[mythtv-users] uPnP Music in 0.27.3 - cannot read file

Ludvik Tesar ludvik.tesar at gmail.com
Wed Jul 9 10:28:49 UTC 2014


John Pilkington <J.Pilk at tesco.net> wrote ..
> On 08/07/14 23:34, Jean-Yves Avenard wrote:
> > ....
> >
> > Just tried it on my Sony Bravia , music plays just fine against 0.27.3
> >
> 
> ... so maybe it's part of the #9446 'fix for Sony' package.  I'm about 
> to go off-line again.

Hi John,

It seem not to be so. That patch seem to affect only recordings or video and you have problems with music only, if I understood well. The code for video, recordings and music is in three separated source files upnpcdsvideo.cpp, upnpcdstv.cpp, upnpcdsmusic.cpp.

If we return to the xml file that you obtained from my shell script: URLs found in that XML output are the same URLs that your UPnP device uses to fetch the music file, so these URLs simply must work. They must provide binary stream, so your browser should at least offer you to save the file or offer you to play them. These URLs actually no longer point to anything inside UPnP implementation in mythbackend, they point to Content Services API nicely documented in http://www.mythtv.org/wiki/Content_Service. You can test functionality of this service separately. It must work in order for UPnP to work. UPnP mythbackend functionality only provides the soap service that gives list of recordings or music or videos to the UPnP client. So, if you do not see correct media URLs in the XML response(URLs must be adhering to the services API wiki), then there is problem in UPnP implementation in mythbackend.  If you can see them, and they seem ok, but they do not give you correct binary streams (i
 t seem to me this is your problem), then there is some problem in services API or you have some misconfiguration due to which the API does not see the actual media files (due to permissions/network file sharing issues etc.). If you are looking at the XML output, another interesting thing worth checking is the duration="something" attribute. If the duratiuon value is wrong, my client (and your client too, re your note in my trac ticket #12187), jumps/FF/REW incorrectly. Also, protocolInfo must look reasonable. In my case (for music) it says protocolInfo="http-get:*:audio/mpeg:DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000". In case of recordings, I see protocolInfo="http-get:*:video/mpeg:DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000;DLNA.ORG_PN=MPEG_TS_SD_NA_ISO". For recordings and videos only, my script might see there something else than Sony Bravia or Windows Media Player vers >= 12.0. Specifically, they see video/avi o
 r video/x-ms-dvr instead of video/mpeg, and they do not see DLNA.ORG_PN=MPEG_TS_SD_NA_ISO. This is subject to patches in ticket #9446 mentioned by you earlier.

Unfortunately, I can not test UPnP Music now, because I am using 0.27.2 + my own fixes + additions to UPnP. My fixes only make changes in Recordings and Videos, I did not bother to fix Music, as I do not use DLNA for Music, so most likely I have wrong port. However, I already have sources for 0.27.3 downloaded. Today in the evening (GMT+1+DST timezone) I plan to merge it with my UPnP additions and Music should work too.

If you are interested, my additions to UPnP are : 12202, 12187, 12190, 12192 (patches are against master there) and I am also using the two pathches from someone else :
https://github.com/MythTV/mythtv/commit/378fe051f1d96d4e341391a1a21c6f0adec83f65
https://github.com/MythTV/mythtv/commit/d2a14f2366e362e40c8a98bd1b0bcd9f0fd3d56a
and I have them backported to 0.27.2. I have also removed making "duration" attribute (mentioned above) from upnpcdsvideo.cpp, as it plays better without duration attribute with my client. But have not submitted that anywhere as I am suspicious it might break someone else's UPnP that depends on it.

In my opinion the UPnP code in mythbackend is pretty simple and any bug is easy to find. It is why I was able to amend it according to my needs, removed few bugs that affected my specific client and I am happy to return resulting patches to the "community". I will be more than happy to help to remove your current problem with music part of UPnP. From your discussion with Jean-Yves it seems that there is slight misconfiguration due to which your services API does not provide correct audio streams to UPnP clients, but I might be wrong. I did not understand what is exactly difference of 192.168.0.5 and 192.168.0.9 in your network (I suppose 192.168.0.6 is UPnP client machine).

Regards,
Ludvik


More information about the mythtv-users mailing list