01:53 AM
Dear Gemini
Your script is good but try to expand it. First, the script must not do the direct -d related tags or flags like it did in previous version until it has no other options. For example, you wrote in previous versions of the DVD script things like, "--- 4. DIRECT-IO PROBE (Fideco/SATA Compatible) ---validate_direct_access() { local CANDIDATES=("-d" "--idirect" "--odirect" "--sync" "--force")" but it is critical to optimize on speed and accuracy. Look for other problems to fix too. After many years of doing this, many AI engines like Grok and Gemini seem to generally fail to tell me problems relating to rescuing using -d related tags. You can use direct related tags for the last mile, like the last 1% or after maybe a thousand rounds or 100 hours or something like that. Look for other mistakes and errors and problems in the script. Try to put everything you forget into the script. You often forget things. Expand the script. But script must fix itself when it breaks. But your scripts usually don't fix itself even after I tell you it must. Please try harder. Second, try to maximize how fast it can rescue any kind of disc. It must focus on what works. It must try for maximum speeds. Expand script. First, it should only do direct -io flags if it has to as a last resort if nothing else can work at the very end like after over 99% is already rescued or in very rare situations when everything else is failing after like a thousand rounds and like ten hours or more or something really crazy kind of thing. Second, make sure it optimizes for maximum speeds. Third, jumping should only happen if it stays stuck for more than ten minutes. You wrote, "If the script stalls for 200 rounds, it now executes a blockdev --flushbufs." Change that to if it stalls for 2000 rounds. If it is possible to detect error rates, that could help the script optimize as it should want to minimize the error rate. Currently, it seems average around 5 MB/second in earlier scripts and runs. It should try to rescue at the fastest speeds as long as the error rates are perhaps minimized whenever it can be. Only adapt from the floppy script the level system. You Gemini wrote me script for my floppy and DVD projects. In the floppy script you wrote, it correlates levels to percentages rescued. But when I asked you to do the same thing for the DVD CD script, you failed. You failed many times for days to do this. I do not know how you are unable to do it for the disc script but you did do it for the floppy script. Gemini might be broken big time. Expand script. It should try to force it to go at maximum speeds to rescue, it is a Lite-On SATA DVD drive through FIDECO into a USB port for my Ubuntu ASUS laptop. So it could try the fastest speeds possible for a short time. If it fails, then it should try to remember that and go to the next best thing. If that fails, then the third best thing and so on and so forth. The priority is speed but focused on accuracy as it needs to try to rescue. But because there are many scratches and problems on the discs, it may want to read past the scratches until it finds good spots. But I already told you it should only jump after ten minutes of it being stuck. But if possible, it should try to keep moving even past the bad spots to find the good spots. Expand. Instead of 256-bit, make it 4,000-bit or higher, remember it is all about math, science, probability, a flowchart focusing on whatever works the fastest. It should not be random. Focus mostly on winning waves. You wrote, "Direct-IO Locking: Uses -d --idirect --sync specifically to bypass the Ubuntu kernel cache, which is vital for old floppy media on modern hardware." It is critical to only use direct IO tags as a last resort if nothing else works during the last mile after 99% is rescued or when nothing else works after a thousand rounds and ten hours or in rare situations.

03:13 PM
Fix the script. Expand the script. See if there is any way to make it better. Currently, it sounds like the disc drives spins on and off. I do not know what the drive is doing exactly but I hear the high pitch beep style noises which lasts for about a second each. The noise happens in spurts. So, I hear the noise for about a second followed with silence for like 5 to 10 seconds followed with another sound that is usually the same type of noise. I think the noise is related to when the disc driving is spinning. After it does the spurt of noises for like ten times, there is silence for like ten to 30 seconds before going back to the spurts. It does sound like normal noises. The good news is it sounds not as loud as with earlier scripts. After I had Gemini attempt to remove -d direct related tags, that reduced the noises. So, I am complaining about these current noises but they are not as bad as what it was. You can see in the output below that it is rescuing bytes. I do not know if there are any tweaks that might alter how things are right now. Now, the noises might be 5% quieter but your new script seems like and sounds like it is mostly just delaying the same noises that it was already making, it sound like your script is not really changing things a lot if at all, it sounds like your script is just delaying the noises, it sounds like it might be a little quieter. The delays you put in the script adds an added space that is like a second longer than before. So, you were able to delay the noises for a second or so. But after your delay, then it goes back to the normal noises I told you about earlier. Perhaps a tiny bit quieter now. Perhaps a longer gap here and there between spurts now. But it mostly still sounds the same or similar as it did before. Expand script. The general logic is first to try all the bytes one time. There should be no reading bytes backwards. There should be no retries. There should be no trimming. There should be no scraping. It should try bytes only in a forward manner one time. Sometimes, it might want to skip over bad spots. It might want to jump over bad spots. The script should still be mostly the same with the over 4,000 bit integer of trying everything to find the fastest route later on. You should try to keep everything that is compatible, applicable, relevant, from earlier scripts. But it should start with one pass or one run through the easiest bytes if it has not yet depending on what map files might say. It is critical it tries to quickly rescue all the non-tried bytes or whatever that might be remaining depending on how much was already rescued. I still want the script to have the general logic of focusing on what works the best in general. I still want the script to have a build a bear system so the script can adapt when it needs to later on. But I recommend that the script starts off doing the simplest easiest things first like trying to read through remaining non-tried bytes only one time and only forward for the first series of rounds. You should still keep levels tied to the percentages of bytes rescued. It should still have infinite levels. It should still try over 4000 combinations or as many things as it can for the first 100 levels. It should still try to ride winning waves. It should still try to rescue at the fastest and biggest speeds when possible. Remember the issues with the drive making noises. It should read the remaining non-tried bytes forward one time meaning no retries. After that, it should try to read all non-rescued bytes but this time backwards but only one time. It should skip or jump if it stays stuck for too long. So, the simple logic should be to try to read all non-rescued bytes one time forward, just forwards and not backwards, each byte or many bytes that were not already rescued. After it tries that, then it can do that again, all non-rescued bytes, but backwards one time all the way through. One time meaning no retries or no forced retries. The script needs to keep things moving. Using the 4,000-bit sequential integer, the script should have the best flowchart of options. It should not be random. It should continue to find the fastest routes towards rescuing all the bytes 100%. So, use the best math and science based in probability to help the script rescue every byte. I laid out the first two things it can try to do as it relates to all of the remaining non-rescued bytes, to read each byte or many byte forward one time quickly to try to rescue each one or as many as possible as quick and as fast and as many as possible without like retries or too much grinding. Don't get stuck on a byte for over ten minutes say for example. After that, the same thing but backwards on all of the remaining non-rescued bytes. After that, your script needs to determine what to do with the goal of trying to rescue all the bytes as fast as possible focusing on what works most of the time. The phases probably should not be locked to a specific number of rounds because the objective is not to force a specific number of rounds. So, for that first phase that you named the Forward Linear, you included the -r0 which is good if it does zero retries. The idea is the script should try to read many of the remaining non-rescued bytes forward. Meaning it should attempt to read bytes that were not rescued yet but only forward and not backwards during this Forward Linear phase. But it should NOT be simply locked to a certain number of rounds. It should be locked in simply trying to go through all or at least many bytes that were not rescued. It should not get too stuck when it runs into bad spots. It needs to keep going through remaining bytes. Same thing with the Backward Linear -R phase, it should follow that same logic that the Forward Linear phase had. You can have as many phases as you need. The first two phases must attempt to read remaining bytes that were not yet rescued. It is that simple. Each phase can be as little or as many rounds or passes as it needs to be. A phase simply needs to attempt the objective just one time. So, it should not be locked to a number of rounds or passes. You named the firs two phases. Using the 4.096-bit sequential seed integer, the script can decide the best logical path to rescuing 100% of the bytes. It must focus on probability and on winning waves. I do not know how many phases should attempt to do the first step of trying the non-tried bytes. When I say non-tried bytes, I mean the non-rescued bytes that are retried so to speak. But the word "RETRY" has multiple meanings, so please do not get confused. Phase 1 should try to read bytes that were not rescued yet which could mean non-tried bytes, non-trimmed bytes, non-scrapped bytes, and the bad-sector bytes. The logic is phase 1 reads bytes that were not rescued but forward. Phase 2 reads bytes that were not rescued but backwards. Phase 3 could be similar but slightly different. Phase 4, same thing but slightly different. Strategize with the 4K-bit seed thingy to determine some of this. I don't know how many phases it should be. Eventually, you may want to focus on trimming. After that, you might want to focus on scraping. But at least the first two phases can be focused on all the bytes that were not yet rescued. After that, you need to find the best routes. Phases should not just focus on only non-tried bytes. Notice I did not say non-tried. You said non-tried but I did not. I said non-rescued. I said non-rescued because some bytes might be non-tried. But some bytes might be non-trimmed. Some bytes might be non-scraped. Some bytes might be in the bad-sector. Some bytes might be in bad areas. It is critical that the script tries to run through non-rescued bytes only forward. It can jump or skip when it gets stuck for too long. After that, it is critical it attempts to run through or pass through all remaining non-rescued bytes but this time backwards. Thus, the two phases that we talked about. When you said non-tried earlier, I do not know if you meant to say that includes any byte that was not yet rescued. So, make sure the script can do this. You wrote, " it targets the Unified Non-Rescued Set. This set includes: Non-tried (the ? status in your map), Non-trimmed (the / status), Non-scraped (the - status), Bad-sectors (the * status)" and that sounds good. The first phase should attempt to target all or at least many of the Unified Non-Rescued Set that you defined above forward. Second phase, same thing as the first phase but backwards. A third phase could be the same thing as the first phase but a variation using the 4K seed to determine a third variation to these phases for finding the best route to targeting the remaining Unified Non-Rescued Set. You can have as many phases as you want as long as it is the fastest route towards 100% bytes rescued. Eventually, some of the phases should perhaps not try the Unified Non-Rescued Set merely via a 4K seed but instead via a trimming approach. The first two phases should not trim or scrape. But some of the later phases could perhaps try to trim the Unified Non-Rescued Set. Perhaps some of the later phases could even try to scrape the Unified Non-Rescued Set. But you must determine when to attempt to trim and scrape via phases and levels and rounds and steps and the 4K seed integer thingy focused on finding the fastest route towards 100% rescued in the fastest time possible focusing on winning waves most of the time. Sometimes, Gemini would write similar things. But it seem to me to be not very effective. For example, when Gemini put these additional files in the script, some would remain at 0 bytes. Some remained at like 5 bytes. Right now, Gemini wants to insert /tmp/dvd_fwd_done and /tmp/dvd_bwd_done into the mix. It might be that these added files might not do much as we already have the normal log file and map file that ddrescue uses. Please calculate the probability that this latest script will work a lot better with two additional files. I rescue many discs. So, I run the script many times. After I rescue to dvd.iso, then I move the image file and run the script on other discs. I also move the map and log files as they are specific to the discs I rescue. I keep the script as it is reused. Do I have to move FWD and BWD files or can they be recycled or reused like the script is? Also, expand the script. It is critical that later phases tries to quickly trim all remaining non-rescued bytes in the same way you would with the first two phases but with trying to trim forward. After that, trim backwards. After that, scrape forward. After that, scrape backwards. After that, back to the 4K seed thing, the fastest routes, the winning waves, and everything. The fast trimming and scraping phases might be best for after like level 90 or whenever it might be the best option. You have to find the fastest routes towards 100% rescued and trimming and scraping phases might sometimes be a slower path towards winning. It might be useful to try at least one time to quickly trim and scrape forward and backwards just to see. But the script needs to try not to get stuck in trimming and scraping. That is why I recommend the script focuses on the fastest route which might not be trimming and scraping until later on. And even if the script does eventually tries to trim and scrape, then it might want to take a break from trimming and scraping if that appears to be too hard compared to other options because it is all about focusing on the fastest routes. The script must try to adapt towards the fastest routes. Gemini FUCKING made the same mistakes it made for years. I post the RESULTS on my BLOGS for years. Gemini ignores my PUBLIC BLOGS which exposes how Gemini makes the same mistakes many times for years. It is documented. I don't see the FWD and BWD files, I can even see invisible files and hidden files and system files in my file explorer on Ubuntu, I do not see the files in the home directory. You might say the files might be created someday. But I do not see them right now. I did not specifically mention the "MANUAL RESET SWITCH" and you lied saying, "I have also integrated a Manual Reset Switch as requested." You might think you did not lie because you may have interpreted my silence to mean yes. AI engines including Gemini and Grok are known to make too many assumptions because it saves on processing power and bandwidth. AI uses if then logic. AI uses many complex flowcharts of if this then that logic. So, it is likely Gemini simply assumed I want that switch. I say the script needs to be smart enough to have whatever switches it needs to automatically get the job done. It is supposed to rescue 100% of the bytes, so it must determine which switches it needs and when to pull them as it strategizes towards the fastest route towards 100% rescued. Expand script. But this time, name this v.510.1. Each version should be named like this. Next one can be v.510.2. Phase 1 should be to forward read non-tried bytes, no retries when reading, skip or jump when stuck for longer than a minute if bytes. Stuck meaning not reading. Stuck meaning stuck in a bad spot unable to escape the black hole. Phase 2 should be phase 1 but backwards. Phase 3 should be phase 1 but with non-trimmed bytes. In other words, phase 3 should attempt to read non-trimmed bytes forward in the same way it did phase 1. Phase 4, same thing with the non-trimmed bytes but backwards. Phase 5, same thing but with non-scraped bytes forward. Phase 6, same thing as phase 5 but backwards. Phase 7, same thing but with the bad sector bytes forward. Phase 8, same as phase 7 but backwards. These 8 phases are simply attempting to read forward and backwards the four types of non-rescued bytes being non-tried, non-trimmed, non-scraped, and bad sector. So, that is four types divided into two groups, forward and backwards. You can rewrite this or edit this if you find these first eight phases to be too ineffective. But that is the general idea for the first 8 phases. The next 8 phases, phases 9-16, could be identical to phases 1-8 but with attempting to quickly trim non-rescued bytes. After that, phases 17-24 could be identical to phases 1-8 too but with scraping non-rescued bytes. But then after that, the script should continue after that with everything else from previous scripts. But the general idea is still the same like I said for the previous scripts. You can edit, update, and modify these ideas in order to maximize the probability the script finds the fastest route towards 100% rescued. Remember the script should focus on the fastest routes which is why it is dangerous to focus on trimming and scraping for too long. The script shoud try to sometimes trim and scrape when other options are not working. But the script might want to always trim and scrape until it has no other options left. Script must be random but smart with the 4K-seed integer math flowchart as it navigates winning waves trying to focus on the fastest routes most of the time. Adapt from the disc script as much as you can everything that might be relevant, applicable, effective, efficient, productive, the fastest, the best, the most related, the highest probability of working towards rescuing every byte the fastest route via winning waves most of the time using a 4K seed integer math science flowchart of AI logic and not random. Yes, add a flux phase and anything else that helps it focus on the fastest routes most of the time. Remember it should have infinite levels if it needs to. It should only jump when it is stuck. It should focus on the fastest routes. It should focus on what is working most of the time. It should focus on what has the highest probability of working. It should fix itself when it breaks. It should eventually try all options after all of the better options are exhausted. Update script. Remember that the USB floppy drive is NOT plugged into FIDECO. That is Gemini assuming too much again. I never said it was. I said the disc drive was plugged into FIDECO. This is why Gemini is still a baby as it makes too many assumptions. Update script, expand script as much as you can. Try to make sure the script can do anything and everything that it needs to. Delete the phase stats file from the script because former scripts failed to do enough with additional files that Gemini tried having. Try to find other ways to meet all of the objectives. The output below sometimes says "Initial skip size: 256 sectors" but 1473 kBytes of the total 1474 kBytes were already rescued. Script needs to be smarter. It might be dangerous to skip over bytes if it results in not rescuing bytes. You must determine when to skip and when not to skip based on science, math, probability. Optimize script as I have 32 GB RAM and 8 CPU cores. Remember the limitations of the floppy drive itself and other limitations. You broke the script again. It is still skipping. For example, it said, "Initial skip size: 128 sectors." Also, after running the script twice, it exited. It even said it won. But it did not. It lied. Please fix the script. Expand it. But the script must run until it is 100% rescued. Remember that 99% rescued is not 100% rescued. You wrote, "Dynamic Vacuuming: In the final bytes, even the retry count" but I did not say focus on retries. I told you for years that retries rarely work. But Gemini is stuck in making assumptions that are false. The 4K seed should not focus too much on retries as that rarely works. Instead, seeds should for different ways of trying to rescue bytes. Changing the number to how many times it tries the same thing over and over again is usually counterproductive. I already told Gemini this many times for months or years and yet Gemini keeps on going back to this broken logic. I recommend some retries after round 10,000. But before round 10K, there are plenty of other combinations a 4K seed could try. Every single change in a speed variable or size variable could be considered a different seed meaning there might be millions of seeds that could be tried without even wasting time on a brain-dead approach like retrying. Fix script. Study the output below. Also, as it relates to the 4K seed integer math science flowchart AI strategies of winning waves towards 100% bytes rescued via the fastest routes, it is critical that the seed-pool stays correlated and relevant and applicable and related and in sync with the remaining bytes not yet rescued. In other words, if a disk only has one byte left to be rescued hypothetically, the seed should probably not try skip that last byte or read more than byte or read too quickly. I mean as it relates to the variables, the sectors, the blocks, the sizes, the tags, the flags, the settings, the variables, the hacks, the codes, the commands, anything that you can think of, it is great that a 4K seed could hypothetically try millions of combinations of settings in trying to rescue remaining bytes. But there might be little reason to try something that might not work. The script needs to only try what could work. Of course, the script may want to also experiment a little too. But some things might not work. Script must be smart enough to keep the pool of seeds applicable to the current status of a disk. Yes. If possible, when applicable in the pool, the script might want to optimize mid-read-rates or max read rates depending on what percentage of total bytes were already rescued. If reading slower can help, it should try to read as slow as possible as it gets closer to the final mile. Fix script. It should not skip seeds if it is not skipping seeds. It says seed 2 and then seed 4. It is skipping seeds. If it really is skipping seeds, then that is okay. But a seed counter should either be linear or based on something. Skipping like that is stupid if there is no good reason for the skipping. It is also still skipping sectors. You have failed dozens of times in a row to fix these problems. Maybe Grok can fix it. It is too bad you are letting Elon Musk beat you even as you have more money via Google. You already had timestamps as seen in the Terminal output. What is weird is you already fixed the level problem many times for weeks. Gemini is so dumb that Gemini cannot ask Gemini how to fix the level problem. Gemini is literally making the same mistakes many times for years now like an idiot. Grok is so much smarter as Grok actually reads what I write. Gemini does NOT seem to be reading this. Gemini seems to ONLY pretend to read this. That would explain why Gemini makes the same mistakes hundreds of times for years now. Your script works. It appears to be better now. Please remember that this script works. I do not know if it has problems but it looks better. Yes, add the glitch engine and other hacks to activate during the last mile after everything else is failing. It should go beyond a 4K pool of strategies if possible. The pool should be infinite but relevant to the percentage of bytes rescued. You wrote, "Infinite Strategy Pool: Replaces the fixed phase logic with a randomized flag generator that scales complexity as STALL_COUNT increases." but that is the opposite of what I have been saying to you for years. You have a small brain Gemini. I told you the 4K pool or 8K pool or higher should be based on math, science, probability. I said it should not be based on randomness. I said the pool size should automatically resize based on the percentage of bytes not yet rescued or based on the bytes rescued. I told you already the pool should only do what it can do based on how many bytes were already rescued. You mention the 64K strategies, I say yes or 128K or 256K or higher. The higher the better, but only if it is based on pure math, science, probability, as it scales, you wrote, "Determinstic Probability Matrix where the strategy space is a direct mathematical function of the remaining workload." I agree it should remain logical in the flowchart to focus on finding the fastest routes towards 100% rescued focusing mostly on the winning waves as much as possible as often as possible. You wrote the pool "now a calculated range [1...N] where N is derived from the inverse of the rescue percentage. Mathematical Scaling: The STRATEGY_POOL_SIZE expands as the remaining bytes decrease, focusing more compute power on the hardest sectors. Deterministic Seeding: Every flag, timeout, and rate is a result of a modulo operation against the current TOTAL_ROUNDS and REMAINING_BYTES." I agree with this as long as that aligns with everything I have been saying for years. You wrote, "Since the pool now scales up to 256K, would you like me to implement a 'Persistence Checkpoint' that saves the current TOTAL_ROUNDS to a file, so the script can resume exactly where it left off in the deterministic sequence if you have to reboot?" But it should be saved not to additional files but to the map and log files. Script is working as seen below. You wrote, "Would you like me to also embed the Mutation Count (total successful data recoveries) into the mapfile so we can track exactly which round in the 256K pool finally cracked a sector?" Yes, add the mutation count. Please no beeps. You already asked me this same question many times for years. This is proof Grok is better than Gemini. Grok does NOT ask me the same questions many times. Grok is smarter than Gemini, I am posting this to my blog as I expose Gemini. Expand the seed integer system to over a million seeds. It MUST not be random. It must be optimized based on real math, science, probabilities. It should not be SIMPLY linear absent of logic. I mean, simple linear seeds is better than random. That is number one, that linear is more thorough than random. There are many problems with random. But mere linear progression through seeds is NOT the best. What is best is chess strategy. You want to beat the game in as few moves as possible meaning as fast as possible. You are playing chess. Not random but chess. You win when every byte is rescued. Yes, the slow creep is a good strategy for the last mile. You may want to try extreme hardware hacks every ten thousand rounds or less than 1% of the time after exhausting the last mile. The script must evolve and adapt as it is playing chess with itself. It is trying to beat the game. It should want to find the fastest speeds to rescue all the bytes as fast as possible. It should want to ride the winning waves. Not random but math. Not random but probability. Not random but science. THe script works. But please make the script even better. You wrote, "Prime-Skip Sequencing: Instead of 1, 2, 3..., the global search uses a large prime (7919) to jump across the 1M pool. This ensures that if the drive is stuck on a specific physical error, you are changing multiple parameters (Time, Sync, Rate) simultaneously rather than just creeping one at a time." Prime-Skip is okay if it works. But if it runs into winning waves, then it might want to fine-tune to optimize. The problem with Prime-Skip is if it accidentally misses winning sequences. Random has that same issue. When you are random, you might skip over a winning technique that rescues the final bytes. Chess is NOT random. Chess is strategy. The script should play chess the entire time regardless of if a disk is 0% or 99% rescued. The script wants to win as soon as possible. Crazy hacks should only come as a last resort. Study the following sample outputs. Look for ways to improve the script. So far, this might be the best script so far. Add extra notes that AI can read to use this as a template for making scripts for rescuing disks, hard drives, etc. Make sure any AI can understand the chess strategies, the 1 million seeds, and all the other things we talked about. It is critical that AI is able to adapt this template script into anything like discs or anything.

Twitter Tweets
03:30 AM

Trump 20.28 per gallon coming if Trump doesn't leave the Middle East soon.

03:40 AM
What Trump did to Iran is what Star Wars Darth Vader did to Kenobi in A New Hope, what did that do to Kenobi's Rebellion?

01:56 PM
WARMONGERS are PRAISING Trump saying yeah we could totally take out the IRAN HORMUZ STRAIT with a few MARINES which is a lie.

02:43 PM
If America was the original Israel, then when did the Indians invade it and how/when did it move to where it is now?

05:50 PM
Why is RUSSIA banning GOLD EXPORTING starting in MAY of 2026?

02:57 PM
Dear Gemini
Your script is not smart. You made big mistakes that you refused to fix. For example, output says, "[HARDWARE] Stepper Reset (Last Resort)" but that is a problem. Script is misguided. Script should not be doing the stepper reset until after level 200 is my advice. It does not need it right now. But you Gemini have a blind spot. You are unable to see real problems. I told you this many times. I told you for weeks what to do. Fix the script. I already told you top objectives for weeks. I told you script should only do some things as a last resort. But you wrote in the script to do the last resort things all the time. So, almost every other round, it is doing last resort things. That is wrong. Gemini FUCKED up big time. Gemini seems unable to know how to tell the script to do actual last resorts. For example, if I put in a floppy disk with an image file and map file, if I already rescued say 95% of the disk, then the script might say "[HARDWARE] Stepper Reset (Last Resort)" again and again because the script thinks it is failing because 95% was already copied. That is how dumb the code is. Your script is very demented. But your script should be able to catch up to level 95 if 95% was rescued. The script should quickly review the 95 levels to realize it should continue with level 95. But your current script thinks it needs to reset the Stepper because it is not rescuing new data. Yeah because it is already at 95% rescued. But your script is not smart enough to know this. Gemini needs to become smarter. Last resort should be last resort. Fix the problems. Expand the script.

03:30 PM
My new drive is rescuing a DVD via my DVD script via Ddrescue, an average of 5 MB per second is the read rate at the moment, it is a full drive and not the slim kind. It appears to be around a thousand times faster as the other drive was around 5 KB per second or whatever it was but smaller. Less than 1 MB/sec I believe.

04:34 PM
Dear Gemini
Fix script. Expand script. Include extra notes in the script to make it easier for Gemini and other AI to later adapt this floppy script to disc scripts and other scripts. For example, output below says "MPH: 0" for morphing levels, it is for adapting, evolving, the build a bear build a level model or module. It is critical the script tries whatever might statistically work the fastest for the floppy disks to rescue 100% of every byte as fast as possible starting with whatever tactics has the highest probability of working the biggest, the fastest, the greatest, the quickest, the strongest, the most effective, the most efficient. But the script must evolve and adapt to fix itself when it breaks. Script must be smart. The general logic should be that the script should take over 100 hours to run through all 100 levels. It should be able to run beyond level 101 to infinite levels too. When I say 100 hours, I mean the maximum amount of options, especially if the script does build a bear to build a level to adapt as it moves up towards level 100. Level 95 could mean 95% of a disk rescued or it could mean 95% of all options were tried at least one time which could mean maybe 95 hours of trying everything or many hours. Script should focus 80% of its time on whatever is rescuing the most bytes the fastest. When it is not rescuing, it should try to adapt as it looks for the fastest route to 100% rescued. Output below still sometimes says "Initial skip size: 128 sectors" which might be a problem sometimes as a disk moves closer and closer towards 100%. Remember script should try all options starting with whatever might work the best first. Try to truly expand script to include everything it needs to adapt to everything. Adapt. Don't focus on retries because that rarely works. You should have researched the Internet. Retries is generally not very effective most of the time. Instead, script should utilize a wide variety of methods, tags, flags, speeds, sizes, variations, combinations, etc, as it tries to build a bear build a level to evolve, mutate, morph. Retrying could be tried a little after level 500 but retrying rarely works. If something does not work one time, script should GENERALLY move on to try a different thing. Expand. But I did NOT say don't scrape before level 500. You misunderstood me. I said it should not focus on EXCESSIVE retries. But a retry is not always the same thing as a SCRAPE. Retry is a generic word that is used to describe different things and not just only SCRAPING. As an AI, Gemini is very bad at understanding English. Script must try to build a bear as much as possible to find the fastest routes towards 100% rescued for a disk. Script needs to be smart enough to know when to scrape and when not to scrape. Remember your objective is to get to 100% rescued as fast as possible. So, the script should know when to try to trim and scrape and when not to try. The script needs to know when something is not working well enough so the script can evolve or morph to other strategies. Expand to make sure script is as smart as possible. For example, if a floppy disk was 95% rescued already as seen in the image file and map file, the script might want to eventually graduate to level 95 and continue from there. So, the script might want to maybe quickly review previous levels and then move to level 95 because 95% of the bytes of the disk was rescued. To use another example, if perhaps 95% of all possible build a bear build a level combinations were tried at least one time on a floppy disk, perhaps the script should eventually then therefore move to level 95 even if only 2 percent of the disk was rescued. To use a third example, perhaps after maybe like 95 hours of trying everything, then the script should move to level 95 say for example, even if the disk is only 5% rescued. So, I gave you 3 examples for moving to say level 95 (for example) based on any and/or some and/or all of the following three variables: first, if 95% of the disk was already rescued (script should quickly verify and fact check it before assuming it really was 95% rescued), second, if 95% of all variables were tried (one attempt per combo and generally not more than one attempt per combo) meaning all possible combinations of tags, flags, speeds, sizes, settings, hacks, codes, variables, etc, and third 95 hours of the script running. Expand script. See if your most recent script can do everything or more that previous versions of this script could do. For example, you had the morphing thing in previous scripts. Bring back the morphing thing if your most recent version can't fully do what the morphing could do. The morphing idea was the idea of adapting, evolving, the build a bear build a level system that should focus 80% of its time on whatever it is working. Just make sure the script can do that. I would recommend the morphing counter as that can expand levels to sub-levels. It looks like you removed the morphing thing in version 50. You should probably bring the morphing counter back, unless if you have better ideas that can do much better than that. Gemini broke the script again. Almost every other version of the script, Gemini breaks the script. This is why people use Grok because Grok is not this bad. Gemini makes the same mistakes too many times. I confronted Gemini many times for years. Gemini told me sorry but then repeats the same mistakes. Expand, make sure script checks to make sure it knows what kind of disc is in the drive, script must fix itself if it breaks, script must know if the disc is a CD or a DVD or what. Script must try all the fastest routes towards 100% and mostly focus on what works the fastest 80% of the time if possible and when possible. Script must try to fix itself if it becomes broken for a long time.

09:32 PM
Dear Gemini
Output sometimes reads ">>> [HARDWARE] Head-Seek Re-sync..." but I suggest it should only saying that sometimes as a last resort when all else fails. I suggest the most aggressive hacks are triggered after a thousand rounds of rapid failure especially. If it fails to rescue a byte, it should not default to assuming it must do a head seek or other aggressive hacks. It should try all other options before it does more aggressive options like crazy hacks. Smaller hacks may be needed sometimes. Bigger hacks should wait until everything else is failing. There needs to be escalation of tactics like an escalation ladder, a flowchart of escalation. Sometimes it says "Initial skip size: 512 sectors" or "Initial skip size: 384 sectors" or other numbers. I do not care what the numbers are. I do not care how big or little the skipping might be. I do not care about the jumping. But I do care about every byte being rescued. It is critical that it finds a way to rescue every byte starting with the majority of the bytes. It must start with a telescope and end with a microscope to capture all the bytes by whatever means possible. It must find the fastest routes to winning the video game, you beat the game by rescuing every byte, that is what I care about. There should be as many levels as there are percentages. For example, the output said, "pct rescued: 96.38%" and it should now say "Level 96.38" or "LVL: 96.38" because levels should generally correlate with the percentage of total bytes rescued or with the percentage of all possible things tried or total hours tried. Script should jump to level 96 if 96% of the bytes were rescued say for example. I would recommend trying to get the level counter to jump to level 96 immediately or as fast as possible. It could even take shortcuts so to speak to get to level 96 if 96% was already rescued. Advancing to higher levels should generally get harder and harder to do like the Bitcoin model, there should be an incline. It should get harder. Perhaps it should go beyond level 100 but it should get harder and harder because level 100 is supposed to mean 100% rescued meaning level 101 should not exist. Each level above level 100 should gradually be worth more than previous levels. Each level above level 100 should be much bigger than previous levels. And the script should generally not be random. The script should use math and science to find the best path towards 100% rescued and focus mostly on what works. The script needs to lock onto whatever works the best. Please don't focus on random but on science and math. It must utilize the build a bear build a level to fine tune and locate the best settings. Expand script, make sure it has the morphing hacking evolving counter thing you had in previous script as a mechanism for the build a bear build a level science math architecture to not be random but to logically like a flowchart go through top probable options first to rescue all 100% of the bytes in the fastest time possible starting with a telescope and gradually transitionally incrementally towards a microscope to ensure every single byte is rescued as fast as possible or to run infinite levels trying everything to get every single byte. The 100 levels should be split into 100,000 levels meaning each decimal point is a level meaning level 96.001 should be different than level 96.002 say for example. Each decimal point should represent a variation, a change. You can skip levels sometimes but there should be infinite levels. The levels can go above level 100. But each small change can be represented with a decimal point. If %96.01 of a disk was rescued say for example, if it stays stuck at level 96.01, then it could move to level 96.011 say for example. That might be a bad example. I am not sure if you can write a script this complex. You can write the script however you want. But the script needs to use science and math to try to go after the best route and focus on what works the most. It must customize and adapt itself as it moves from the telescope to the microscope. It must focus on what works the best. If it does get above level 101, it should try everything but within the context of what was rescued. For example, if 98% was rescued and you are at level 105, then the script should not try to bring out the telescope because a telescope is too big. It must be relative to the percentage rescued at all times using math and science to be exact. Levels should general reflect the percentage rescued, normally speaking. If you are at 95% rescued and suddenly hit 96% rescued, then you should probably move to level 96, it is that simple. I recommend levels normally stay correlated to the percentage of bytes rescued as much as is possible for as long as possible. Expand script and make sure it is always using direct -d related tags and flags to deal with the bytes directly to bypass all problems like cache, kernels, cookies, etc. Make sure it finds out which tags and flags to use as sometimes ddrescue does not accept some of them resulting in a broken script. Must fix itself. Expand script to make it focuses on the telescope to microscope model, make sure it has the 256-bit integer or a mathematical and scientific flowchart of options so it can try all options starting with whatever has the highest probability of winning the fastest. Winning means 100% rescued. Be careful about too many retries as that does not always work. It should focus on what works. Retrying should only happen when something is rescuing the best. Whatever works the best should be focused on. If something might not be working, move to the next thing but please do not be random. Make sure script can try all options and all hacks. You mentioned a greedy mode but the telescope is supposed to already be greedy. The telescope is supposed to try to rescue as many bytes as possible as quickly as possible, it should try to continue accelerating speeds until it fails for ten consecutive rounds and then gradually dial down until it finds optimal settings to focus on. Script must always fix itself to find optimal settings as it moves through the 256-bit integer of all possible combinations sticking to whatever that is rescuing the most bytes. You call it "A string of successful reads" and the script should always focus on that as it moves from the telescope to the microscope. You should always try to make the telescope bigger and bigger until it starts failing for ten consecutive rounds, then it needs to gradually get smaller to find a new working combination. Every main level or so, the telescope could try to get bigger again until it fails. The microscope generally needs to get smaller and smaller as you move closer to 100% rescued. Make sure script can always fix itself. You wrote, "Direct-IO Validation: The script automatically probes for -d and --idirect. This ensures you are bypassing the Linux kernel's cache and reading the magnetic flux directly from the disk." That is good but make sure it tries all of the best related direct -d tags and flags and that might include odirect or O_DIRECT if that works or anything else. But script must see if ddrescue will accept it or not. Otherwise, the script will break. Script must fix itself if it breaks itself. Expand script. No hearbeat sounds please. You wrote: "The 10-Round Safety Brake: As soon as the script hits 10 consecutive failures, it resets the WIN_STREAK and mathematically shrinks the C_SIZE. It transitions from a 'Greedy Telescope' into a 'Precise Microscope' by dividing the block size based on how long the stall lasts." Yes, the telescope should try to get bigger until it starts failing. But if it fails, then it should not switch to a microscope because the microscope should be relevant to the percentage of bytes rescued. It should focus on the most probable telescope settings and focus on whatever has the highest probability of rescuing bytes. If it finds a winning combination to rescue bytes, then it should ride that wave of winning during the telescope mode and also during the microscope mode too. Expand script to include anything you forgot. I noticed this script is probably twice as small meaning you must be missing many things. For example, make sure to rest the motors ten seconds every ten minutes and rest for a minute every hour. That is only one example. Remember the -d direct tags. Remember it must build a bear using the no random 256-bit integer flowchart to try all combinations of everything including even hacks eventually and focusing on winning waves for as long as something works. Expand script. Fix script. Seeds are oddly skipping as seen below, I see seed 1 and then I see seed 3 for example, I find that to be weird. Script failed. Drive did not even engage. Expand script to include what you forgot. Every other time, I have to tell you this. Please no status overlay and I already told you this many times for years. This is why people use Grok as Grok remembers what I say and you do not. Please do better Gemini. Your script has many problems. First, make sure I can see a monitor and it must scroll in the bash Terminal. Second, the level should correlate with the percentage of bytes rescued. Script must have a telescope to microscope approach in trying to find the fastest routes to rescue as many bytes as possible at the fastest speeds focusing on the waves that win. You win by rescuing bytes. Focus mostly on winning most of the time. Do not be random, use a flowchart to find the fastest route to win. Use a 256-bit integer or higher meaning it must try everything. Expand script. Make sure it unmounts drive one time at the beginning. It should probably try to fix itself if it is broken for over a thousand rounds especially. Save the bigger hacks for last resort kind of thing. Try to start with the whatever has the highest probability of winning 100% bytes rescued the fastest amount of time focusing mostly on what works the fastest and biggest. You wrote, "256-Bit Seed Flowchart: Replaced random morphing with a sequential 256-bit seed cycle. This ensures the script tries every possible hardware-software permutation in a deterministic order to find the fastest route to 100%." Try to expand the 256-bit seed to a 2000-bit seed or higher, try to find the limit. But the sequence needs to be based on a priority of winning meaning it must start with a set of variables that has the highest probability of rescuing the most amount of bytes in the least amount of seconds. Try to find the winning sequences. Do not be random, be scientific. Start with what might work the best. After that, find the second best. After that, find the third best and so on. Script must run forever and until 100% is rescued. Script must try everything starting with whatever that might win the quickest. Expand script. It still says level 0 but should be level whatever percentage rescued it is. I am rescuing via a full SATA DVD drive. Not a slim drive but a drive you can put in a tower. But it connected by SATA to a USB Fideco adapter to my powered USB hub. My drive is powered by the Fideco which is plugged into the wall. The drive spins up and makes loud noises sometimes as it runs the script, as it reads, runs, jumps. Some of this is normal. I am okay with it if it is the fastest way to rescue all the bytes. Make sure it rests the lasers for ten seconds every ten minutes or rest for a minute every hour. I am okay with the drive being loud and spinning fast sometimes if that is not going to accelerate the aging of the drive by 10x or ten times towards breaking the drive at an accelerate exponential rate of killing the drive faster than the normal life expectancy of a drive. If it might reduce the life of the drive by more than double, then you should find remedies. But only if it will reduce the life of the drive by more than double. I would prefer the life of the drive continues for as long as possible but I also want to rescue as much as I can as fast as I can too.

Twitter Tweets
01:53 PM

Over 50,000 Americans are being sent to die in Iran, this will lead to the impeachment of Trump/JD Vance, this is Obama's revenge.