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?

12:20 PM
Dear Grok
Expand this Bill script.

Each level should be unique.

One variable that can change per level could be MPH.

MPH is the speed.

MPH can start at the highest speed which might be -a 25M according to Gemini. Higher numbers might sometimes push Bill to try harder for a few seconds said Gemini. But Gemini started to say 25M was a good number for the highest speed.

Add MPH to a level system.

Or add MPH to an escalation MPH system that is independent on levels, rounds, etc.

There could be other flags, variables, etc, too.

And -c 32K seems good. I wonder what 64K would do.

Look at all flags.

Look at expanding stuff.

After like 80% rescued, 32K and some of the higher flags might not work as well. As long as the Stall Protocol can push Bill to the next level fast enough, then Bill might find a Goldilock setting even after 80%.

The challenge is to not push Bill too hard during the first roughly 80% or higher as many discs might be rescued in under an hour at the highest settings meaning you may want to let Bill run if Bill is on a winning wave or even if is accelerating even.

Looping, Stalling, Graduating
Bill must loop if not stalling or graduating. Switch level if stalling or graduating. Bill must loop from level-9 to level-0 if Bill is not stalling or graduating. Stalling means if stalled for too many consecutive rounds. Graduating means if an entire pass (run/probe/read through all remaining non-rescued bytes). If Bill isn't stalling or graduating, Bill must loop levels, worlds, modes, and loops. Bill should graduate each level before switching worlds. Bill should graduate each world before switching modes. Bill should graduate each mode before switching loops. Bill should loop inside the Scan Loop until Super Stalling or Super Graduating. After the Scan Loop should be loops for Post-Scan modes like Trim, Scrape, Crawl, Reverse, Retry, Chaos, Merge, Fill. Nine loops if you include the Scan Loop. It should be very hard to stall or graduate from Scan Loop to Trim Loop because most discs can rescue over 99% of all bytes inside the Scan Loop. Each loop can have modes.

Bill must return to level 0 per session and pass. A session is started when Bill is started in the Terminal. Stall counters must reset per session and pass. A pass is when Bill runs/probes/reads all remaining non-rescued bytes.

06:47 PM
Dear Gemini
You wrote, "Near the top of your while true; do loop, you have SWITCH_REQUIRED=true. This causes the script to reset itself every single time." I wanted the Switch to loop per session and pass. A pass is when Bill probes or runs or tries all remaining non-rescued bytes. A Session is when Bill is started in the Terminal. I wanted Bill to graduate a level if Bill stalls or completes a pass. The purpose of the Switch was to do a new pass via a different level, world, mode, etc. I was trying to get the Switch to do a quick fast speed run at the start of a new pass via different settings. When I said Apples to Apples, I was talking about Gemini. But Gemini lied and said it was about my script.

Goldilocks Protocol
The Goldilocks Protocol demands Bill do two things. First, Bill must start in Goldilocks. Second, Bill must return to Goldilocks. That's it. Goldilocks are winning flags. Bill must assume the highest settings have the highest probability of winning the most bytes most of the time. However, you don't want to be too hot or cold. You want settings that have the highest probability of rescuing all the bytes. That's how you win. Bill must start in it. Bill must always return to it. Bill must find it. Discs are full of surprises which is why finding Goldilocks is like striking gold. It's like winning a game of chess or poker. Bill should adjust settings between each round. If possible, Bill should turn up and down the volume between each round. Bill wants to rescue all the bytes as fast as possible. By default, Bill should follow the established routes of rounds, levels, worlds, modes, and loops. Additional hierarchical tiers can be established if unique and needed. One way to find Goldilocks is by trying each round, level, world, mode, loop, stage, phase, land, chapter, flag, setting, option, variable, number, variation, combination, code, etc. But sometimes, that can take many hours. It's better than nothing but there might sometimes be shortcuts. I am not sure if I know how to write something like this into Bill. Bits and pieces of this protocol exists in Bill already in some ways. But things can always improve.

Warp Protocol
The Warp Protocol pushes Bill to finish the current pass via an escalation ladder. A pass is a run or a probe through all remaining non-rescued bytes. Instead of automatically and prematurely graduating levels via the Stalling Protocol, Bill should first attempt several Warps. Here, the definition of Warp is to accelerate somehow. Depending on how Warp is written, different flags might help. The goal of the Warp Protocol is to find ways to push Bill to finish a pass. The Stall Protocol tells Bill to give up on a level. But Warp tries to find a way to speed through it. I don't know what Bill should do finish a pass. Think about many flags. For example, what if Bill ran faster. What if larger clusters. What if -K jumping was increased per stall. Perhaps Warp and Stall protocols can merge because if Warp fail to push Bill through bytes via different tactics, then Stall should trigger a Level-Skip or you can call it a graduation. Tho, not a real graduation if it was not a complete pass. I don't know what the best ways there are for Warp. Sometimes, it can be tough if it is stuck on a scratch or loop. Warp pushes Bill to run faster to finish a pass (run) before changing tracks. But Stall pushes Bill to run over to a new track. Bill might do better on a different track (level). Some of the protocols might be similar to the Merge Protocol. I've also mentioned Merge in the past. This is a new variation of what I called Merge. I prefer if Bill can react per round. But at the same time, Bill should probably be less reactive during a first pass because many DVDs might be easy, over 80% of the bytes of perfect discs might get copied (rescued) within only ten minutes in only one round. Some might need several rounds. Some might need several hours. Bill should probably step in more and more as it becomes tougher to rescue the remaining bytes of discs.

Jordan Protocol
The Jordan Protocol pushes Bill to win. Jordan might be identical to the Goldilocks Protocol and also the Turtle Protocol. I'm thinking about getting rid of the Switch Protocol either partly or completely. The Switch Round was supposed to be played per session and round. However, I'm thinking about trading Switch for Jordan. The purpose of Switch was to try to push Bill to run through the highest settings. Run means to pass or probe through all remaining non-rescued bytes. Talking about Jordan might be confusing because I've written many ideas about Jordan for Bill. I'm not saying Switch has to be totally deleted. But my idea right now is Jordan could be Phil. Oh wait, I already wrote the Phil Protocol. Named after Coach Phil Jackson. I wrote many protocols. Some protocols overlap. Gemini sometimes forget the many protocols as there were so many protocols for months now. But right now, I'm thinking it might be better if Bill does not always reset per session. I said I prefer to reset per session because it might be easier to design code around a session reset. But to be clear, I still like the idea of retrying remaining bytes via different levels. After a pass, I still prefer Bill performing another pass but via a different level, etc. But on top of that, my current idea is it might be best if Jordan or Phil or someone decides what play to run per session and round. The challenge is making the script too crazy might sometimes prevent Bill from finishing full passes if Phil is having Bill run through a rat maze of levels and flags back and forth which might include looping on a scratch on a DVD. So, I like the idea of changing tactics per round. But that might result in crazy loops of failure which is why that might be tricky to write.

Design Paradox
One of the many challenges is there are multiple ways of designing Bill to be universal. For example, I often design many modes and levels within Bill. I prefer Bill focus on Scan, that's why I started designing four Scan Modes within a Scan Loop in an attempt to prevent Bill from prematurely trimming for example. But one of the challenges is the complexity within hierarchical tiers, because I also like flags being independent of the tiers they're housed in. The difference between level-1 and level-2 could be the difference between -a 20M and -a 15M. But in that sense, the MPH speed is dependent to the level. Gemini remedies situations like that by placing some flags in a separate section that levels can pull from. I might have at least 3 options when designing levels. First option is flags are dependent to a level, like my example earlier where -a 20M is tied to level-1. Second option would be focus less on tiers and more independent flag systems which sort of function like levels but in a different way. Third option would be a hybrid. We've talked about this many times for years. Gemini designed thousands of Bill scripts for months. There are pros and cons between the different systems. I struggle to tell Gemini things as I know Gemini will probably forget it in a few seconds, even tho I turned the memory on so Gemini can remember things. Gemini does remember things randomly sometimes but it's not reliable. Look at the three main options above. Talk about the three options. I still tend to prefer tiers because a default path generally works better than hoping Bill can figure it out via random routes.

Assume Bill continues with a hybrid structure.

Suggest how to keep each tier unique. For example, what makes a loop special, should it even be called a loop? In the past, it was called a mode or it had other names. I created loops to go above modes. I had other names too. So many. By default, Ddrescue has Scan, Trim, Scrape. I believe those are the top 3. You could say more. We already talked about that. I like it if Bill can be focused on Scan for 99% if possible. And then what is a mode. And what is a world. And what is a level. And depending the design, there could be any number of tiers. Most of my focus is on Scan like I said. So within Scan are many flags, settings, etc. I also still don't know if I should have multiple Scan modes or not. Perhaps I will go back to having modes as the highest level where it goes from Scan to Trim to Scrape to maybe a few others. But each tier could focus on a top flag, that might be one way. Even within a hybrid system, a tier could focus mostly on one variable, setting, speed, etc. I like MPH speed as a key variable. I like clusters as another. I like -K jumping. I like -d as another. I like -R. I like -O. I sometimes like error flags if they work. Sometimes, it can be tough to rank which flags and settings might play the biggest role in rescuing data.

Some of the flags as follows:

-c

-a

-K

-d

-R

error flags

-O

do not trim flags

do not scrape flags

re-trim flags

mark as untried flags

-r but I prefer rarely using -r until maybe after 99% rescued normally

c-pass flags

etc