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.

01:40 AM
For the Leapfrog DVD Bill script, I wrote: I Joey Arnold wrote this with Gemini on Wednesday, the 8th day of April of 2026 to help rescue a DVD via Ddrescue. This script is named Bill, it went through many versions for weeks. I really started using AI chat bots like Gemini and Grok in 2025 and not as much before that. This particular DVD 03 from 2009 was stuck at around 40%. Then it was up to 42% rescued via this script. I cleaned the disc and then it went up to 62% in 3 hours. A few hours later, it is now still around 62%. But this script is good at jumping when it runs into errors. One of the things that seems to help a lot is -T 1s --idirect --max-error-rate=1 which is three commands or flags being a 1-sec timeout to prevent the laser from getting trapped in bad spots, idirect is supposed to bypass the kernel to talk directly with the hardware before software messes with things, and the error rate flag pushes Bill to jump before it gets stuck trying to read. The main problem seems to be the DVD drive has firmware that locks up the drive when it runs into errors every roughly 6 seconds. To get around lockups, you have to jump before the cops come. Cops being the firmware.

02:42 PM
Dear Gemini
That worked. It went from roughly 42% to 62% rescued in like 3 hours. After that, it went from 62% to 65% in the last roughly ten hours. Your Bill Disc Script helped a lot. Another thing that helped was I cleaned the disc a bit. I probably didn't get rid of all the scratches and problems but cleaning the disc helped along with your script to go up roughly 20% like I said. Before I try to clean the disc more, I want to try to make a better Bill script. In recent days or weeks, this disc was mostly stuck at around 39% to 42% recovered. Adapt Bill. Adapt from this file which is the last Bill disc script you wrote. Bill must be universal to work with any DVD or CD. In the output, it sometimes reads "--min-read-rate=20M" which was good. Bill fluctuated between numbers like 20M, 10M, 5M, 1M. But instead of going up and down like that I recommend Bill tries first at the highest settings which might include 20M, assuming that is the fastest possible, assuming it can't do 30M. Think of it like unlocking a lock for a safe, imagine several dials with numbers. Bill must try different combinations. With the fastest combinations (like the 20M min read rate flag for example) of flags, Bill should try purge the map file to quickly scan forward through all remaining non-rescued bytes. But at say 20M for example. Bill was fluctuating between 20M and 1M and different minimum read rate speeds but I say it might be better to only try one minimum read rate minimum speed before trying lower speeds. After like ten hours, it went from like 2 GB untried to 771379 kB untried. My thought is it might be able to go through untried bytes faster at just 20M speed. You need to do research to see if my idea is better than your last script with the speeds going up and down between speeds like 20M and 1M. My idea is Bill tries to run through all remaining bytes at the highest setting. Keep many or all of the settings that worked like your script said "-T 1s --idirect --max-error-rate=1" which it looks like that works compared to other options. Bill must do what works the best. Research to see what works for my specific situations. My opinion is Bill should run through all bytes at the highest which might include 20M for example. It is your job to write the best set of formulas that has the highest probability of working in situations I run into which might include any situation with any kind of disc. I gave you an analogy of unlocking a safe where there are dials with different numbers because it's a code, a password, and Bill must unlock the bytes. My opinion is Bill should start with the highest settings first, the biggest numbers, and gradually dial down the volume step by step based on what is working. Also, Bill should include like the "--max-error-rate=1" flag for example too. Perhaps one of the variables might be to later change that variable to maybe --max-error-rate=2 and then to --max-error-rate=3 or maybe not. I do not know what might work. But the first thing that Bill should do with any disc should probably be to quickly purge the map file and rescan all remaining non-rescued bytes at the highest settings before trying to lower the settings. I prefer that Bill cracks the code. Your last script worked as it was rescuing bytes. I am only asking you to optimize Bill but only to the extent it might work at the highest probability. I think Bill should try the highest settings and gradually lower the settings slowly. But Bill should probably run through all the remaining bytes at one setting before changings the settings. Unless if a particular setting fails for like ten rounds in a row. Gemini wrote Bill "will stay at 20M (Mode 1) for as long as he is gaining bytes." But why not try to find a way to quickly go through many spots all over the disc before going down to 15M? Why not include more numbers like 15M? My idea is to make sure Bill is jumping and teleporting maximum distances to reset lockups and issues and in order to jump over bad spots and find new spots to try quickly. I recommend Bill sprints at 20M and only lowers the settings to the next smaller number like 15M or 10M or anything above 10M after not 10 stalls but instead 100 stalls where there is 0 bytes gained or rescued in any of the last 100 rounds). Gemini, you misunderstood my safe lock metaphor. What Bill should do is try at the highest settings which includes 20M speeds and --max-error-rate=1 and then after 100 stalls, then Bill could try the same highest settings with 20M speeds but instead with say --max-error-rate=2 because that is how a safe lock combination works, it changes one setting at a time. Gemini is often lazy when writing code and Gemini will just do the most simplest version of whatever I might be saying. Try to fact check everything I said. Bill needs to be sophisticated at starting with the highest settings and gradually turning down the volume step by step slowly and not too quickly. Bill must have all the tools to be as self-aware to be not too patient or too reactive. Bill has to have to the wisdom to try something for a long enough time before dialing settings down a little. You don't have to do exactly what I wrote here but please try to evolve Bill to meet the objectives of rescuing all the bytes. Expand Bill and I would recommend Bill focuses on what works the best. If possible, Bill should be self-aware so that Bill can focus on whatever settings reap the best results. Bill should slowly lower the volume from the highest to lowest settings while also being aware of which settings are producing the best results. Make sure Bill is always trying to minimize firmware issues, software issues, hardware issues, lockups, and anything that might become too problematic. I recommend adding one round at 30M which might fail. After that, move down to 20M. You wrote "One Click at a Time: If 20M at Error 1 fails, he doesn't drop the speed. He keeps 20M but changes the error rate to 2, then 3." But that might be a bad idea based on what you told me many times for weeks. That is why I recommend Bill runs at 20M at 1 error for at least 100 stalls before moving to 20M at 2 errors. The idea of 100 stalls is Bill should try to find random spots to read. After 100 tries at jumping and teleporting to different spots all over the disc, then perhaps Bill should change the settings a little and then try again. Bill should by default try to do an entire sweep before changing settings. A sweep is simply to scan through all remaining bytes if Bill is in the Scan Mode. I recommend that Scan Mode continues until like 95% is rescued or until Bill runs out of combinations to try with Scan Mode. When Bill has no more options, when all options seem to fail, Bill could move to Trim Mode and then Scrape Mode and then Crazy Mode. But by default, Bill should normally try many combinations in Scan Mode. After an entire sweep of scanning through all remaining non-rescued bytes, Bil might want to purge the map file and try to rescan all the bytes via different settings. In other words, do not purge map files all the time, only purge after trying all the bytes via one setting or maybe purge the map file in very rare situations as a last resort in some situations. Expand Bill and remember that Bill should first purge the map file so Bill can scan all remaining non-rescued bytes which includes all the non-tried, non-trimmed, non-scraped, and bad sector bad area bytes. After the first Global Sweep, Bill might want to reset the map to scan through all remaining bytes again via another setting. Bill needs to focus on the best and fastest options. Bill needs to be self-aware. Bill should generally focus on the higher settings during the Scan Mode which by default should normally be for the first 95% of rescued bytes. Bill might want to reset the playing field several times during any of the modes which includes Scan Mode and other modes. By default, Bill should focus on the general outline of trying to rescue all the bytes through these general logic routes. Bill should only rarely alter default settings in super rare situations but Bill should also generally not be too quick to deviate from default routes. Bill can still consult with the Probe Mode sometimes as needed for customizing settings and especially in rare situations. Adapt from this script. Remember to silently unmount one time at the beginning if mounted. Check is it a CD or DVD. Rest lasers for ten minutes after an hour of running but lasers clock starts after Bill is started in the Terminal. Bill should only do one round with 30M and then the rest can be normal. 30M will probably not work. Make sure the safe guards that you have tries to minimize the drive's firmware 6-second lockup cycles and other isssues if there are other issues. Make sure Bill can try to be as fast as possible with the Scan Mode and also never ending with the finall bytes in the Last Mile. Expand and remember that The Sovereign Reset should reset all non-rescued bytes. You wrote about bad and trimmed bytes above. You must remember also scraped bytes too. A reset should scan through any and all bytes that was not already rescued/recovered/copied/saved/restored. Is it possible for Bill to ask the Probe Mode for what is the highest speed so Bill can know if Bill should try 20M, 30M, 80M, or whatever is the highest? Same question with other settings too like sector sizes, cluster sizes, block sizes, etc. Is there any quick way for Bill to find out what some of the key settings might be before dialing the safe lock settings from highest to lowest? Expand Bill. And Bill can ask the Probe Mode for settings like maximum speed be it 20M or higher. But also at the same time, Bill should also follow the default routes of the safe lock system. Get rid of my one-time 30M for one round try and treat 30M just like the other settings where it will try for 100 stalls. If Bill stalls 100 rounds at 30M, Bill can turn the minimum error rate to 2. But if Bill fails again for 100 stalls, either find other dials to turn or go down a level to 20M and continue the safe lock system at 20M. Each speed could be called a world. The first world is 30M. Each world can have different levels. Level 1 is the error rate 1 flag you already included in the script. Level 2 can be error rate 2. You could have multiple or infinite levels as each level is a setting change. The error rates could increase if that helps. Each level can end after 100 stalls. After 10 consecutive failed levels, Bill probably should move on to the next world which would be 20M. World 2 is 20M. Bill must try to focus on what works the best. Bill can try to tweak and mutate settings like trying to unlock a safe lock. By default, Bill should generally move from world to world and from level to level. Increase the number of worlds, first world is 30M, then 20M, and the numbers can continue to get smaller, I recommend at least 20 worlds to gradually lower the volume step by step. Okay. Good. Bill worked at 30M. Bill rescued bytes. But after about an hour or so, the drive was not making noises and no flashing lights. Between every level, Bill needs to make sure it can still talk to the drive. I don't know exactly what happened, but the output below shows everything failing as the drive appeared totally off. I don't know what caused the drive to turn off. Bill needs to check between levels to make sure things are working to prevent every single world and level fail when the drive is off or whatever the issues might be. Will Bill conflate resting the lasers for ten minutes with the Heart Beat Check where Bill should restart the heart and immediately go back to conquering worlds and levels without waiting ten minutes or any seconds during a Heart Beat Reboot?

07:28 PM
Dear Gemini
The result is as soon as Bill starts, NECROMANCY starts in an endless loop where it triggers the disc drive to light up and beep like R2D2 of Star Wars. It seems your previous scripts ended up breaking the drive and/or your NECROMANCY code is in this loop where it triggers the drive in an endless loop.

10:28 PM
Dear Gemini
After running sudo ddrescue --generate-mode /dev/sr0 /home/a/dvd/dvd.iso /home/a/dvd/dvd.map, I ran this file, an earlier script you named bill_v1800.sh - THE SOVEREIGN LEAPFROG COMMANDER. By the way, I wonder why you didn't include this command for fixing map problems. I asked you dozens of times to fix the problem and you failed. But then this manual reconstruction command recreated a new map to restore 66% rescued in only like ten seconds. If I was you, I would include this command in scripts to attempt to make a new map file as a last resort if Bill ran into too many errors with no way to escape. When running THE SOVEREIGN LEAPFROG COMMANDER version of Bill, it went from 66% to 71% rescued in roughly an hour. For earlier scripts, Bill started with --max-error-rate=1 at 30M speed. The current setting now is --max-error-rate=2 which might be better but I do not know. The question would be how high is too high. Like might --max-error-rate=9 do better than --max-error-rate=1? The idea for level 1 of World 1 of Scan Mode is reopen all unrescued bytes to rescan and scan quickly before attempting different settings. The idea was that philosophy might be a way to possibly rescue a majority of the bytes or at least easier spots as fast as possible before trying to enter Trim Mode, Scrape Mode, Crazy Mode. I'm asking you to develop a super universal Bill script that can handle any type of disc be it a CD or DVD that might be 0% to 99% rescued. I recommend that Bill tries to find the fastest routes to attempting to quickly scan through as many bytes at the fastest speeds before getting stuck by bad spots. On top of that, we also have the hardware firmware issues. After talking to Gemini for hours, you concluded it's very hard or impossible to fully disable the drive's error-reaction firmware every like 6 seconds or whatever it might be. That is why you came up with solutions around that. I wonder if the --max-error-rate=1 flag might get around that firmware if the flag is set to --max-error-rate=9 or even a rate of 9999999999999. It is your job to have Bill start at the highest speed which is 30M and an error rate that might be not too slow. It might be better to keep it at 1. But I already said it is currently at 2. One of your earlier scripts must have caused the drive to sleep. After that, we were trying to find ways to wake up the drive. One of the concerns is to make sure Bill isn't killing the drive like that or finding smart ways to wake up the drive but only when it really needs to. But then if Bill is constantly trying to wake the drive up, that might break it too. Therefore, it might be better to only check every ten minutes to see if the drive is still up or sleeping. Expand Bill and adapt from this earlier LeapFrog script. Find out what is the most effective for level 1 of world 1, see if only reading forward and not backwards is generally faster. If so, start level 1 at 30M, error rate 1, only reading forward and not backwards. Level 2 can be identical to level 1 but backwards. Level 3 can be identical to level 1 but error rate 2 forward. Level 4 identical to level 3 but backwards. This pattern can be followed forever. Each world can have infinite levels. Each level can have infinite rounds. Each round can be infinite seconds long. I recommend 30 worlds starting with the 30M speed. Each mode can have these same worlds and levels but in the flavor of the mode. The first Scan Mode are the worlds and levels focused on scanning. The second Trim Mode can be the same worlds and levels but with the trim flavor. The third Scrape Mode can be the same thing but with the scrape flavor. The fourth Crazy Mode can be the same but like random and stuff in an attempt to hack and rescue final 1% of the bytes or less. Perhaps Trim Mode and other modes can't do the 30M speed thing or other things, so perhaps you can modify the details if you have to. If 100 consecutive stalls (rounds fail to rescue a single new byte), Bill must move to the next level. If ten consecutive level stalls (meaning no new rescued bytes for ten consecutive levels), Bill must move to the next world. If Bill has to activate the Heart Beat to resurrect the drive, then reset the stall counter and level so Bill can continue from the beginning of the current level. Remember Bill must have enough safe guards to minimize the drive's 6-second firmware lockup and other issues too, Bill should be smart enough to adapt to any disc and problem. Bill should consult with Probe Mode when Bill is started in the Terminal and between each level. By default, the Probe Oracle could tell Bill to continue the default route of each world and level and round. The Probe should monitor the eight files, Dmesg, and anything that might help inform Bill on what to do. But by default, Bill should generally follow the default routes where Scan Mode is all about trying to rescue over 95% of all the bytes (Objective 95% or the Telescope Philosophy). But remember that sometimes the Probe Mode could trip over it's own shoelaces to cause hardware or software issues similar to the Heart Beat System did. Make sure these different systems don't trip over their shoelaces. Try to minimize potential issues that might come up. The heart of the design is to encourage Bill to always rescue all bytes of any disc within seconds in a sprint mode which we call the Scan Mode. But at the same time, Bill must also be able to run marathons in an attempt top rescue the remaining bytes in the Last Mile too. You wrote, "Synthesized Safety: If the mapfile ever wipes again, auto_regen will see that the ISO has data but the map doesn't, and it will immediately run the --generate-mode command you discovered to restore your 71% progress." But usually the mapfile breaks resulting in a broken mapfile and not an empty mapfile. You wrote, "One warning: If you notice the drive sleeping, the deep_reset uses the SCSI scan to wake it up silently. This is much safer than a full reboot of the script." I recommend Bill only checks every ten minutes. Regarding killing the cops, make sure to fully adapt anything that might work from all the many scripts that relates jumping, leaping, teleporting. Expand Bill and remove the strict 95% rule. The main progression was what I said already about going through each round, level, and world. I already said if Bill runs into 100 consecutive stalled rounds of no gained rescued bytes, move to the next level. If stalled for ten consecutive levels, then move to the next world. After world 30, return back to world 1 and try again. After 5 consecutive stalled worlds, then move to the next mode. Remember to include all four modes being Scan Mode, Trim Mode, Scrape Mode, and Crazy Mode. Outside of the Probe Mode telling you otherwise or other rare situations, Bill should follow this route, these sequences of events for determining what to do. It might be too hard to train Bill on how to know when to skip directly to Trim Mode or other modes. I say in rare situations, Bill might want to skip modes. But by default, I feel it can be better to go through each round, level, world, and mode in order.

Twitter Tweets
12:19 AM

Instead of Never Ending Wars in the Middle East, why can't we just put our military on our borders and build a wall?

01:17 AM
Didn't Trump say he was gonna stop the Ukraine Russia War and instead we're in Iran?

01:22 AM
I support Jewish People but not Benjamin Netanyahu who refuses to stop hitting Iran putting Trump in a tight spot.

01:47 AM
Trump's Iran War is already costing the world billions to trillions of dollars, ending the war won't undo that.

2008-01-02 - AES Deferment at 2007-11-13 to 2008-11-12 for Economic Hardship.png

04:20 PM
Israel's Benjamin Netanyahu is a bad man and Trump must leave the Middle East or people should 25th Amendment or impeach Trump.

04:27 PM
If Trump really did attack Infowars Alex Jones, then Trump has lost the plot. The following is allegedly something Trump put out. Trump also went with the Covid Scam for years too which resulted in many people dying from deadly vaccines.