I'm in the middle of a big project where I'm wiping out the songs from the empeg disk drive and replacing them en masse with higher bitrate copies.

I want to save the data currently on the dynamic data partition that contains my EQ presets and Tuner presets, so a complete Builder-Image run is something I would like to avoid.

I could just delete the existing songs and put the new songs onto the player. But if I recall correctly, there is still a bug where things like the "plays" count are still there, stored on a per-FID basis, after you delete a song. So when I replace all the songs, the plays counts will be incorrect for each of the songs (since the FIDs will change).

One option would be to hand-select each song and do "replace tune" to preserve the FID number, but I don't want to do that 3500 times.

I don't mind wiping all of the "plays" counts to zero and starting over, but I don't want to have wrong "plays" counts for the songs.

Does anyone have any ideas about how to easily erase the song statistics from the dynamic data partition without erasing the other data stored there? For instance, I could back it up to a file using the instructions in the FAQ, then copy that file to my PC, edit it with UltraEdit, and copy it back to the empeg. I just would need to know what range of bytes to edit (and could I get away with just zeroing them out?).

You can set the plays counter using JEmplode. It's on the advanced property tab under 'play_count' if I remember correctly.

-Chuck

But if I recall correctly, there is still a bug where things like the "plays" count are still there, stored on a per-FID basis, after you delete a song.

The operation of downloading a FID should erase that data; if the bug is still there in 2.0-final, rereport it. But in that case, you can use

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

to zero out the per-fid dynamic data without touching the other stuff. Be careful typing that, as you will hose everything badly if you do it to the wrong partition.

Peter

The operation of downloading a FID should erase that data; if the bug is still there in 2.0-final, rereport it.

You know, now that you mention it, I never checked that in 2.0 final. I just remember that it was there in some of the 2.0 betas and I didn't see it specifically noted as "fixed" in any of the release notes. On reflection, you're right: just because it wasn't specifically reported as fixed doesn't mean it wasn't fixed. So I should verify that it's even a problem at all before I panic. Maybe I don't have to do anything.

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

Cool. I'm going to put that in the FAQ. Is there anything special that needs to precede the command, such as mounting the drives read-write?

You can set the plays counter using JEmplode. It's on the advanced property tab under 'play_count' if I remember correctly.

I thought that didn't work to change the value. Anyone know for sure?

Hey, Peter, which statistics does that erase? Just the plays, or does it erase all of the statistics including last time played, BPM, the volume graph for SeekTool, etc.?

(Those don't matter to me personally, I just want to make sure the FAQ entry is complete on this point.)

I know the changing play_count works as I used it last night.

I don't think changing play_last works though, it's been quite a while since I tried that.

-Chuck

I know the changing play_count works as I used it last night.

Can you do it for a group of tracks? Say, all 3500 tracks on the player?

I zero-ed a complete playlist, so it should be no problem. Just make sure to press <Enter> after entering the value for 'play_count' on the advanced property page, otherwise JEmplode will ignore the new value.

-Chuck

Is there anything special that needs to precede the command, such as mounting the drives read-write?

Nope. That blats directly onto the dynamic data partition. As you know, the read-only/read-write thing is only an attribute of how the partition is mounted; and since the dynamic data partition is never mounted...

Hey, (someone), which statistics does that erase?

All of the per-FID dynamic data -- play count, track profile, etc.

Thanks, Roger!

And thanks, Peter, for the command. I'll find out soon whether I even need to use it.

Just thought I would let you know, I ran across one tonight that wouldn't change. I can't tell you what is different, but I thought I should give you a heads up as you were going to do a massive tune swap.

-Chuck

Thanks! I'm uploading the first batch of tunes tonight, we'll see how it goes. If I have to zero them out, I'll use that shell command.

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

Shouldn't that be:

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

?

Shouldn't that be:

Oops. Yes, of course it should.

Peter

Thanks! Corrected in FAQ.

The operation of downloading a FID should erase that data; if the bug is still there in 2.0-final, rereport it.

From my intial checks, this seems to be working as intended now.

From my last batch of fresh uploads, all the files were at zero plays except for one which was at 20.

I would consider the "20" a bug, however this batch of uploads crashed after a few hundred files, and I had to hand-delete the database file and rebuild it before the player worked properly again. So it's conceivable that this file is the one it crashed on.

The crash was weird. I suspect something screwed up on my LAN during the night and caused a hiccup in the network. The song uploads started stalling with 8004003E errors at some point, and everything went downhill from there.

Tony,

you should upgrade your faq about this, since i almost posted a new post asking how to change the play_count since in emplode when i "replace tune" it resets to 0, which is dumb, why would you want to do that?

I just added a line saying some statistics could be edited with Jemplode. Is that what you meant?