Unified music addon frontend

Hi,

Following up this thread here regarding a unified online music frontend I want to suggest that we expand XBMCs music functionality with online services integrated into the music part of XBMC.

Clearly I'm primary talking about spotify which is expanding to the US very soon.

promontis suggested here that the user probably don't care where the music comes from, the user just wants to find the music he wants and play it.
And I agree, we should expand the functionality that already is in XBMC to also include music from online music addons.

Using spotify as an example this is how it could work:

• Artists → artists from the local db & artists that has “stared” tracks in spotify
• Albums → local albums & stared albums from spotify
• Tracks → local tracks & stared spotify tracks
• Top 100 → submenus with local top 100 tracks, albums & spotify top 100 tracks albums etc.
• Playlists → local playlists & spotify playlists that are converted to local playlists, they act as they where local and support adding and removing of tracks and so on
• Search → returns local artists and songs, albums & spotify search results
  

The tracks, albums and playlists from a plugin could be distinguished with a prefix to there names, a small overlay on the cover art or a small icon somewhere maybe.

The way this could be done is to allow compiled shared libraries as addons just like the pvr-clients. The addon should implement functions like search(str), get Albums(), getTop100() and so on.

Further the addon should be allowed to include a custom paplayer codec and custom menu entries for its items. Spotify will need “star” and “unstar” for example.

Even further some services might add additional functionality not easily integrated in the current menu structure, spotify has a very useful “radio” for example. So allowing an addon to add a special menu entry in the music section could be a nice solution.

So what do you guys think?

promontis stated that he is interested in coding this and I want to help out and also create a new spotify addon parallel to go with it.

/David

What we want in general is to allow addons to populate the library, i.e. allow multiple library backends. This for video and for music.

This would allow uPnP MediaServers to feed straight into the libraries and it would allow services such as you explain to be added by magic into the library.

Ideally when making that one could unify the media databases to ease addition of new media types (as games, pictures, audiobooks etc.)

Easiest would probably be to design the unified caching database, along with hooks to add new database types, outside xbmc. After that is done and work well we could start making xbmc use that caching database. After that is done one could add one type of backend be the old databases to give backwards compatibility

that would be awesome. I can imagine controlling spotify integrated within XBMC with XBMC commander on my iPhone for instance. Searching new albums and so on. I am willing to help if I can. I guess there will be more people interested once spotify released in the US even if Grooveshark for instance could be integrated in the same way.

topfs2 Wrote:What we want in general is to allow addons to populate the library, i.e. allow multiple library backends. This for video and for music.

Could you elaborate on the 'multiple library backends'? Is this like the plan to seperate frontend and backend? Because that'll be a lot of extra work blocking progress on the actual feature.

Furthermore, what is your (the team's) view on c++ addons? If the experience for the end user remains the same as for installing current python addons, I don't see any problem implementing that first; it makes coding spotify integration a lot easier as spotify lib is coded in c++. Also, we've noticed that c++ addons give a much more fluent user experience, at least for spotify (but I bet this can be generally applied to any plugin).

promontis Wrote:Could you elaborate on the 'multiple library backends'? Is this like the plan to seperate frontend and backend? Because that'll be a lot of extra work blocking progress on the actual feature.

Furthermore, what is your (the team's) view on c++ addons? If the experience for the end user remains the same as for installing current python addons, I don't see any problem implementing that first; it makes coding spotify integration a lot easier as spotify lib is coded in c++. Also, we've noticed that c++ addons give a much more fluent user experience, at least for spotify (but I bet this can be generally applied to any plugin).

What an spotify addon would and could be is a new database backend. So the database we have right now in xbmc would be a form of "cache" of the aggregated result on all backends. That way you could add mysql as a possible backend and spotify as one and uPnP MediaServers as one.

So the actual feature would be to allow for addons to be backends, even if remote or not.

Here is a simple block diagram depicting a possible design for it:


This can either be done via the "start fresh" and designed outside xbmc (which is a big project) or incremental (personally not what I would do I think).
Incremental would mean

1. turn current database into a cache, i.e have each item in the database have a backend associated to with it and only give items which has backend "connected"
2. make abstractions so that you can create backends which can give the data to the cache on request.
   

And we want binary addons for sure, if it actually speeds up GUI it depends on the type of addon, python isn't that slow when compiled, especially not if the python code is mostly glue code. i.e. it does the heavy lifting in C and not in the scripting. Many apps out there which are plenty fast and python based (extremely common on linux desktop). For example visualization in python would probably be sluggish but a plugin may not be noticeably slower.

Wow, great to see people finally talking about this. When Spotify will be launched in the U.S., the requests for a proper plugin will be overwhelming I guess. I'm using Spotify for a long while now (Holland), and I can't live without it

topfs2 Wrote:What an spotify addon would and could be is a new database backend. So the database we have right now in xbmc would be a form of "cache" of the aggregated result on all backends. That way you could add mysql as a possible backend and spotify as one and uPnP MediaServers as one.

So the actual feature would be to allow for addons to be backends, even if remote or not.

Here is a simple block diagram depicting a possible design for it:


This can either be done via the "start fresh" and designed outside xbmc (which is a big project) or incremental (personally not what I would do I think).
Incremental would mean

1. turn current database into a cache, i.e have each item in the database have a backend associated to with it and only give items which has backend "connected"
2. make abstractions so that you can create backends which can give the data to the cache on request.
   

And we want binary addons for sure, if it actually speeds up GUI it depends on the type of addon, python isn't that slow when compiled, especially not if the python code is mostly glue code. i.e. it does the heavy lifting in C and not in the scripting. Many apps out there which are plenty fast and python based (extremely common on linux desktop). For example visualization in python would probably be sluggish but a plugin may not be noticeably slower.

That make sense for a service containing of a couple of hundred movies or an uPnP service a guess, filling the cache with the movies /albums that are provided.

But with a service like spotify where you are supposed to search for albums, artists and tracks from a database with tens of millions of posts caching the results in a db does just seems to add additional overhead I think. (and you can of course not "browse" the entire spotify catalog and cache it, not allowed and probably very hard to do)

The results will be different for every search and searching the albums that you already have saved (or stared) seems pointless.

Or is the cache supposed to be flushed and refilled on every call for items? Like you hit search, the cache db is flushed, the db asks all "backends" to refill it with relevant material, and then the db is queried and the result is displayed?

If so to me it seems like the backends could just return what it got directly and not taking the route through the cache db.

/David

akezeke Wrote:That make sense for a service containing of a couple of hundred movies or an uPnP service a guess, filling the cache with the movies /albums that are provided.

But with a service like spotify where you are supposed to search for albums, artists and tracks from a database with tens of millions of posts caching the results in a db does just seems to add additional overhead I think. (and you can of course not "browse" the entire spotify catalog and cache it, not allowed and probably very hard to do)

The results will be different for every search and searching the albums that you already have saved (or stared) seems pointless.

Or is the cache supposed to be flushed and refilled on every call for items? Like you hit search, the cache db is flushed, the db asks all "backends" to refill it with relevant material, and then the db is queried and the result is displayed?

If so to me it seems like the backends could just return what it got directly and not taking the route through the cache db.

/David

The suggestion I made only reflected the first part of your goals, i.e.

akezeke Wrote:

• Artists → artists from the local db & artists that has “stared” tracks in spotify
• Albums → local albums & stared albums from spotify
• Tracks → local tracks & stared spotify tracks
• Top 100 → submenus with local top 100 tracks, albums & spotify top 100 tracks albums etc.
• Playlists → local playlists & spotify playlists that are converted to local playlists, they act as they where local and support adding and removing of tracks and so on
  

The search would need to be elsewhere, I have no design idea for that tbh but I guess a more normal-ish plugin might work in the search case?

As for why go through the cache db, mostly to speed up for possibly slow backends. You could easily just aggregate and assume each backend has a cache if it needs it. Whichever is simplest really. I personally think its better to have the cache in xbmc because of a number of reasons

1. One cache implementation instead of many
2. Can keep the feed from backends simplistic and have filter, search and query logic in the cache instead
   

The first point is mostly me assuming many backends will need cache, thus easier (for backends) if we do the caching. The second point is that the backends could simply give us MusicTracks, MovieItems and such in a very simple manner and queries like "Give me all artists with track titles beginning with "ab"", as those filters are easier to do in databases (thats what they are good at) we would most likely store the data in a database no matter, might aswell leaverage the possiblities of that.

From my POV, it is easier to start coding the unified music addon first. Like the PVR addons, we will put it in a directory first. Eventually the addons should become real downloadable addons.

Honestly, that is what I think have gotten a bit wrong with PVR. A unified media library (although more work) would benefit all parts of xbmc, it would be easy to add picture library, games library and recorded tv (even epg could be in there).

But you can still start with music without it being unified (between video, music etc) as I posted here, unify could be a later goal. The design and the roadmap I put forward would work just as well for pure music also. Benefit of going with that design IMO would be that uPnP and other servers could easily use the same hooks.

Also if you check the step I suggested I think it would be quite easy to do it incremental without taking way to much time refactoring and you could have spotify quite early.

My suggestion would be introduce backend ID (or addon id) which feed the data into the database. Let it only be visible if the addon states itself as available (would only happen if for example server is available etc.). This could also later be used to show removable content aswell (from usb/cdroms etc.) as you just peg the disks uuid as id.

EDIT: You may want to check out banshee and how they behave as they have hooks for something very close to this via their PrimarySource. It works essentially by stating that the PrimarySource is owner of the files, they cannot exist without the primarysource. A service then inject items into the database with primarysource as owner, they will only exist if primarysource is existing. So if a server goes offline you remove the PrimarySource and the content goes away.

If you want to do it feel free to ping me on IRC anytime, I'd be happy to help out as I would love to add uPnP support in a similair fashion.