Thread: POLL: Best way to handle media information

Seperate, without a doubt. Keep the content seperate as much as possible for scalability.

I lean towards using something existing, like the WMP database. Build a custom one later if performance is a problem or if there's some other big gain to be had.

Performance is night and day between a true database and something like wmp (my current setup) or even iTunes. I think for anyone with a decent collection having to wait 3-4 seconds to find your song compared to 0.1 is very noticeable. That said, having control over what data is stored (for example lyrics) allows for some pretty cool features down the road.

So something built in seems to be out - but then the question is how separate. Im leaning towards a MediaDatabase plugin type. That way if you want to use wmp and the wmp database you grab those two plugins. If you wanna use vlc but the wmp database - you can do that too. You could even then do separate databases for removable media - for example you could have vlc, the itunes database and an iPod database thats only available when the ipod is plugged in.

Thoughts?

Originally Posted by justchat_1

Performance is night and day between a true database and something like wmp (my current setup) or even iTunes. I think for anyone with a decent collection having to wait 3-4 seconds to find your song compared to 0.1 is very noticeable. That said, having control over what data is stored (for example lyrics) allows for some pretty cool features down the road.

So something built in seems to be out - but then the question is how separate. Im leaning towards a MediaDatabase plugin type. That way if you want to use wmp and the wmp database you grab those two plugins. If you wanna use vlc but the wmp database - you can do that too. You could even then do separate databases for removable media - for example you could have vlc, the itunes database and an iPod database thats only available when the ipod is plugged in.

Thoughts?

This takes my vote. The more options you allow for, the better it will be received!

Originally Posted by ws6vert

This takes my vote. The more options you allow for, the better it will be received!

I agree with this. I think different media "sources" which are added by plugins defiently makes for a more flexible frontend.

I was thinking of the iPod situation earlier, and while reading the database is certainly one way to go (and is how most frontends handle it). I would really like the abilty to be able to write a plugin that can send and recieve serial commands from my iPod, with the iPod itself playing the audio (avoiding DRM issues with iTunes bought music). A similar system could posisble be used for interfacing with CD changers, providing someone comes up with the hardware and a plugin.

I really don't understand the logic in using a separate db for music. What it means to me is that you have to manage your music using *that* app (itunes, wmp, etc). I could have used Amarok or Banshee for nghost but I didn't and never will. Those apps come with a long list of deps that I didn't want to force a user into. I think there was a general consensus a while back that having external deps on apps like that was a no-no.

If I were you, I'd do it "the right way" (TM) and build a simple database of your own. Then write plugins that dep on other apps for those people who like dependencies on technologies that were never meant to be used in that environment.

and sqlite is about the slowest of all possible database engines. But you don't need anything blazing fast for what you are doing.

Originally Posted by kev000

I really don't understand the logic in using a separate db for music. What it means to me is that you have to manage your music using *that* app (itunes, wmp, etc). I could have used Amarok or Banshee for nghost but I didn't and never will. Those apps come with a long list of deps that I didn't want to force a user into. I think there was a general consensus a while back that having external deps on apps like that was a no-no.

If I were you, I'd do it "the right way" (TM) and build a simple database of your own. Then write plugins that dep on other apps for those people who like dependencies on technologies that were never meant to be used in that environment.

and sqlite is about the slowest of all possible database engines. But you don't need anything blazing fast for what you are doing.

I think you had a misunderstanding of the question. Having the database as a separate plugin type would not be limiting - having the database only be the one you create would be. The MediaDatabase plugin included in the app (aka the official plugins) would be the sqlite database plugin (no dependencies). Should users not want to use that they could use one that interfaces with iTunes, wmp or others. This would prevent users from having to re-index large collections or maintain ratings and other stuff which some programs do not save to the media tags.

Again I completely agree that depending on external apps is a huge mistake in the mobile environment which is why the official plugins never would - but then again I feel that it would be limiting to completely prevent it.

That said-thats my opinion but the point of the poll was to get everyones and see what we come up with.

As far as sqlite being slow - maybe compared to a full sql server on the right hardware but lets me honest on a carpc where ram and processing power are limited I think its way up there for the simple queries it would need to be handling. Not to mention transfer overhead for something external to the application. Maybe i'm missing something though so if you have alternatives you wanted to suggest or other info I would definitely be interested.

Originally Posted by ballen

I agree with this. I think different media "sources" which are added by plugins defiently makes for a more flexible frontend.

I was thinking of the iPod situation earlier, and while reading the database is certainly one way to go (and is how most frontends handle it). I would really like the abilty to be able to write a plugin that can send and recieve serial commands from my iPod, with the iPod itself playing the audio (avoiding DRM issues with iTunes bought music). A similar system could posisble be used for interfacing with CD changers, providing someone comes up with the hardware and a plugin.

The part we are discussing is the media database - the part that stores an index of all your music.

The framework already contain an AVPlayer type of plugin that could be used for just about anything including playing an iPod as a removable drive, or through serial commands or even an iPhone streamed over bluetooth. Feel free to read more about it in the developers wiki but it may be a little technical.

Originally Posted by justchat_1

The part we are discussing is the media database - the part that stores an index of all your music.

The framework already contain an AVPlayer type of plugin that could be used for just about anything including playing an iPod as a removable drive, or through serial commands or even an iPhone streamed over bluetooth. Feel free to read more about it in the developers wiki but it may be a little technical.

I understand this, but as far as I can see the AVPlayer is just able to control what's playing. How about selecting what to play though? I presumed the database plugin would have to return a list of songs available, which, in this case would have to be retrieved via serial, rather than accessing an actual database. Or would this be handled by the MediaManager plugin mentioned in this poll (there didn't seem to be anything in the wiki on this yet so I'm not 100% sure what it is... my guess was that it was for display of data from the database plugin, enabling you to pick a song to be sent to the AVPlayer plugin, is that correct, or is it more about importing media into the database?)