Can I do this via FTP?

I have the MaxFID patch on this player and it seems to have done nothing at all. I originally installed it to eliminate this exact problem, but it was not effective. Maybe I didn't install it correctly? Anyone?

One reason that you might be having database rebuild trouble wouldn't necessarily have anything to do with the number of tracks or Maxfid: You wouldn't happen to be running alpha software would you? The 3.0 alphas gave me that kind of trouble when I tried them.

Nope, I'm running the 2.x final - whatever number that was.

Let's rewind a bit. How many tracks do you have on the player, exactly what is going wrong that's preventing a normal synch (what is the exact error message), and have we already (as a group) diagnosed and determined that it really is the number of tracks that's causing the problem?

There are 26618 tracks on the player. It's got dual 80gb drives and about 12.5gb free space.

I'm completeing a sync right now and should have an exact error message in a bout an hour when it gets done "crashing" Emplode. I'll report back.

Question: Did you reinstall the player since applying the patch?

Yeah, OK, with that many tracks it wouldn't surprise me if you've run up against the limit, even with MaxFID installed. I forget what the upper limit is with MaxFID installed, but that might very well reach it.

So yeah, doing manual database rebuilds: Definitely try the site commands to see if you can do it with FTP. That'd simplify things for times when you don't have a serial cable handy.

That's exactly the problem, no serial handy at work, only at home.

Let's get back to this one thing for a minute... if I shouldn't reboot the player while it's in RWM mode using the front panel, then how should I get the player to re-start and re-build the databases via FTP once I've deleted all the necessary folders?

From the serial port, you'd just type "exit", which would restart the player application. Rebooting while the player is in RW mode is going to cause it to run an fsck, which is going to take a looooong time with two 80GB drives.

However, doing a "SITE Q" won't work, because "Q" isn't a command to the OS, it's a command to the player application. Let me think about the easiest way to solve that problem.

So where would one modify the set maxfid app to go higher than 26618?

Will this also keep Emplode from doing a "Checking Disk Intergrity" test everytime I sync?

Take care to note the exact terminology here: "reboot" means to effectively cycle power to the machine; "restart" means to kill off the player process and start it again with a command.

Cheers

The maxfid patch doesn't work quite that way; you can't set it for a particular number.

What happens is that the size of the dynamic data partition isn't absolutely set -- it depends on the size and geometry of your particular hard drives. Kind of like a rounding error, the actual partition size is going to be at least the set size, but there might be a little bit of extra space. It's like asking for 1.5 plates of food and the chef giving you two, because he only makes whole plates. If you want 0.8 plates, you get one, if you want 1.1 plates you get two. Integer units of measure. It's not rounding, and not truncating, I forget the exact term.

Newer and larger harddrives have larger minimum units for allocation. (Don't forget that the factory default drive sizes were like 8 & 12 gigs.) So when the disk is partitioned, in order to get the expected 16MB of disk space the partition may actually be 18MB or 21MB or 32MB or whatever it happens to be based on the geometry of that particular drive. (These numbers aren't real, but should serve as examples. Cylinders, heads, sectors, blocks, &c. are more detailed than I care to deal with right now, and then there's all the IDE dynamic addressing stuff.)

Mark's maxfid patch first figures out exactly how big your particular dynamic data partition is And then it overwrites the player binary file with a number that corresponds to the size of your dynamic data partition. What gets overwritten is a number that is based on a true 16MB partition, and takes into account how the dynamic data partition is allocated. So if you have a 22MB instead of the safe-to-assume 16MB, then you have 6 more MB's worth of fids, how ever many fids that ends up working out to.

When you run the program it will tell you how many fids there's room for. And that's the number you get. With an 80GB drive, you're likely to be fine, since you're not that far over the default max.

Bitt will likely post in a few minutes correcting all of the errors and assumptions I've made in this post.

--Nathan

Does all this mean that if one built their drive by hand, they could have a 40 or 50mb partition? Is there an upper limit to what will work with the patch?

You could, but it would get overwritten the next time you applied a standard empeg upgrade image, which includes partitioning information.

If you only use tools like Mark's upgrader and the upgrade splitter and did everything manually, then you could, and have a different sized spare partition as well.

The dynamic data partition (hda3) doesn't need to be very big. There's a =lot= of technical details in the thread Bitt linked to above, and if 16MB gives you ~22k fids, then 32MB is going to be more than double that because the 16MB includes space for saving playlists.

I think most of us with 30GB+ drives end up with at least 30k fids just using the extra space with the default partitioning.

--Nathan