From: Jens T. <jen...@po...> - 2004-04-07 21:05:20
|
Hi Jonathan, On Wed, Apr 07, 2004 at 09:22:13AM +0200, Jonathan C. Ross wrote: > Hi Jens, > > last time I looked, the gtkpod iTunesDB code was really slow... on my > dual 2.4 GHz Xeon that is. It took about five minutes to parse my 4500 > song db (perhaps the GUI code was slowing things down a bit too). I > shiver at the thought of running it on my iPod. If we ever wanted to > add playcount updating to podzilla, it would not be too wise either, as > gtkpod actually re-writes the entire database upon export. I think the > way to go is actually a proper db driver implementation - updating > records in place (or, at least, with a cache mechanism for updates, so > as to minimise disk access). The slowless is almost certainly caused by the gui. Depending on your settings it is adding the entries in the gui as soon as it is reading them (IIRC at least). Still I fully agree on the in place editing. > I have started work on a playqueue in podzilla - for now I'm going to > use my own simple d.b. files for browsing songs (to be generated with > libid3tag on the host). I am working on the principle of caching up to > 16 MB of the next songs in the playqueue, and actually playing them > with libmad (rather than forking a sub-process). (Intel's code is my > second candidate, but its not GPLed). > > When I've gotten that working, I would port the code to the binary > iTunesDB format, and add play-count updating. > For the time-being, I think Bernards idea of a link farm is the > quickest way we'll get user-friendly song browsing in podzilla :-). I will try to give the iTunesDB a shot tomorrow night. So if it is not to complicated perhaps we have s/th by the day after tomorrow. Cheers Jens -- Jens Taprogge |