JJZolx wrote: > IMO, it's just plain silly to use this method of navigation to build > the database. Aren't there better options for low-cost methods of > cataloging newly added files?
I kind of understand what's going on behind the scene. If you think about it, what can SlimServer do when it descends into a directory? If it just spit back a raw directory listing, well, that's OK as far as it goes, but then none of the tracks would be "clickable". That is, it could show you what's there, but it wouldn't understand what it was showing you. This would be akin to my tiny perl script that runs super fast but has no understanding of what it's listing. The alternative is for SlimServer to do a lookup for each track it encounters -- this way it can "understand" what it's showing you in a directory listing. Mixed in with this is the idea of picking up newly added tracks and/or directories, a limited "rescan", if you will. I guess what's confused me is that since all I have at the top level of my music folder is more folders (about 800 of them) and no loose tracks, I don't know what takes SlimServer so long. There's really nothing going on there for it to try to "understand", do lookups on in the database, etc. So what's it doing as it's reading that top level directory? Which brings me back to my initial post on this, and why I was so surprised to find that "Browse Music Folder" took so long in 6.0.2. SBB _______________________________________________ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
