XBMC Protocol
#1
Hi all, i'm a new user in forum but i do follow XBMC developing since some time and use it for my media center needs.
I've seen some people asking for "centralized db" to share metadata of media hosted on nas or network shares and i've seen XBMC going in that direction.
I was wondering about the possibility to create a "XBMC protocol" used to present such data to XBMC "clients" satellites.
What i'm thinking about is a "XBMC server" which will:
  • Share media list
  • Deliver upon request fanart, descriptions, poster etc.
  • Deliver the media itself
  • Receive and store any needed data coming from "sitellites"
  • Delete data received from satellites

Think about an XBMC "satellite" which can siply add an XBMC Protocol source and recive:
1) an XML file with the description of all media shared (to show the list)
2) upon request receive fanart, covers, poster from XBMC server (to show descriptions and fancy list)
3) "save" or "delete" some preferences about each media (to personalize the experience)
4) Receive and play the media

The satellites can work in three different modes
1) "Kiosk" - there is NO saving of any kind on server.
2) "User" - Data saved (fanart preferencies, position, metadata) are user relative (the same user "logging" on another satellite will receive his data no metter where he is) or even more there could be a sort of "policy" about what a particular user can save (i.e. just fanart and not position) or access (i.e. for parental control) and what he can't
3) "Site" - Data saved are satelite relative and similar policy can be applyed where a satellite could be authorized to save just SOME data or display just some media.

Each satellite should have a unique "site name" and the option to "log in" with user/pass (with the option to disable/force the log in process).
These credential should be passed to server at each information requested.

Using XML for metadata transaction can make the protocol extensible and can, in future, include the chance to share games or programs or any other media.
An example of an xml fragment received from server could be:
Code:
<media>
   <type>Video</type>
   <id>12345</id>
   <displayname>Avatar</displayname>
   <fanart>fanart-avatar.jpg>
   <cover>cover-avatar.jpg</cover>
   <banner>banner-avatar.jpg</banner>
   <detailsXML>details-avatar.xml</detailsXML>
   <activation>avatar.avi</activation>
</media>
A possible extension is a pay per-view tag with the fee charged for viewing the video.

Obviuosly satellite's skin/scripts and server behaviour should be personalized accordingly too.

In this scenario is possible to cover almost all of the "sharing" needs.

An Hotel can have XBMC satellites configured as "site" so to save the preference of each room and delete that data when the host leave or even use a "user" mode setup to save host personalization to reuse them in case the host come back to the Hotel (or to another one with which the hotel share the data).
It can even personalize and extend the protocol and the server (python?) to include pay per-view or any other option needed by the particular setup.

An Home setup can be configured to have different users/configurations for the satellites in kids room (no password, no rated content, no option to login with different credentials), janitor room (password protected for rated content) or living room ("site" setup with the ability to login with kid or janitor credentials).
Each family component's laptop can have a "site" configuration.
It's even possible much complex setups with "power users" with the ability to copy/move preferences between user/sites or define default options.

Kiosk mode is usefull where user interaction should be minimal and no need of saving data is needed.

The server is, after all, a specialized web server with the ability to serve media upon request.

What do you think about the possibility to add such a feature in XBMC?

Bye

MakkaD

P.S. Sorry for bad english but i'm italian and not writing in english since ages
Reply
#2
This is what uPnP essentially is, albeit we might not share all those stuff now but it wouldn't be to hard to get fanart and such shared over uPnP
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#3
afaik upnp just deal with media presentation and delivery.
There is no "preference" or metadata savings in upnp, there is not user policyes about media avalability based on user/renderer.
It is just a way to "show" media or am i wrong?
Essentially this could be thought as an upnp extension/specialization .

Bye
Reply
#4
uPnP is mostly a way to share libraries and each library node is possible to have a number of properties, properties can be stuff like content, fanart, cover and a bunch of stuff and is very flexible. (uPnP is alot more but I'm not extremely read up on the subject so if someone wants to expand on my explanations that would be lovely)

I'm not sure if you can alter or save data on a server from a client but it really shouldn't be needed, the whole idea behind uPnP is that the server have done all the parsing and is producing a final and nice library, the clients then can be very small and just display and use the information from the server.

The modes are also possible, its just a matter of each client to use what properties it wants.

Not sure what your refering to with preferences and policies?

It might be that your suggestion can do more than uPnP but I'm guessing if we'd adopt and expand our uPnP you'd easily be 90% were you'd want and it would be a common standard that would / could work between different applications which is a far more satisfying end game IMO. So it would be awsome to see standards produced regarding fanart and different coverart and such things so all the media center applications could use a standard setup of properties to ensure compability, then you wouldn't be tied down to XBMC (can't see why you would change application though Laugh).

Cheers,
Tobias
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#5
topfs2 Wrote:I'm not sure if you can alter or save data on a server from a client but it really shouldn't be needed, the whole idea behind uPnP is that the server have done all the parsing and is producing a final and nice library, the clients then can be very small and just display and use the information from the server.
Saving data is a crucial part of the idea since that will permit to let some data follow the user such as the "watched" status or the position at which the media was stopped so to be able to resume from that point.
Usually these data are stored on the local machine (thus making them "bigger") and did not follow the user.
Passing them to the server (and saving them) wil make that data reusable by any other client.
All this can be done without having a db open to outside connections so the client do not need to connect to external db.
All what a client need is to be able to do http request and parse an xml file to have all the information he needs.
In an ideal situation with no media on the client, there is no need to store anything, just the client name and base configuration.
Clients could be very small and needs almost no local storage (just the space needed to cache images and data and that could even be in memory since at next boot it will reload all data).
It's even possible have embedded clients which will get XBMC client binaries from network and get configuration from server itself (maybe based on mac address).
This approach is possible even in a standalone situation with both server and client on the same pc.
Server will take care of collecting media from the various sources (local storage, network drives, upnp sources and any other source), call the needed scraper, store the informations and present them in a omogeneous way upon client request.
topfs2 Wrote:Not sure what your refering to with preferences and policies?
Preferences could be which one of the many available fan art to use for a particular media or user playlists or any "personalization" the user is able to do.
Policies define the rules to apply to choose which of the available media are presented to the client.
topfs2 Wrote:It might be that your suggestion can do more than uPnP but I'm guessing if we'd adopt and expand our uPnP you'd easily be 90% were you'd want and it would be a common standard that would / could work between different applications which is a far more satisfying end game IMO.
Agreed!
As i said, it could be a sort of upnp+authentication(by client name/user)+authorization (for the policies) + user feedback (playlist, preferences etc).
topfs2 Wrote:So it would be awsome to see standards produced regarding fanart and different coverart and such things so all the media center applications could use a standard setup of properties to ensure compability, then you wouldn't be tied down to XBMC (can't see why you would change application though Laugh).
I totally agree with you here!

Bye
Reply
#6
UPnP can handle writing metadata from client to server I believe. Obviously XBMC's setup doesn't handle this as yet - not sure if it can be done with platinum (the upnp lib we use) or not.

IMO this is most definitely the way forward.

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply

Logout Mark Read Team Forum Stats Members Help
XBMC Protocol0