Peoples preference about the way front-ends store media..

JaseVYS · 09-13-2005, 01:37 AM

im in the process of building a front-end for myself and things are going quite rapidly.. but i now find myself sitting infront of my keyboard wondering "what do i do now"..

And its just about one aspect of the system.. how it works with the media on the disk.

The way i see it, theres two ways..

A) One way is to not care whats there, just go through each directory/file on the fly, pulling information (such as mp3 id3 tags) and length etc out as you go..

B) The other is to pre-index the available media, getting lengths, id3 tags, directories and files, and storing them either in a disk-based database or flat file.

Both have their pros and cons.. (A) means no immediate delay between booting and playing the first track.. but there is less searching-capability for it.. whereas (B) offers complete searching and traversal capabilities amongst media collections etc, but at the cost of the potentially large delay at startup while it indexes the media. And of course when you add media, you have to do the process again, so it can include anything it doesnt already have..

So i want to know your thoughts on this. As a user or developer (i know you guys are lurking around

) what would you lean towards?

JoeDirte · 09-13-2005, 04:05 PM

I would have to lean towards a database approach.

If you decide to, check this out. Very fast and small.

Good luck!

Mad Ad · 09-13-2005, 06:32 PM

you dont have to index it every time, just check for updates so b) wont be slow all the time, just to begin with

PatO · 09-13-2005, 08:37 PM

b) has obvious advantages, the key is make it as seamless as possible.
A frontend should be able to automatically detect the addition of new files and sync them up quickly.

1) Massive Re-Sync
Resyncing the entire folder structure is one option, but it's a slow and aggrivating option. It has is place - occasionally I go through and add files to certain folders or update ID3 tags. In that case, a massive examination of the files is justified.

2) Smart Re-Synch
If I add a few files or albums, I don't want to wait 5 minutes for my library to be updated. A frontend should be capable of updating based on a specific folder. I tell it where the new files are, and it does its thing.

3) Automatic interogation of new files
Provide a dumping ground for new files. When the software detects new files in that folder, it does what it can to load info from those files. This is up for discussion, but it could skip the ID3 info to save on time...

3 subsection A) Upon detection of new files, the frontend could move the files to an appropriate folder. At which time, it could read ID3 info. This is likely to take a fair amount of time (several seconds for an album!) As all the user cares about is hearing music, this would have to be done on another thread from the music decoder. A simple enough task for someone adept at programming.

JaseVYS · 09-13-2005, 09:42 PM

Thanks for your responses guys.

Khumpty, I've got the SQLLite Database already setup in the project, its just not being used because i was unsure if its use would be better or worse that other solutions.

I ended up using a bulk indexing method on first run (see here for an update on my software), which then serializes the index out to an xml file. Because its XML, applications could be written to pick up the data and append data with very work, and i dont think SQLLite would have been that easy.

As for new media.. i was thinking what you were thinking Pat0, use a specified directory for new media, register a Win32 DirectoryChangeEvent hook in a seperate thread (or even an entirely seperate application, just a small windows service or something) which is notified when something changes in that directory, and acts accordingly, indexing and moving to the main media directory.

From the testing i've done, the tag pickup process is quite quick (details on page linked above), so one album is not time consuming at all.. but if they're indexing more than 14GB of music, it may well cause a slowdown.