2026-04-10

12:24 AM
Dear Gemini
Good. Stall is working. I already told you the default rule to move to the next level after 100 consecutive stalls. I defined a stall as a round with no new rescued bytes (+). But let's add another rule. Move to the next level after 20 failed reads. Let's define a failed read as Ddrescue failing do any of the following four things for a single byte in a single round: first, failing to mark a byte as Non-trimmed (/); second, failing to mark a byte as Non-scraped (*), failing to mark a byte as Bad Sectors (-). When Bill fails to do any of these four things during a single round, count that as one failed read. Also check the script to make sure there might not be hardware or software issues preventing Bill from reading bytes. We talked about my exact setup many times for years. So, it can be tough to know as it relates to the -d related flags. But the "T 1s --idirect --max-error-rate=1" flags worked in previous scripts. We talked a lot about the -d flag many times but perhaps the specific --idirect is the best flag for bypassing kernel and other issues. The FAIL_READ counter went up even while the non-trimmed counter went up. I want the FAILED_READ counter to reset when it reads. I want the STALL counter to reset when a byte is rescued. Expand Bill. Remember that when a byte is not rescued in a round, the stall counter goes up 1. Also, if bytes are not marked in a round, then the fail read counter goes up 1. As defined earlier, the fail read counter means if not even a single byte is being marked to be trimmed, scrapped, or bad sectors. But to be clear, the purpose of a world is to describe a speed. World 1 is 30M. Each level can describe the alteration between --max-error-rate flags and the forwards or backwards flags. Mutations can be useful during Crazy Mode if mutations can find a way to rescue bytes that other methods can't. It seems that mutations are generally not needed most of the time until the Last Mile. You can include mutation rules but you can drop the mutation counter. When the stall or read fail counters get close to the end, that could trigger mutation rules that attempts to mutate flags. But Bill should generally stick to the default settings as opposed to letting mutations alter the routes too drastically. Unless if a mutation results in rescuing bytes. That would then trigger the streak counter which would say the mutation is rescuing bytes. But outside of that, Bill should not focus on mutations. Expand Bill and double check the logic behind how Bill decides to jump, leap, teleport, to find new untouched undiscovered bytes, to escape kernel issues, to escape cache issues, to escape the hardware disc drive firmware 6 second lockup software issues, AKA the cops, other issues if any, make sure Bill can do his best at staying alive jumping around dealing with the many issues with the SATA disc drive, the FIDECO, the laptop, the software, hardware, the many pieces of the puzzles, the moving parts, the flags, the methods, everything. Expand Bill and make sure Bill is the best Bill ever. Study the output below. Some of the previous scripts had flags like -T 1s --idirect --max-error-rate=1 which worked. Your most recent script has M_FLAGS="$M_FLAGS --idirect --nocache --retry-on-error" and that is good. It looks like nocache is a good flag. The idirect flag is probably better than -d based on what I have seen so far. Some of the earlier scripts had flags like -K 512Mi,4Gi and I do not know how that compares with the current script you wrote relating to teleporting. I recommend you use whatever methods has the highest probability of running from all the cops be it the kernel, the cache, hardware issues, software issues, drive issues, firmware issues, Fideco issues, Ubuntu issues, Atapi issues if any, and so on. Do your best to try to safe guard and minimize potential issues relating to all of these many variables and moving parts. Expand Bill and make sure Bill is always trying to run from the cops using the best flags possible. The mutation logic should not focus on running from the cops but on trying rescue bytes or at least minimize the read fail counter (reading meaning to mark sectors to be trimmed, scraped, or bad sectors) from going to 20. Bill should focus on the teleporting and on running from the cops all of the time and not just when mutation is on. I shared with you many messages from like Dmesg. I could be wrong, but Dmesg may have said that I ran into the 6 second drive firmware lockup and/or different issues. At an error rate of 1, one round extended to 15 seconds. After that round, 9 seconds and it continued rescuing bytes. It is tough to say where the invisible line is. I wonder what might lockup the drive. There has to be a way to know what exactly would lock it up. I am not sure because the Dmesg info is confusing. I gained 227328 B in a 15 second round. I gained 227328 B in a 15 second round. You wrote, "If you set --max-error-rate=100, Bill will hit an error, wait for the 1-second timeout, and then immediately try the next block." Are you saying that the error rate would prevent Bill from teleporting? Why couldn't the 1-second timeout flag tell Bill to leave and then why would Bill not look at a teleport flag and leave the block?

01:51 PM
Dear Gemini
Talk to me about finding formulas for Bill. For example, one idea might be formulas attempting to get Bill to jump a few times and then teleport. The trick is to find the Goldilock Formula to jump the maximum amount before say the firmware locks up the drive other issues. Also, it is a question of if it might cost more time similar to the -R situation. I would love to find a hack where Bill hops a few times when it runs into errors before it has to say teleport. But the trick is to try to save time trying to do the very most while trying not to lock up the drive or other issues. Try to see what the best formula might be to juggle all the variables like trying to save time versus all potential risks like sync issues and risking locking up the drive and whatever else.

02:56 PM
Dear Gemini
Here is my new pitch for a new Bill script:
Expand Bill. Use the specific names of the 8 files from this script. Adapt as much as you can from this script I sent you. Think about everything we've been talking about for weeks. Bill should generally by default run with Scan Mode settings until 95% of a disc is rescued. But to be clear, I said by default because perhaps Bill could mutate or personalize settings in rare situations if Bill or the Probe Mode is able to use information from Dmesg, Ddrescueview, the eight files, other information etc, to alter default routes if Bill finds the routes, the probability of the profitability (saving time) of trying to rescue all the bytes of a disc to be above the rate of diminishing returns. For example, it would be great if Bill could sometimes look at Ddrescueview and other statistics and data to determine if or even when Bill should alter default routes.

Earlier, I told you to drop the 95% rule. But now I'm thinking the default route is more profitable to stay in Scan Mode for a disc until 95% is rescued. You need to let me know if it might still be profitable to continue default Scan Mode settings above 95% rescued. Earlier, I told you to have Bill progress from levels to worlds to modes based on the 100 stall counter and 20 read error counter. I suggest now that the default setting is to have Bill only loop between levels and worlds in Scan Mode until 95% rescued. At 95%, it might be generally more profitable to switch to Trim Mode. And then to switch to Scrape Mode at 99% and then switch to Crazy Mode after 5 hours.

Scan Mode defaults should have many or even all of the things we talked about like the -T 1s --idirect --max-error-rate=3 flags. You can decide optimal settings for other modes. Scan Mode should have the Hop Teleport Combo we talked about with the Error Rate 3 + Hopping and then teleporting or I think you called it like a Springboard. See if you can make sure Bill only teleports to non-rescued bytes (unless if it might be time-profitable to land on rescued spots in an attempt to run across bad spots, bad dots, bad areas, unrescued spots, potentially good spots, etc. Also, it might be profitable for Bill to only teleport to one place once and then checking it off Bill's List like Santa Claus does for all the people he drops presents at. When Bill starts, the default route for Scan Mode is to purge the map file of anything not rescued. Scan Mode should only scan forward and not backwards by default. I suggest Bill loops between levels and worlds in Scan Mode until 95% rescued. I suggest at least 30 worlds for each of the four modes. After Bill loops back in Scan Mode back to world 1, that is when Bill should purge the map file to try to scan through all remaining non-rescued bytes again.

Make sure Bill has the best settings to minimize all potential problems include the drive firmware lockup issue for example. Earlier, I mentioned how the no cache related flags might not work, we talked about that, but you may have found alternatives to flags that don't work. It also seems that --idirect is the best flag out of the different direct IO -d flags, double check to see which flags have the highest probability of working as it relates to my specific situation with the kernel, the cache, the hardware variables, software, Linux, Fideco, SATA drives, USB, etc.

Level 1 of World 1 of the Scan Mode should have the maximum profitable cluster size, the biggest it can go without too many issues like Fideco or other things choking or whatever. I suggest level 2 be a slightly smaller cluster size. Level 3 could be even smaller. Earlier scripts had levels alternate between increasing the error rate number with turning the -R reverse flag on and off between levels, but now I suggest deleting that. The default route should reserve -R and increasing the error rate to anything above 1 to after 95% rescued. Therefore, one variable that can change per level is cluster size. Feel free to add other variables if they might be profitable. You can decide how many levels there should be depending on how many different variables might be used to make each level slightly different. Each world should be slightly slower. Level 1 should be 30M speed or maximum speed. Do your best writing the best Bill disc script ever with everything we have been talking about for years in mind. Expand Bill, see if you can nudge Bill to other modes if it becomes profitable to do so. But only if it is truly more profitable. But the default route is to stay in Scan Mode until 95%. Perhaps Bill can stay in Scan Mode after 95% but with a quicker trigger to switch to other modes. Perhaps the trigger can stay the same regardless of if a disk is 0% rescued or 99% rescued, that there might be ways to trigger Bill to calculate that it is more profitable to switch to other modes based on anything and everything, the probabilities, the math, the science, the facts, the raw data, the 8 files, Ddrescueview, Dmesg, etc. If you can develop a smart enough trigger, then it could move Bill to other modes but not until it is very clear it is more profitable to do so. Perhaps the 95% should make the trigger ten times harder to activate or I don't know how many times harder it should be because it should be based on pure math, science, probability, etc. Make sure the triggers are very smart because it might be very hard to guess when to trigger a mode switch if the Ddrescueview map for example is like say too empty or too unexplored. In other words, in a world of probability, the more Bill does not know what might be in each byte, each cluster, each block, each sections, each region, each area, each dot, each scratch, each bad sector, each bad spot, each variable, then that probably increases the odds that the triggers to switch modes might be more counterproductive as opposed to profitable enough in the world of risk taking. If you can develop mode switching triggers, it must be very smart to understand the math, the science, the art of probability, at gambling with the odds, the risk taking, of deciding when there might be a higher probability of doing better in other modes. This trigger could, if written right, keep Bill in Scan Mode even until 100% of a disc is rescued assuming there are no bad spots. Try to see if you can keep Bill in Scan Mode above 95% and to only switch modes at the last minute when it is profitable to switch but not until it is clear it is profitable to switch. All four modes should have triggers where Bill only switches when it is profitable to switch. By default, Bill should stay in the default route of Scan Mode to 95% then Trim Mode until 99% rescued, and then Scraped and Crazy Modes after that until 100%. The triggers should only come when they have to last minute. Bill should be able to switch to and from any mode but should by default remain in the default route of scan, trim, scrape, and then crazy in that exact order of modes in normal situations. Make sure Bill checks is it a CD or DVD. Make sure Bill rests lasers for ten minutes after one hour of running but lasers clock starts when Bill starts. Expand Bill and make sure Bill generally when profitable stay on default routes of the four modes in this exact order generally of Scan Mode to 95% rescued bytes, Trim Mode to 99%, Scrape Mode, and then Crazy Mode. Make sure Scan Mode World 1 is 30M speed plus the other flags and settings we talked about for maximum speeds and probability. Remember each level should be a lower cluster size. I do not know if there are other variables, flags, settings, that you might want to include to add variety to levels. There can be as many levels per world as you want. Remember Bill should by default rotate through levels and worlds within the current mode until Bill is triggered to switch modes. Bill should switch levels according to the 100 stalled (no rescued bytes) or 20 failed reads (failing to mark any byte to be trimmed, scraped, or bad sector) counters that we talked about. I suggest looping between levels until 10 consecutive stalled levels. Like the 100 stalls counter, if Bill fails to rescue a single byte for 10 consecutive levels, Bill should switch to the next world. Otherwise, Bill should rotate in an endless loop between levels. Each level can be infinite rounds. Each round can be an infinite amount of seconds. Expand Bill and make sure to purge map at the beginning of each mode which means to purge if Bill loops around from the final world back to the first world of any mode, purge map because Bill is at the beginning of the mode again. I want a live byte counter at the bottom of the scrolling non-clear Ddrescue live activity monitor activity so I can total rescued bytes in actual bytes and not in KB or MB or GB but in B or bytes only. Bill works. Expand Bill. Since Scan Mode: World 1: Level 1 should have the highest fastest biggest greatest strongest coolest widest longest settings ever possible, contrast current Bill script settings with all other possible settings including the debates on what might be faster as it relates to if Bill should perhaps by default include flags relating to teeling Ddrescue to specifically do not trim or do not scrapped versus whether or not some of the specific flags should not be included or maybe some flags should be included later on in different levels, worlds, modes, versions, flavors, rounds, and/or mutations. The Silence counter said "SILENCE: 493296h 24m 2s" which is off. Expand Bill the best you can. Double check to make sure Bill is the best Bill that Bill can be. Perhaps the Probe Mode needs to be expanded to better help Bill keep an eye on the eight files, the Dmesg, live stats, all the raw data, all the facts, the specifics, the details, the map file via Ddrescueview, any programs, commands, etc.

Twitter Tweets
07:47 PM

I'll vote Tulsi Gabbard for President.

10:03 PM
I only have one fan named Maflopper.