Hey, Mark...

If you had a bad sector in the section that stored the current playlist order on the scratch partition, what would the command be to zero THAT out?

For instance, this command...

dd if=/dev/zero bs=512 seek=4096 count=28672 of=/dev/hda3

... zeroes out the statistics. What would zero out the stored playlists without erasing the EQ data?

I have a bad sector on the scratch partition where the current playlist order is stored. I am planning to get a new drive once I get settled in a new address. But for now I want to force it to map out the bad sectors in that section while I wait.

(I know, I argued specifically against this earlier in this very thread. I swear: If this works for me and the drive doesn't go completely south because of it, I will FAQ this.)

Damn.

Looks like I need to spend the cash on the new hard disk, then.

try zeroing the partition first. The player code does single sector I/O usually on the scratch partition, and that isn't good enough since the drive itself only reads/writes tracks.

Cheers

Okay, I'll give it a shot while I wait for the new drive to arrive. It means losing my EQ settings, but I can write those down.

If I recall, what I lose by zeroing the whole partition is:

- EQ settings
- Play counts, track overviews, and other per-track statistics
- The current running order/playlist (this is the thing that's not getting saved properly so it's already gone)

Anything else?

Again, my own FAQ answers me:

Tuner presets and bookmarks. I'm moving to Seattle so tuner presets I was gonna change anyhoo. And I don't have any bookmarks I'm worried about.

Okay, gonna try it.

Okay, it worked. Hm.

Before I FAQ this as I promised, I'll need to run all those SMART tests on the player to be sure the hard disk is in working order.

Incidentally, what indicated a disk problem to me was Hijack telling me "HDA: LOST INTERRUPT" each time I selected a down-down-down shuffle, and subsequent not-remembering-that-playlist-across-reboots. Selecting a smaller playlist would sometimes work without giving me the error and would be fine across reboots. I determined: Bad sector somewhere in the dynamic data partition. Not cable/header trouble because it had no problem reading the song files and playing them back. I reseated the cable, double checked its crimping, double checked the header, and switched the connector anyway to be sure, but no change.

But since it let me zero-out HDA3 without giving me any errors (either on the screen or in the console) and the player seems (cross fingers) to be working perfectly now, then should I assume that the disk is really fine at the hardware level and there was something ELSE wrong I'm not understanding?

Would something like a power failure or a software glitch that causes a reboot, during a dynamic-data-write, cause this kind of error?

And by the way, Mark...

THANK YOU for all your incredible expertise on this topic. We are truly fortunate to have the "Linux IDE Guy" around helping us all out. You are, and always have been, The Man.

Thanks for figuring out those offsets, Peter. I had just returned from a long (11 hours, 10 caches, 1035KM) drive, and my paltry reasoning skills were not functioning yet (and still probably aren't!).

Tony.. as you noted, you still oughta try a S.M.A.R.T. "long" test on it. It might really be bad still, but what you have done often recovers things nicely.

cheers

Thanks, I'm curious if the problem could possibly be all-software. I figured the errors I was getting were only possible as hardware errors.

Oh, and thanks, Peter and Mark, for those command lines. I updated the faq entry on clearing the dynamic data with those.

I'm still reserving judgement about a new FAQ on using the zero-out command as a workaround for bad sectors. Haven't gotten to the SMART tests yet. Still in a transitionary phase in my relocation and don't have time to run the tests just now.

Well, then I'm not so embarrassed for buying the new hard disk, then.

Well, as long as the new hard drive has a larger capacity, you can always say you were upgrading...

The logs retain error info long after errors are repaired. The report you posted shows old information.

It also shows you launching a "long" selftest, but I don't see the results of that test afterwards.. did you wait an hour and then redo the "smartctl -l selftest" command? I see one instance of that right after issuing the "-t long" command, but it doesn't show the results of the "-t long", which means the selftest was still happening (or the unit got powered off or something before it completed).

The selftest commands ("-t long") execute *in the background*, and take a while to complete.

Cheers

Damn. I thought I'd waited the 55 minutes it told me to wait.

Guess I'll do it over again.