Summary: Despite it’s age, UPnP-AV is still the de facto standard for multimedia sharing in the home. Hundreds of products throughout millions of homes support UPnP to varying degrees. This propagation of devices represent a largely untapped potential to increase the relevancy of XBMC. Currently, XBMC operates both as a UPnP ‘media server’ and a ‘media renderer/control point’ (client), however it does not fully utilize the protocol to provide as rich as user experience as possible, and some third-party devices are incapable of streaming the content from XBMC altogether. The aim of this project is to extend the existing UPnP handling within the application, enhancing both the underlying code for the ease of future development, increasing the support for existing devices, while making great improvements to the end user’s perceptions as a whole.

How will I achieve this: As it stands, there is already an existing approach to accessing one or more libraries across multiple XBMC clients - sharing the actual SQL database - however this approach has its flaws and is not likely to become a supported feature. In terms of UPnP, there are a number of areas where the existing handling can be improved:

not all the available information for files is offered to clients

discovery of media servers is not immediately clear to new users

UPnP sources are not integrated into the local library views

there is no support for tracking access to the files in the server component (such as watched-status, last played position)

crucially there is the limiting factor of no support for transcoding video & audio files to formats accepted by the player. Many existing devices support a very limited number of video and audio formats. If XBMC is to operate not only as a media player, but a viable server it must also cater for as many appliances as possible.

access restriction is non-existent

My approach will be to initially tackle the easiest changes - metadata, automatic discovery, library integration, before moving onto the major part of developing client <-> server communication via UPnP protocol extensions. Real-time transcoding of media files can be achieved through proper management of DLNA profiles, and the actual work would be performed by third party applications such as FFmpeg or lame.

Supporting access restrictions over UPnP require further changes to the profile handling of the application which may not be feasible in the timeframe. While I will not be working on developing a separate server application, it’s worth pointing out that the changes to the server side will be easily transferable in the future.

Benefits: Increasing numbers of XBMC users rightly expect the application to take full advantage of today’s multi-device environments. With the advent of low cost NAS devices, frontends such as the RaspberryPi, and more generally the gradual diversification of technology in the home, XBMC has the opportunity to reassert itself as the principle sustainable & open media-center of the future. Users benefit from a richer experience overall, as well as the increasing utilization of existing UPnP devices in their homes, while developers benefit from the adoption of a stable framework for server/client communications.

Goals: The main goal is to bring UPnP fully into the forefront of XBMC, making use of those features to reduce setup times, allow greater control over multiple players, provide a richer user experience and increase the flexibility of the platform overall.

What does it touch in XBMC: The majority of the client-side changes will take place in the file system and library layers. There will also be some modifications to the user interface in order to enumerate connected devices more easily. For the server-side changes, my attention will be focussed on maximising portability and interoperability with other servers. Even though it’s likely that eventually an distinct XBMC server application will exist, it’s important that backwards compatibility with standard UPnP devices is maintained.

Requirements: The changes will take place exclusively in the application itself, so all that is required is knowledge of C++ and the source tree. Having access to other UPnP supporting devices, I will be well positioned to test their functionality during the development process, something that is crucial to the success of this project.

How long have you been writing software for work/fun? I’ve been writing software for over 10 years. Initially I worked on web development, before shifting to C++ during my first year at University. Since then I’ve worked with other languages, notably Java & Perl.

What is your primary development language/environment? C/C++ via GNU/Linux.

Is this your first GSOC? No, I participated in the Summer of Code of ‘08.

Have you contributed to XBMC or other FLOSS projects? For my first GSoC, I worked on the beginnings of the PVR branch. During that summer I became accustomed with the XBMC source tree and was also allowed the opportunity to meet many new colleagues at the inaugural developers convention in Amsterdam. I was asked to join as a permanent team member in the autumn of 2008. I was also instrumental in refactoring the Add-ons system in 2009.

Add an FFmpeg based on-the-fly transcoder and remuxer to that and it is a super idea!

Transcoder would enable you to playback audio and video formats not supported on some devices, or on devices that do not support high definition videos, as well as have place shifting capability to access your home library over a slower internet / WAN link from a friends house or on your mobile devices over 3G / 4G

Remuxer would solve the PS3 / Xbox 360 issue with them playing H264 but not supporting MKV containers.

Little update - I'm upgraded the Platinum library to the latest version, and have a much better understanding of the workings now(!). If anyone is brave and has a working UPnP setup in their house, feel free to compile the upgrade-platinum branch from my fork on github and let me know of any problems in this thread - NOT the bug system! There shouldn't be any new features, but reports of bugs that have been fixed would be gratefully appreciated. No binaries will be available, so if you can't compile you'll need to wait I'm afraid.

I'm now looking at improving the sorting of files returned by the server, and how best to handle the 'quirks' database - i.e. the mappings of specific behaviour to certain (naughty) devices. UPnP is highly extensible, so our support for it should be the same.

As it happens, I just posted a Trac ticket which aligns with what you're trying to do here!

Great job, as DLNA is quite useful, and when done correctly, rather functional. As others mentioned on this thread, even though the Plex implementation is in its infancy, it is quite possibly the best implementation I've seen in my usecases yet in terms of meta-data etc (I've used PS3 Media Server, Twonky, XBMC DLNA, Serviio, Plex, Fuppes, MediaTomb, so I speak from experience).

Looking forward to seeing this!

PS. Say what you will about others (e.g. Plex), but you have to give a nod when something is done right.
PPS. I apprecaite greatly the fact that XBMC mods/forum doesn't censor out 'competition' names, allowing for proper discussion. +1 for that!

Can you tell if picture streaming over UPNP is also part of your plans? Unlike video and audio, pictures aren't stored in a database but they (and their metadata) are cached, which has recently changed drasticly.

As far as I know picture streaming over UPNP in XBMC Eden/Frodo is fixed but needs some work also. But the release notes of XBMC 9 (Camelot) said "Ability to view pictures over UPnP in XBMC, also loads of fixes to the UPnP library"

Nice. I just got pointed to this thread by JoetheFox. I didn't know anyone was working on transcoding features for XBMC. I toyed around with Plex a couple months ago to see how they did it. I didn't get very far into it before I gave up and pitched it. I've been using AirVideo for years for streaming to my iPod and it works so well. I've not found anything quite as easy to setup and use as that. I used Serviio, Mezzmo and PS3 Media Server for a short while trying to stream video to my Sony TVs and iPod/Android devices. Each worked pretty well, but still nothing as well as Airvideo. I'm looking forward to see what you do with this. If you need testing on the Windows side of things, I'd be happy to help. I can compile on my own. I'd love to see a server that can run on my unRaid box (Slackware linux variation) where all my media resides.

(2012-06-09 02:41)jmarshall Wrote: The server is closed, so I doubt any code would trickle anywhere.

(2012-06-16 15:52)alcoheca Wrote: I've been having a good look at the Plex server, from a user perspective of course. I can't play with the client as I don't have a Mac or a windows machine.

Yes, this is true but there are still things that could be used or at least tried out.

Plex client is on git (there's a link in Mac support section) it was posted a while ago when auto refresh switching was discussed. So it can be seen how server XMLs are being parsed out. Here you can find XBMC add-on that provides communication with Plex server and allows XBMC to use and stream content from it:

I will skip the part about what I don't like about Plex as it was discussed before and only point to those facts that, IMO, are solved better.

Home page items are served from a server, meaning that you will not see Music section if you do not use it. OTOH, you can define 2 different music sources as 2 different Music libraries and they will pop-up as 2 items on Home page. This solves the need to have separate sections on Home page without the need of making custom links for, say, anime, home videos or such.

Second step in UI is a long list of available filters, first being All movies for Movies section (Movies-all_movies-content). This allows for simple and efficient user interface to use on any client, IMO (HomeItem-Filter-Content).

What this has to do with UPnP serving? Say I want to use it on my Panasonic TV (DLNA certified). What sections would appear on home screen ones I have chosen XBMC server? How do I navigate to content? Over the years for one reason or the other people got used to... "banding" the XBMC UI - custom sections on home screen, go directly to movies, some use videos with flattening, some custom playlists from home screen, some opted not to use library and are making custom links to files to name just a few.

As for the streaming part I would not mind lack of transcoding in the beginning. Most of clients are able to play 720/1080 h264 content and I would personally see it as more important to have local XBMC network functional and easy to use before thinking about streaming over 3G from my home to a hotel room.

(2012-07-12 13:16)pecinko Wrote: Plex client is on git (there's a link in Mac support section) it was posted a while ago when auto refresh switching was discussed. So it can be seen how server XMLs are being parsed out. Here you can find XBMC add-on that provides communication with Plex server and allows XBMC to use and stream content from it:

The uPnP standard has documents stating exactly how the XMLs are supposed to look, if they aren't following it, following them is beyond bad If they have extended the uPnP standard (within what is allowed) then looking at standardizing their extensions might be valid. However there exist plenty of rdf and semantic standards which they ought to use if extending. In short, I doubt looking at their client code will do anything besides confuse and make this project about supporting their implementation, which is bad

EDIT: With that said I must say I'm happy to see that they came to their senses and added uPnP support, while uPnP may have a bad name (due to those which doesn't follow it properly) their server should have used uPnP from the get go IMO

(2012-07-12 14:12)topfs2 Wrote: The uPnP standard has documents stating exactly how the XMLs are supposed to look, if they aren't following it, following them is beyond bad If they have extended the uPnP standard (within what is allowed) then looking at standardizing their extensions might be valid. However there exist plenty of rdf and semantic standards which they ought to use if extending. In short, I doubt looking at their client code will do anything besides confuse and make this project about supporting their implementation, which is bad

You might be right, I really don't know, but it seems that you're making assumptions and don't know for sure. This really does not matter, IMO, as this talk is between Plex server and Plex clients. See why it does not matter below.

Quote:EDIT: With that said I must say I'm happy to see that they came to their senses and added uPnP support, while uPnP may have a bad name (due to those which doesn't follow it properly) their server should have used uPnP from the get go IMO

It looks like you're assuming they made it out of standards (if they made it, I don't know) for sole purpose of doing it that way. I have a hard time believing this.

What maybe makes some more sense to me is that they:

- improved library and solved custom sections, navigation in easy way
- made Mac only Plex local network possible without MySql
- added transcoding and mobile clients support
- added support for DLNA clients

Plex server 2 plex clients communication may be non uPnP, but support all XBMC/PLEX features. Plex server 2 non Plex clients is uPnP based and does not support most of XBMC/Plex features (fanart to name one).

Looking at this, this seems to me as a clever way to go as it make little sense to me to cripple HTPC XBMC clients support for the sole purpose of using standardized communication where it does not fit well. OTOH, sticking to standards is very much required for other clients that does not run XBMC.

Either way, trying out Plex solution may be beneficial and I do not believe it will make XBMC uPnP solution end up as Plex client only.

(2012-07-12 14:12)topfs2 Wrote: The uPnP standard has documents stating exactly how the XMLs are supposed to look, if they aren't following it, following them is beyond bad If they have extended the uPnP standard (within what is allowed) then looking at standardizing their extensions might be valid. However there exist plenty of rdf and semantic standards which they ought to use if extending. In short, I doubt looking at their client code will do anything besides confuse and make this project about supporting their implementation, which is bad

You might be right, I really don't know, but it seems that you're making assumptions and don't know for sure. This really does not matter, IMO, as this talk is between Plex server and Plex clients. See why it does not matter below.

Quote:EDIT: With that said I must say I'm happy to see that they came to their senses and added uPnP support, while uPnP may have a bad name (due to those which doesn't follow it properly) their server should have used uPnP from the get go IMO

It looks like you're assuming they made it out of standards (if they made it, I don't know) for sole purpose of doing it that way. I have a hard time believing this.

I didn't mean any disrespect to Plex, just said that for this project the idea is to better uPnP, and doing so doesn't necessarily mean it would help looking at Plex. There are plenty of clients out there which are far more interesting to support, like TVs or PVRs

(2012-07-12 16:17)pecinko Wrote: What maybe makes some more sense to me is that they:

- improved library and solved custom sections, navigation in easy way
- made Mac only Plex local network possible without MySql
- added transcoding and mobile clients support
- added support for DLNA clients

uPnP can do all of these, as explained below

(2012-07-12 16:17)pecinko Wrote: Plex server 2 plex clients communication may be non uPnP, but support all XBMC/PLEX features. Plex server 2 non Plex clients is uPnP based and does not support most of XBMC/Plex features (fanart to name one).

Looking at this, this seems to me as a clever way to go as it make little sense to me to cripple HTPC XBMC clients support for the sole purpose of using standardized communication where it does not fit well. OTOH, sticking to standards is very much required for other clients that does not run XBMC.

Either way, trying out Plex solution may be beneficial and I do not believe it will make XBMC uPnP solution end up as Plex client only.

Core of uPnP does not allow for some of the features xbmc posses, as fanart. However, its fully within the uPnP spec to expand, given that you follow their exansion rules. All items have a class and based on their class a set of required properties and a set of optional, its fully ok to add properties if needed, its recommended to do so by adding to the class without breaking it on devices who don't understand said class. So in short, its fully possible to have xbmc server -> xbmc clients to talk over uPnP and share fanart etc, if a non xbmc-client who doesn't understand the expanded metadata it will become crippled but still work.

So it does fit extremely well to use uPnP, which is why this gsoc was suggested and chosen.

And, if we wanted to go a non-standard route, which is not what this thread is about, we could have used JSONRPC as a base. Which already could allow for distributed xbmc boxes, the goal however with this project is to work with more devices than xbmc.

And on the topic of not using standards even if its not 100% fit, at most times its better to use the standards even if its not perfect, otherwise you just end up adding complexity to the ecosystem as a whole. As xkcd explains well, http://xkcd.com/927/

Ok since I made the thread go perhaps offtopic I'll try to steer it back

@pecinko
If I understood your suggestion you meant that even if plex server is closed we could look at the client to see how it has implemented uPnP, so that we can look at how they have organized the XMLs?

What I wanted to answer was: If they are following the uPnP standard its better if we look at the uPnP documents, since they and we could missunderstand the documents and its better if all just reads from the same document, minimizing the missunderstandings.
If they have expanded upon the standard it might very well be interesting reading how they have done that, but we need to be 100% sure they have done so within the spec, if they have done that (not saying they haven't) then using their expands in xbmc might very well make sense. The point I was trying to make is that its vital that we don't accidently stray off standard so that TVs and PVRs accidently stop working, this seems safer if we follow uPnP core and only expand the standard where we are 100% sure its allowed!