That makes sense; though I've never had speed issues with Freevo since I organize by artist/album, so no folder has more than say, 20 tracks.
What I meant was that since we pull out the id3 tags in the main thread (apparently) it becomes a blocking operation. If we parsed the id3 tag files and put them into the cache in a seperate thread, we wouldn't have to wait for them. It does create concurrency issues though if you want to scan a file and play it at the same time. Aubin On Tue, May 27, 2003 at 10:12:09AM +0200, Dirk Meyer wrote: > Aubin Paul wrote: > > By watching, I mean, watching for changes to the filesystem, it's > > possible that the actual parsing of files and reading of tags is done > > is the main thread. > > Freevo can't scan the directory elsewhere. How could Freevo know, > which di will be the next you want to see. And because the names of > the items are generated by the id tags, Freevo opens every mp3 file in > the directory. If you store your mp3s in different directories, Freevo > should be much faster. > > > Dischi > > -- > The best things in life aren't things. ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ Freevo-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-users
