Improved UPnP serving and client

(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:

http://forum.xbmc.org/showthread.php?tid...pid1108279
http://forums.plexapp.com/index.php/topi...-for-xbmc/

https://github.com/hippojay/plugin.video.plexbmc


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 16:17)pecinko Wrote:  

(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!

Did I missunderstand your suggestion or did I make myself clearer?

Cheers,
Tobias

(2012-07-12 16:57)topfs2 Wrote:  Did I missunderstand your suggestion or did I make myself clearer?

I was aiming on 2 things in my reply.

Alcoheca said that he had taken a look at Plex for inspiration but was not able to explore to a greater extent because Plex lacks linux client. So I was just suggesting another way that would work.

Second thing was my concern about solving UI part of it or what will experience look like when we got functional solution. It may be early to think about that, I don't know, but I thought that it might make things easier later. Here, I really think Plex managed to solve things in smart way. You may have noticed that I did some skinning lately and although I managed to simplify things in my skins to a great extent I have found that some boundaries can not be jumped over. But maybe you have all this solved/planned already.

As for the standards, I agree to keep to them and make TVs and PVRs compatible. If you say expanded spec will allow for all other XBMC specific stuff, then all is great

Out of curiosity, is there anywhere where one can follow the progress of this item?

Thanks!

You can follow the progress here, if you can compile by yourself. https://github.com/alcoheca/xbmc/tree/upgrade-platinum

Maybe alcoheca could give us some insight, if it is already worthwhile to test the build. As due to my understanding the GCOS will end (coding) in 2 to 3 weeks maybe it would be a good time to release the first beta versions.

(2012-07-30 17:24)edrikk Wrote:  Out of curiosity, is there anywhere where one can follow the progress of this item?

Thanks!

Answer: set https://github.com/alcoheca/xbmc/branches as your homepage

(2012-07-31 09:16)Sylus Wrote:  You can follow the progress here, if you can compile by yourself. https://github.com/alcoheca/xbmc/tree/upgrade-platinum

Maybe alcoheca could give us some insight, if it is already worthwhile to test the build. As due to my understanding the GCOS will end (coding) in 2 to 3 weeks maybe it would be a good time to release the first beta versions.

I asked earlier on if people would test the upgrade-platinum branch, and the request still stands. I'm particularly interested in people who can test with WindowsMediaCentre/player/Xbox360 as I have no microsoft devices to test with.

That branch currently only builds on linux, so you'd need to build it on a linux box.