Once the features of 2.0 are delivered to the masses I think the next "big thing" to attack is the long database rebuild times that take place once you have a lot of files on your empeg.

If the database used were stored internally by FIDs, the sync application could submit a list of fids that were modified and only update those. Only in the case where the database got hosed would it need to rebuild itself from the individual files all over the disks. If the player software needs it in another format this could serve as a source to generate the current format of the player database in a quick fashion.

Has the database structure changed at all for 2.0 to allow this to take place in a way that doesn't take ages to implement?

I frequently find myself wanting to quickly add a few tracks to my empeg right before running out the door. This would prevent me from having to sit there and wait (what seems like forever) as it rebuilds the database. This is one of the few things I like about my portable Archos Jukebox, I can copy a file and run.

Another approach would be for Emplode to create the actual binary database that the player uses. That way the Emplode host (which is usually quite faster than the empeg) could do any sort of manipulations that might be slowed by the empeg itself.

-Kit

Emplode creating the database is one option that has been considered, but is not currently in v2.0.

Problem is, it's possible the database would get out of sync with the files (these things happen) and then data loss would be a very real possibility. I think we'd have to make it do a full rebuild on the player sometimes (giving you the option to skip it if you were in a hurry, obviously).

Hugo