Occasional "No Index" when rereading floppies an obscene amount of times

[seal331]

Hello there, have been using my Greaseweazle F1 to dump all sorts of floppies for ages, great work on the device!

Recently I got a massive haul of various Novell floppies, which sadly time haven't been kind to. I've been trying to save a specific set for quite a while, but what I presume to be a bug is complicating everything.

From personal experience (Disk 2 of this set had a track which would have 14/18 sectors read reliably each time, and that track did give up after 13 hours of hammering it with a script I wrote to work around the bug), if the disk isn't already totally broken, those bad sectors can still be read if you read them enough times. If this were a perfect world, I would specify an utterly unreasonable amount of read attempts and just go away from the drive for a day, but there seems to be either a bug with the Greaseweazle firmware or a hardware fault with my drive, which exhibits itself in the following way:

After a random but very large amount of read attempts (most of those crashes I wasn't there to witness and I didn't have time to fix my hackjob logging system yet, I think I know why it is writing out empty files but I didn't have time to adjust the script), the Greaseweazle software reports "Command Failed: GetFluxStatus: No Index" and promptly exits. The lowest I've seen this happen at is somewhere inbetween 800 and 900 read attempts, and the highest I've gotten before crashing is somewhere inbetween 1100 and 1200 attempts.

This is starting to be a massive pain to deal with, because while I have already wrote the script needed to hammer the disk, if we get one successful read of a sector that's barely hanging on and then the software crashes, we have to reread that sector again, which can be, in the best case, extremely time-consuming.

The command I am using to read the track in question is "gw.exe read --format=ibm.1440 --raw 00.0.raw --tracks=c=11:h=1 --retries=1000000".

I am still using Host Tools 1.16.1 with firmware version 1.4, so if it's a known bug that has already been fixed, please let me know and sorry for wasting your time!

[seal331]

I have bought a second drive and the same issue still occurs, so I'd say this isn't a drive problem.

[keirf]

Obviously to be tracked down, but why not script up calls to gw in batches of say 1000 revolutions? Scrape the output to find when the sector is successfully read, and silently drop invocations that trigger this No Index bug.

[seal331]

Obviously to be tracked down, but why not script up calls to gw in batches of say 1000 revolutions? Scrape the output to find when the sector is successfully read, and silently drop invocations that trigger this No Index bug.

At first, increasing the revolutions seems to be decreasing the amount of read attempts I get before the bug occurs, and second, the resulting flux file doesn't get written out when gw.exe crashes (neither do we get any sort of a list of read sectors, we only get a general x/18 sectors). Either way, I have implemented a very hacky workaround (it basically consists of "on No Index go through the entire board reset procedure except clearing the buffers"), which does help but drastically decreases the already-slow disk reading speed, because the board has to be reset after every single read closer to the end. Thankfully, I have managed to save the disk, so the torture is over :)