Posted by: Kit
Incremental Database Rebuild - 18/09/2001 17:24
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
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