Author Topic: DLNA Media Controller plugin - Common library for UPnP AV  (Read 191158 times)

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
DLNA Media Controller plugin - Common library for UPnP AV
« on: October 06, 2013, 06:39:30 am »
Plugin version 0.8 has been released.
You can download it here (ZIP archive at the bottom of this page): http://code.mios.com/trac/mios_dlna-cntroller/browser/tags/1.0


What's new in version 1.0:

  • Device category updated (set to AV)
  • Short codes added for the following state variables: CurrentTitle, CureentArtist, CurrentAlbum, CurrentPlayMode and online
  • Plugin icon with transparency
  • Init all variables when the device is created

What's new in version 0.8:

  • Volume control added in the device panel
  • Volume control added in the UI player tab
  • New UI tab for TTS
  • AVTransport and RenderingControl services files renamed again

What's new in version 0.7:

  • New TTS library with multiple engines support
  • New parameter Engine for the Say action

What's new in version 0.6:

  • Fixed: relative URL in the XML description
  • Improove performance when browsing content + abort timeout (30 s) in case of very big content
  • Workaround for a bug in Freebox Player firmware 1.2.12

What's new in version 0.5:

  • Fixed: compatibility with MiniDLNA and Synology servers
  • Changed: log of debug information
  • New variable DebugLogs; default value is 0; value set to 1 enables log of additional debug information

What's new in version 0.4:
  • Fixed: Ignore case for transport actions (required for GMrender Media Renderer)
  • Fixed: handling protocol for the PS3 Media Server
  • Changed: Play action has now an optional parameter named "Protocol"
  • Changed! PlayDMSMedia action has now an additional parameter named "DescriptionURL"
  • UI Player and Settings tab: display of identity for discovered servers and renderers changed
  • UI Player tab: a protocol amongst all the protocols accepted by the Media Renderer can now be selected in addition to the URI
  • UI Player tab: new entry named "None" in the protocol pick list; when selected, no protocol information is delivered to the Media Renderer
  • UI Player tab: new info message displayed
  • UI Help tab: display information about last played media server object
  • UI Help tab: list of protocols accepted by the Media Renderer is now displayed in the Help tab
  • UI Settings tab: current Media Renderer is now selected by default in the "discover" pick list
  • New variable DelayBeforePlayback: delay in ms before SetAVTransportURI and Play; default value is 0
  • New variable CheckStateRate: delay in minutes between automatic state checks; default value is 0 meaning no automatic check
  • New variable DefaultLanguageTTS: default language (2 characters) used by TTS; default value is "en" meaning "english"
  • Changed: files renamed for AVTransport and RenderingControl services

What's new in version 0.3:
  • Fixed: browsing media from BubbleUPnP server
  • Fixed: compatibility check between the Media Renderer and the Media Server

What's new in version 0.2:
  • fixed: browsing of Media Servers
  • fixed: managing of URI with non standard characters like French accents
  • fixed: do not try to set AV transport URI when URI is not set (not found)
  • control added to find a compatible protocol between the media to be played with the protocols accepted by the Media Renderer
  • UI updated: browsing of Media Servers
  • UI updated: user can now select an available server protocol or let the plugin select automatically a protocol compatible with the Media Renderer
  • Scene editor: actions are now available in the devices tab
  • action BrowseDMS: parameters updated
  • action PlayItem: renamed into PlayDMSMedia and parameters updated
  • new variable SinkProtocolInfo: store the list (CSV) of protocols accepted by the Media Renderer
  • new variable CurrentAlbumArt2: same as CurrentAlbumArt except when CurrentAlbumArt is not accessible; in this case, it is set to a default album art

It is a classical installation, meaning you have to upload all the files with the Vera UI, except the PNG file that requires to be uploaded using WinSCP in directory /www/cmh/skins/default/icons/
Then create a new device using D_DLNAMediaController1.xml. Don't care about the IP. Restart LUA. When restarted, refresh your browser cache (Ctrl+F5). Then open the Settings tab to select your DMR, either using the UPnP discovery or filling in the UPnP device description URL. Wait few seconds until the setup is done and that's all, you can now open the Player tab.

Automatic discovery (UPnP discovery) could require an additional setup of your Vera Lite. Please read the explanations in this message if it does not work directly: ​http://forum.micasaverde.com/index.php/topic,16905.msg132502.html#msg132502

Known issues:
  • PS3 Media Server sometimes uses MIMITYPE_AUTO in the protocol information; it is not yet well managed by the plugin and the playback of the media will not be accepted by the plugin.
  • "Last server media played" field value displayed in the Help tab cannot always be copied and pasted in the parameter of the action PlayDMSMedia; depending on the server and the used format for the object id, it can work well or not.
« Last Edit: May 02, 2014, 07:34:35 am by lolodomo »

Offline garrettwp

  • Beta Testers
  • Master Member
  • *****
  • Posts: 6371
  • Karma: +227/-128
  • Vera 3, Lite, ISY994
Re: Common library and services for UPnP control
« Reply #1 on: October 06, 2013, 08:15:26 am »
Squeezebox plugin doesn't use upnp, it uses the telnet service of the squeezebox server. I'll look into seeing if it can support upnp.

- Garrett


Offline RichardTSchaefer

  • Master Member
  • *******
  • Posts: 10090
  • Karma: +762/-142
Re: Common library and services for UPnP control
« Reply #2 on: October 06, 2013, 10:42:36 am »
With this done ... how far from making Vera a DLNA Media Controller that can control any DLNA Media Server and Player ?
 


Offline futzle

  • Beta Testers
  • Master Member
  • *****
  • Posts: 3257
  • Karma: +191/-9
Re: Common library and services for UPnP control
« Reply #3 on: October 06, 2013, 04:59:58 pm »
A UPnP controller library is a natural next step.  I sort of had it in the back of my mind when I was writing the WeMo code, so it's sort of broken into platform-dependent functions and platform-independent functions.  I've got absolutely no time to commit to it, though, but I'll gladly donate any code that I've already written to the cause.

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Common library and services for UPnP control
« Reply #4 on: October 07, 2013, 05:44:13 am »
With this done ... how far from making Vera a DLNA Media Controller that can control any DLNA Media Server and Player ?

A UPnP AV / DLNA Media Controller would require 3 items:
- UPnP discovery of UPnP AV Media servers and UPnP AV Media renderer: - this is not implemented and may be bot easy from Vera (I don't know)
- Browse media on UPnP AV Media servers: this is more a user manual task and something that requires a good UI. Vera is not really a good choice for this task
- Send a media to a UPnP AV Media Renderer: this is typically what we can do with Vera.

Unfortunately, it exists a lot of UPnP AV Media Player (Playstation PS3, Freebox Player, some TV, some DVD and BR players, ...) but only few UPnP AV Media Renderers. Media Player don't provide UPnP interface for remote control by a Control Point. After a quick WEB search, the candidates for a control by a control point would be only:
- XBMC
- Windows Media Player/Connect
- BubbleUPnP (Android)
- Sonos

So, I can make a generic plugin for these few Media Renderers (XBMC and WMP).

PS: finally XBMC seems to not be a UPnP Media Server, there is no browse capability exposed to UPnP. It is a Media Player + Media Renderer.
PS2: Sonos is a Media Server + Media Renderer
« Last Edit: October 07, 2013, 06:28:49 am by lolodomo »

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Common library and services for UPnP control
« Reply #5 on: October 07, 2013, 05:48:02 am »
One problem to make something generic is that every device implements its own subset of UPnP AV services. This can be retrieved from the description (XML) file. With Vera, we are constrained by statically declared services.
And I even not sure that in Vera we can hevae different services with the same service type/id ?
Does DLNA defines standard services (AVTransport, RenderingControl, ...) ?

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Common library and services for UPnP AV / DLNA control
« Reply #6 on: October 07, 2013, 06:02:19 am »
On the DLNA Web site, we can serarch for certified DLNA products.
It look slike the Xbox 360 is a Media Renderer. So it could be probably controlled from the Vera too.

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Common library and services for UPnP AV / DLNA control
« Reply #7 on: October 07, 2013, 06:05:51 am »
Regarding BubbleUPnP: https://play.google.com/store/apps/details?id=com.bubblesoft.android.bubbleupnp&hl=fr
Quote
BubbleUPnP is a full featured UPnP/DLNA Control Point, UPnP Media Renderer and UPnP Media Server

So it is a new candidate.

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Common library and services for UPnP AV / DLNA control
« Reply #8 on: October 07, 2013, 06:07:10 am »
Updated list of UPnP AV Media Renderers:
- Xbox 360
- XBMC
- Windows Media Player/Connect
- BubbleUPnP (Android)
- Sonos

On Wikipedia, we can find the list of UPnP media render hardware: http://en.wikipedia.org/wiki/List_of_UPnP_AV_media_servers_and_clients
This list includes Sonos and Xbox 360. But it seems that this list includes few products that are only Media Player without ability to control by a remote control point, like for example "Panasonic Plasma Viera NeoPDP V10-Series". I will check again this evening.
So I am sure that the list in Wikipedia makes a clear distinction between Media Player and Media Renderer.
« Last Edit: October 07, 2013, 06:29:02 am by lolodomo »

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Common library and services for UPnP AV / DLNA control
« Reply #9 on: October 07, 2013, 06:22:51 am »
Do you think that browsing UPnP Media Server from the Vera could be of any real interest ?
Through actions ?
Through UI ?

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Common library and services for UPnP AV / DLNA control
« Reply #10 on: October 07, 2013, 07:07:19 am »
Regarding UPnP AV standards, we can find all services here: http://upnp.org/index.php/sdcps-and-certification/standards/sdcps/
So we could define the 4 different versions of AVTransport service for example.
But if I take Sonos example, it does not use the standard, Sonos add additional actions to the AVTransport:1 service.

So if we want something as generic as possible, we use the standards as services, but in this case, we could loose some actions really provided by certain UPnP devices.

Here are ideas:
- we could have a generic UPnP AV controller plugin, based on UPnP AV standards services.
- For Sonos plugin (example), we would define additional services, like Sonos_AVTransport:1 that will contain specific actions and state variables defined by Sonos that are not in the UPnP AV standards.

Other point: few URL are currently hardcoded, while they should be extracted from the description file, like control URL or event URL. But without UPnP discovery implementation, that would require that the user provides the URL for the XML device description file.
« Last Edit: October 07, 2013, 07:09:43 am by lolodomo »

Offline RichardTSchaefer

  • Master Member
  • *******
  • Posts: 10090
  • Karma: +762/-142
Re: Common library and services for UPnP AV / DLNA control
« Reply #11 on: October 07, 2013, 08:29:17 am »
We might need layers of shared components. I think it would be good to have components that match the standards where they are defined ... with a specialization layer that customizes for some specific devices. This would allow continued development to someday get to a DLNA controller.

On the other hand Vera App store provides no support for handling/managing/enforcing the dependencies between shared components.
It will not allow us to maintain the files as components and replicate in a plugin ... it enforces that ALL file names are unique across all plugins.

I have a shared evaluation engine between PLEG and PLTS in an invisible plugin called PLC. This is very confusing for users to have a plugin that has no devices on the UI ... and then of course they have the problem of making sure all components have compatible versions ...

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Common library and services for UPnP AV / DLNA control
« Reply #12 on: October 07, 2013, 10:40:29 am »
I could first create a generic plugin UPnP_AV_DMC, defining and implementing standard UPnP AV services. This plugin should be ok to control basically any existing UPnP DMR.
This generic plugin would become a template for any specific DMC plugin, like Sonos or XBMC for example.
A specific DMC plugin would allow to add non standard features. It will consist in:
- defining new dedicated services for non standard actions and state variables
- implementing some of the standard services actions and dedicated services
- using the generic plugin library for the standard stuff
- adding specific code, including UI, for the non standard stuff

The generic plugin would include:
1 - a common library for UPnP:  the current L_Sonos1.lua library + additional utility functions relative to UPnP proxy event plugin; a check has to be done to WeMo plugin for UPnP request code, in case it is better handled in WeMo plugin.
2 - a common library for standard UPnP AV with all standard actions implemented

Offline guessed

  • Master Member
  • *******
  • Posts: 5293
  • Karma: +90/-22
  • Release compat is not a bolted-on afterthought
Re: Common library and services for UPnP AV / DLNA control
« Reply #13 on: October 07, 2013, 12:56:58 pm »
Regarding UPnP AV standards, we can find all services here: http://upnp.org/index.php/sdcps-and-certification/standards/sdcps/
So we could define the 4 different versions of AVTransport service for example.
But if I take Sonos example, it does not use the standard, Sonos add additional actions to the AVTransport:1 service.
It's part of the [UPnP] standard to permit "extensions", and these (both state and action) are permitted to live within the existing Service files (but these must be downloadable/discoverable from the Device.  These are logically in the same namespace, so putting them into separate/special S_ files, in addition to the standard/baseline ones, might cause havoc on the declarations in the corresponding D_*.xml files

This is why I checked in the Sonos ones as S_Sonos*.xml, which also avoids NS collisions.

Technically, and with a little work, these could be dynamically downloaded/stored as required.  They'd likely end up with odd-looking names, but it would then be possible to code-gen the wrappers using (a derivative of) L_Sonos.lua

This is functionality that's supposed to be in Vera, but has never really worked.

Anyhow, given there aren't that many things that folks want to control, and it's not too hard to do the important ones by hand.  The hard part here is that Vera lacks a dependency system.  These could readily be packaged into a Lib (plus related files) but we'd be left without a mechanism to indicate that "Plugin X requires Lib Y" from the App Store.

There would also need to be a LOT more thought given to compatible changes over time.


On Squeezebox...
The original Sonos plugin had several things done to it to support a UPnP interface to SqueezeBox, at the [PM] request of 'Ap.  Not sure that the validation was ever done though.

On L_Sonos.lua...
The one thing I should have done when I originally wrote this is to extract out the "Connection" level information, into a connection object, and then have the service-level objects require that.  It wouldn't be a hard change to make, and I'd make it before broadening the usage of this lib, since there are other "things" that need the connection also.

Offline lolodomo

  • Moderator
  • Master Member
  • *****
  • Posts: 3484
  • Karma: +74/-10
Re: Common library and services for UPnP AV / DLNA control
« Reply #14 on: October 07, 2013, 02:07:19 pm »
A usual, you break my enthousiasm :) If I listen to you, I just do nothing because the ideal cannot be reached (due to MCV implementaition or bugs) :)
My idea is more to do what is possible to do with what we have. And I think there is now place for a generic UPnP AV Media Control plugin.

Ok, we keep a full service file for each specific UPnP device. I just discovered that they can be easily retrieved from one URL displayed by Device Spy. No need to create the file manually.
I can at least create the standard services for the generic UPnP device.

Technically, what I want to improove is at least get device supported services from the device description file and then filter these services to keep only the services having a service type defined in the D_xxx.xml file. Then I will automatically initialize in the plugin code a service (call to upnp.service) for these services. Is it possible with lua to go through the services attached to a device ? Edit: function device_supports_service should help me.
« Last Edit: October 07, 2013, 02:27:05 pm by lolodomo »