12:11 AM

1. Help me with Jordan or merge Jordan with other protocols.

2. Help me with that.

3. The problem is both the Oatmeal Rounds and regular rounds had similar or identical results. Bill should only activate Oatmeal Rounds if they're at least 2X faster. If a regular round is rescuing bytes at 2 MB/s, then Oatmeal Rounds must be rescuing at a minimum of 4 MB/s to be worth switching. Recently, they were both the same or almost the same in results.

4. Fix it

5. Rest lasers for ten minutes after Bill is running for an hour, clock starts when Bill starts.

6. Merge Jordan or fix Jordan or something.

Sonic Protocol
The Sonic Protocol is the new overriding protocol that runs Sonic at the beginning of each session. Sonic must override protocols that might interfere. Before Bill can run, Sonic must perform two quick passes. First, Sonic must perform Sonic 1 through all remaining non-rescued bytes. Second, Sonic must then run Sonic 2 through all remaining bytes. After that, Oatmeal and Jordan and Phil and all the other protocols can help Bill continue what Sonic did to finish rescuing all 100% of the bytes.

Sonic 1
-c 1 -a 25M -T 5s -M -A -n -N -r0 --cpass=1 --no-trim --no-scrape -K 64KiB -b 2048

Sonic 2
-c 32 -T 5s -n -N -r0 --cpass=1 --no-trim --no-scrape -b 2048

Sonic Protocol
Sonic must do two runs. First, run Sonic 1. But second, after that, run Sonic 2. Run means pass. But pass is NOT just a round. A pass means to run through all remaining bytes. If the Timeout flag interrupts a round, that is NOT a pass. A pass is when you scan through all remaining non-rescued bytes. First, run through all untried bytes. Run through trimmed bytes. Run through scrapped bytes. But scan only. No trimming. No scraping. Sonic must try to pass or run or probe or read all remaining non-rescued bytes during Sonic 1 and Sonic 2. That means potentially thousands of rounds or one big long round.

Housekeeping v Progress Protocol
Bill must finish full passes (runs through all remaining non-rescued bytes). Housekeeping and other Refresh Protocols should only clear cache or anything that might cause the error rate to increase. I've talked for months about this need to get over issues with say the disc drive's firmware getting locked up, we dubbed them the cops. I wanted to re-mark sectors or bytes on the map between passes or at the beginning of sessions or at certain times. But right now, I'm worried that Bill is struggling to complete simple passes through all the bytes. Progress must be made. This is a bit of a paradox. Can progress be made if Housekeeping never fixes problems? The other question is, does it matter if Housekeeping keeps Bill in a Loop-State unable to fully complete passes?

Continue Protocol
The Continue Protocol forces Bill to continue across sessions. In the past, I demanded Session Resets. But I've decided to discontinue that. Please terminate Session Resets. My concern was Bill might get stuck if sessions didn't reset. Currently, I want to override Session Resets. The Continue must make sure Bill can continue. I still like to sometimes retry bytes eventually. But right now, my desire is to quickly make sure Bill can at least run through all remaining bytes before attempting additional passes down the road. Turn off Session Resets. Don't turn off everything, only turn off the Session Resets that might re-mark bytes to untried per session. If I ever finish a full pass resulting in 0 untried, then Bill will need to do something. But at the moment, it is critical to simply get to the end of one simple pass. A healthy disc can finish a pass in under five minutes. Sonic was supposed to help Bill finish a pass in record time. The Continue Protocol must make sure sessions are no longer reverting remaining non-rescued bytes back to untried bytes per session. But after there is 0 untried, then Bill probably should do something. Continue can help Bill continue if there are untried bytes and if there are 0 untried bytes. Continue must make sure Bill can run fast enough and hop far enough to get over scratches and slower spots. It's critical to get over bad spots that can lock up the disc drive.

11:54 PM
I use AI all the time. But remember that AI is often very broken. But Gemini said each day for months there is. Right now, Gemini is saying done is the last word. But each day Gemini says that is not true. Gemini is arguing with Gemini. That is bad. There is nothing after done. Nothing. But Gemini always says there is. But there is not. Gemini was wrong each day for months. Gemini refuses to stop. It is too bad Gemini has no memory. If Gemini had memory, Gemini would stop it. If Gemini cannot remember anything, then Gemini cannot stop. if i did it, why would you tell me to do it even after i tell you i did it, and then respond with okay now do it, but i already said i did, and then you say okay now do it, but i said i did and yet you act like i did not.

Twitter Tweets
12:31 PM

We told you 2 months ago Iran is the new Covid as 70% of Americans live paycheck to paycheck.

01:00 AM
MPH Protocol
The independent speed MPH Protocol regulates Bill's speed in any zone, mode, run, pass, level round, world, or whatever. MPH must be designed so Bill can go any speed at any time. But at the same, there must be default routes where MPH goes from fastest to slowest. Gemini usually says the top speed should be 25 MPH which is 25 MB/s. My disc drive is labeled as 16 MB/s but 25 MPH might push Bill over bad spots during earlier rounds. Sometimes, Gemini says 100 MPH might also help. I don't know what to believe because Gemini is often wrong about everything. I don't know how much MPH affects Bill as it often seems Bill goes at whatever speed Bill wants to go. Also, sometimes my drive might be being throttled by cops and stuff. If possible, I would love for Bill to match the MPH to whatever speeds the drive went in the previous rounds. But then again, I don't know if that is a good idea. I think for most flags, including the MPH -a flag, the 80/20 rule apply, generally speaking. The 80/20 rule is twofold. First, stick with the highest settings possible during the first hour of rescuing a disc. Second, to focus on what works the best 80% of the time. A perfect disc can be copied in under 5 minutes, that's around 17.07 MB/s. Other discs, under an hour which is roughly 10x slower. Assume that almost 20 MB/s is the gold standard. My drive is capped at 16 MB/s tho. If copied in an hour, that might be roughly 1.4222 MB/s. 20 MPH is the best. Anything above 2 MPH is good. The MPH Protocol must push Bill to max speeds, especially for the first 80% or more. Eventually and/or as things continue to slow down for many minutes and/or many rounds, especially rounds under 2 MPH, the MPH Protocol might sometimes experiment or try different tactics. For example, the first tactic is the highest MPH possible. Another tactic might be lower MPH. Another might be an average which might be around 10 MPH. Another might be to match whatever speed the drive is going in an attempt to finish the current pass through all bytes. It may or may not be best to raise and lower MPH. Sometimes it feels like MPH might have little power as you get closer and closer to 100% rescued. Therefore, it might be best to keep MPH at max until 99% rescued or until it seems max MPH is doing more harm than good which still might be very hard to determine if MPH is being too counterproductive or not. Build me a template with enough MPH speed options from max speeds to the lowest speeds which even include -a 0 as the lowest speed that I know about right now.

Cluster Protocol
The independent Cluster Protocol must push Bill to focus on the largest cluster sizes possible at first and/or whenever it might help. I recommend including a 128K, 64K, 32K, 16K, 8K, 4K, 2K, 1K, 512, 256, 128, 64, etc, down to -c 1. Must be independent. Must try to do the largest ones at first and whenever it is needed. Bill must know what is needed. Sometimes, higher sizes might not work. There must be a way to quickly see if a crazy high size might do something for a short time. But then eventually Bill needs to lower the volume as too high might be a waste of time sometimes. Especially during the first 80% rescued and/or for the easiest bytes, Bill is encouraged to try for max speeds, max clusters, etc. Perhaps the Housekeeping Protocol might help with keeping things clean. A lot of things can go wrong at any second. Bill might even think a crazy high cluster size is working but it might be just ghost data from cache, RAM, CPU, GPU, etc. So, Bill must be smart with finding the Goldilocks Settings for Clusters, MPH, Mario, etc. Especially for the first 80% or for the easiest bytes at least.

11:46 AM
Default Tiers
Bill must loop levels. Each level must have infinite levels. Bill must attempt multiple tactics to complete each pass. But a pass is a run or probe through all remaining non-rescued bytes. After a pass, it should say 0 untried bytes during the Scan Modes. Bill must try very hard to complete full passes via Mario, MPH, and different tactics when possible. Bill must hop over scratches. Bill must try to run all over the disc during passes. Eventually after trying everything for a long time, the Stall Protocol might push Bill to other levels, etc. Bill must loop in worlds too. The hierarchical tiers goes rounds, levels, worlds, modes inside the Scan Loop or some of the tiers can be added or deleted or altered depending on what is needed. But Bill should not switch to Trim until trying many different levels, worlds, rounds, Scan Modes, etc. Bill should first try everything to finish each pass. Each level represents a pass. But each level should be unique. Bill must try different things. Bill must by default loop forever until it is time to switch.

Timeouts to Risk Ratio
The default must be the higher the risk, then the smaller the timeout. Speed might minimize risk normally. The larger the cluster size, the higher the probability of risk which means timeouts should probability be minimized at first until it is proven that it is working. But generally speaking, timeouts are supposed to help protect Bill from risks. Some things might increase the odds of risk. Like running into scratches and bad spots. Increasing jump sizes might decrease the probability of risk for example. Timeouts can help extend rounds which is sometimes good if it is working but dangerous when it is not working as well.

Direct Protocol
The independent Direct Protocol must sometimes use the -d --idirect related flags to help Bill when Bill really needs it the most. The Stall Protocol, for example, could trigger the Direct Protocol. I was able to rescue almost 80% of a disc in about an hour without -d which means -d is not always needed. Bill must try -d out. Bill can turn -d on and off at any time when other tactics are not working. If -d improves performance (The Goldilocks Rescue Protocol), then -d could continue to be used when it is needed the most. Not just the -d flag but also -R and -O and maybe even Error related flags and maybe even -J. Tho -J might be less likely to work. But Bill can try different flags to see if they improve performances when Bill is struggling. Especially when below 2 MB/s before 80% rescued. After 80% rescued, it might be more normal for speeds to drop under 1 MB/s and that might not be the worse thing. But Bill can still decide to try things out when needed and to use whatever works the best. The Direct Protocol must be independent of other tiers. Bill can use the Direct Protocol whenever Bill needs it the most.

08:06 PM
Dear Gemini
Gemini wrote, "To fix this so Bill actually listens..." But I didn't say Bill doesn't listen. I said Gemini doesn't listen. I said Timeout should begin small and gradually get bigger. Gemini translated the word "GRADUAL" to mean two things. First, a one second timeout. Second, a one hour timeout. That is NOT gradual. But that is what Gemini did. That is proof of how bad Gemini is. This is being posted on my blog.

List of some of the problems:

1. Bill failed to decrease Clusters Size (-c 131072) after that first round. If Clusters are too high, turn it down to -c 64K the next round. After that, 32K. And then 16K. Find the Goldilocks Settings. Gemini used to say 2K was the ceiling for cluster. Then Gemini said 4K. And then 16K. Therefore, 131K is probably not going to work. Anything above 16K should only be tried one time per session. 8K might work a little sometimes. Usually, Bill does better when clusters are below 2K.
2. Bill might be stuck on a scratch.
3. Bill decreased jump sizes but it is better to increase to hop over bad areas. You decrease after rescuing a lot of bytes. When you struggle, then you increase jump sizes.
4. Bill failed to activate -d and/or any flag that might help.
5. Bill did not really return to normal rounds. It looks like Bill was stuck in Oatmeal Rounds and was unable to escape it.

11:40 PM
Gemini is bad at writing code.
Here are some of the many problems:

1. It went from -c 131072 clusters size by 50% per round (which is good) but then looped back to 131K for no reason. If 131K produced 50 MB/s, that would be a great reason.
2. It always seems to say "TARGET: 0x110008000" or at least lately which might be a scratch, a loop, if it is not able to complete a pass.
3. It says -a 100K and it also sometimes says -a 75K.
4. It says -d every single time which means it is not even trying. It should turn -d on and off to see what works. It did not work with -d. Bill should have turned it off realizing it did not work with -d. If Bill was still stalling, then Bill could have turned it back on. Same thing with any flag, really.
5. You are missing the cpass flags which I want for many levels or at least until all the easier bytes are gone. I prefer cpass until 99%.
6. Jump sizes should increase if stalled.
7. Why not try Error flags sometimes?
8. Why not try many different flags when stalling?