[akezeke]

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

[topfs2]

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

[neoflex]

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.

[promontis]

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).

[topfs2]

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.

[coendeurloo]

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

[akezeke]

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

[topfs2]

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.

• 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.

[promontis]

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.

[topfs2]

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.

[jmarshall]

@promontis: First off, yes we're fine with having binary addons - indeed, there's been quite a bit of work done on this already, though it's currently somewhat stalled on the backend infrastructure required (as I'm sure you'll understand, supporting multiple platforms becomes tricky ensuring all dependencies are met!)

Secondly, as you say, the standard "directory" plugin really doesn't work for spotify, though it could be useful for holding previous searches and the like - I suspect it's quite similar to LastFM in this respect - there will be some directory stuff that makes sense (eg top 20 artists/albums/songs or recommended lists etc.) but some stuff is really better in a general search interface. Search results can, however, be displayed in standard listings, as often there's a hierarchy involved in the results.

Thus, I think what you're after really is a directory-based interface, supplemented with search capabilities. We therefore need to extend the standard directory API (which is really just a single function: GetDirectory) to allow search as well. This would then be reflected in the python API for plugins as well. I think the only thing to define is the search API (i.e. how search/filter/grouping terms are defined).

The layer that goes on top to combine things is more what topfs2 was getting at. This can be very simple at first though, such as just running searches (backgrounded, ofcourse) and adding "Listen to other songs by this artist" or "Find similar artists" style links to the standard library listings. These would be generic links that could be filled by multiple listing services (spotify, lastfm, netflix, hulu, etc. etc.)

There'd have to be some control over how things are integrated - some users won't want any integration, some will be happy with integration via the addition of extra links as above, and some will prefer the results in-line with their local listings.

Cheers,
Jonathan

[topfs2]

Yeah I think there will somehow need to be two parts of an addon of this type, one is the directory (which provides search from a user perspective) and the second where either the database searches and stores or the service provides the info to store (I think its better if service decides what to store even if it involves more code on service side).

So since english isn't my native language I usually have a hard time to get my point cross (jmarshall is great at interpret it though ), I'll put forward a step list I think could be a great way to work towards the goal to have spotify in GUI but also to have uPnP and such as possible backends (not the search part ).

To get the part I'm contemplating it seems like we could go an extremely simple route:

1. Add hooks for addons to do something close to MusicLibrary.[Add|Update]Track(....)
   
2. Add owner-ID to any items in the database (set owner-ID to "" or something if its xbmc)
   
3. Add some form addon hook to inject which owners are available, something like MusicLibrary.Source(ID).SetActive(true)
   
4. Update or add new hooks to be MusicLibrary.[Add|Update]Track(ID, ...)
   
5. make GUI only show items if owner is active
   

So from that list you could in fact start implementing spotify already at point one but if you continue down the roadmap it would be possible to add servers which comes and goes (much like how uPnP and MySQL ideally should behave). Almost all points on that roadmap are merge worthy which I think ought to create quite a good incremental roadmap for the goal to allow addons (and spotify) to inject items into the library so they feel like they are native (which would be awesome).

Personally I think doing this in MusicLibrary would make lots of sense since we have both spotify and uPnP which is could feed data quite well to xbmc's library with music, very few servers can do this type of interaction with video items just yet (even if later uPnP MediaServer specs would work awesome).

In core after these steps are done we have the possibility to add MySQL as an addon which would not only make it easier to manage (as the addon could control the db layout) but also possibly allow multiple MySQL backends (even if I doubt many users needs that ).

When this is incorporated we could implement the same steps in all libraries and the unification could be completely seperate and after this (I like to consider the end solution first before I start thinking of incremental steps towards it which is why I started discussing it first ).

Cheers,
Tobias

[jmarshall]

Actually, at a starting point I'm not convinced that adding items from something like spotify to the current database makes sense, as I think it's important to keep even the sqlite database (which represents files you own on the network) as a separate "source/owner".

Certainly a caching layer on top of that could well use an sqlite database to manage things - that I'd be fine with. It doesn't have to be an sqlite database at first though, and indeed, you don't even necessarily need a caching layer at first - just do the spotify searches in the background and integrate as a proof of concept.

Cheers,
Jonathan

[akezeke]

Actually, at a starting point I'm not convinced that adding items from something like spotify to the current database makes sense, as I think it's important to keep even the sqlite database (which represents files you own on the network) as a separate "source/owner".

Certainly a caching layer on top of that could well use an sqlite database to manage things - that I'd be fine with. It doesn't have to be an sqlite database at first though, and indeed, you don't even necessarily need a caching layer at first - just do the spotify searches in the background and integrate as a proof of concept.

Cheers,
Jonathan

This together with topfs2 latest road-map example sounds great. I'm now working on the spotify addon backend (much prettier and not so hackish as my old implementation) so we have something to implement as soon as the hooks and form of such a music addon is decided.

For now I concentrate in two areas, the stared albums and tracks (to be inserted in the album/tracks listings) and the search.

/David

[topfs2]

Actually, at a starting point I'm not convinced that adding items from something like spotify to the current database makes sense, as I think it's important to keep even the sqlite database (which represents files you own on the network) as a separate "source/owner".

Certainly a caching layer on top of that could well use an sqlite database to manage things - that I'd be fine with. It doesn't have to be an sqlite database at first though, and indeed, you don't even necessarily need a caching layer at first - just do the spotify searches in the background and integrate as a proof of concept.

Cheers,
Jonathan

I agree I'd rather see our database as one source to the aggregated library, it may involve more work though. If we have our database as one source it would be much easier to do a complete shift in how the database work though as we could simply have another source as the new. anyways, I consider the hierarchy of the abstraction to be something like:
PrimarySource (borrow naming from banshee atm but we could name it better) which owns tracks and items it has.
Each normal source (vfs filenameparser / nfo parser) in current code would also be a PrimarySource or if easier all normal sources are part of one XBMC-PrimarySource (which is how I suggested in the roadmap by setting owner to "" for xbmc, little hackish but fast ).

We have the option to either assume that each PrimarySource carries their own database (which makes a caching database somewhat redundant) or we assume each PrimarySource may be slow and keep a caching database (which I somehow would prefer as an end-game).

I think we want somewhat the same thing no?

This image I posted earlier shows somewhat what I mean with the PrimarySources, except it also contains a move of scraping to be after PrimarySources (so all of them could benefit from scraping)