Upnp with 0.28

[ris2t]

Since upgrading to MythTv 0.28 (as part of Ubuntu Xenial 16.04) MythTV browsing via UPNP/DLNA nolonger works on a number of devices. These all worked fine on 0.27.x.

Is there a switch in 0.28 to allow these previous working clients to work again? I see from the notes that uPnP has been refreshed to align with the standards but in practice breaking compatibility with 3 out of 4 clients doesn't help me use MythTV as a PVR system.

Clients:
Samsung TV 40C6900 - worked well under mythtv 0.27 and below.
- appears as a device, errors with ""
iOS VLC Player 2.7.5 - appears as a device, shows no listing.
iOS videoCast - appear as a device, errors with "No supported Media"

iOS 8 Player Lite 2.14 - continues to work. Seems to query upnp differently.

Issue:
Devices appear to discover the MythTV upnp service and generate an initial log. But when they browser for media no traffic appears or is registered.

For the Samsung TV the following upnp logs are generated (--setverbose upnp ...)

Code: Select all

2016-04-25 17:56:58.401199 I [1706/1779] SSDP ssdpcache.cpp:132 (Remove) - SSDP Cache removing USN: uuid:e17980d4-e85b-6e47-76bf-b0595abd8da8::upnp:rootdevice Location http://192.168.50.54:52235/dmr/SamsungMRDesc.xml                                                       
2016-04-25 17:56:58.401363 I [1706/1779] SSDP ssdpcache.cpp:132 (Remove) - SSDP Cache removing USN: uuid:e17980d4-e85b-6e47-76bf-b0595abd8da8 Location http://192.168.50.54:52235/dmr/SamsungMRDesc.xml                                                                        
2016-04-25 17:56:58.401483 I [1706/1779] SSDP ssdpcache.cpp:132 (Remove) - SSDP Cache removing USN: uuid:e17980d4-e85b-6e47-76bf-b0595abd8da8::urn:schemas-upnp-org:device:MediaRenderer:1 Location http://192.168.50.54:52235/dmr/SamsungMRDesc.xml                           
2016-04-25 17:56:58.402028 I [1706/1779] SSDP ssdpcache.cpp:132 (Remove) - SSDP Cache removing USN: uuid:e17980d4-e85b-6e47-76bf-b0595abd8da8::urn:schemas-upnp-org:service:RenderingControl:1 Location http://192.168.50.54:52235/dmr/SamsungMRDesc.xml                       
2016-04-25 17:56:58.402163 I [1706/1779] SSDP ssdpcache.cpp:132 (Remove) - SSDP Cache removing USN: uuid:e17980d4-e85b-6e47-76bf-b0595abd8da8::urn:schemas-upnp-org:service:ConnectionManager:1 Location http://192.168.50.54:52235/dmr/SamsungMRDesc.xml                      
2016-04-25 17:56:58.402274 I [1706/1779] SSDP ssdpcache.cpp:132 (Remove) - SSDP Cache removing USN: uuid:e17980d4-e85b-6e47-76bf-b0595abd8da8::urn:schemas-upnp-org:service:AVTransport:1 Location http://192.168.50.54:52235/dmr/SamsungMRDesc.xml                            
2016-04-25 17:56:58.411270 I [1706/1779] SSDP ssdpcache.cpp:132 (Remove) - SSDP Cache removing USN: uuid:21e41ca1-ca1a-6eee-db34-4f0fa98f279c::upnp:rootdevice Location http://192.168.50.54:52235/pmr/PersonalMessageReceiver.xml                                             
2016-04-25 17:56:58.411428 I [1706/1779] SSDP ssdpcache.cpp:132 (Remove) - SSDP Cache removing USN: uuid:21e41ca1-ca1a-6eee-db34-4f0fa98f279c Location http://192.168.50.54:52235/pmr/PersonalMessageReceiver.xml                                                              
2016-04-25 17:56:58.411593 I [1706/1779] SSDP ssdpcache.cpp:132 (Remove) - SSDP Cache removing USN: uuid:21e41ca1-ca1a-6eee-db34-4f0fa98f279c::urn:samsung.com:device:PersonalMessageReceiver:1 Location http://192.168.50.54:52235/pmr/PersonalMessageReceiver.xml            
2016-04-25 17:56:58.411926 I [1706/1779] SSDP ssdpcache.cpp:132 (Remove) - SSDP Cache removing USN: uuid:21e41ca1-ca1a-6eee-db34-4f0fa98f279c::urn:samsung.com:service:MessageBoxService:1 Location http://192.168.50.54:52235/pmr/PersonalMessageReceiver.xml                 
2016-04-25 17:56:58.419426 I [1706/1779] SSDP ssdpcache.cpp:132 (Remove) - SSDP Cache removing USN: uuid:69549009-5dce-5f87-de48-3d0e35f050a2::upnp:rootdevice Location http://192.168.50.54:52235/rcr/RemoteControlReceiver.xml                                               
2016-04-25 17:56:58.419611 I [1706/1779] SSDP ssdpcache.cpp:132 (Remove) - SSDP Cache removing USN: uuid:69549009-5dce-5f87-de48-3d0e35f050a2 Location http://192.168.50.54:52235/rcr/RemoteControlReceiver.xml                                                                
2016-04-25 17:56:58.419702 I [1706/1779] SSDP ssdpcache.cpp:132 (Remove) - SSDP Cache removing USN: uuid:69549009-5dce-5f87-de48-3d0e35f050a2::urn:samsung.com:device:RemoteControlReceiver:1 Location http://192.168.50.54:52235/rcr/RemoteControlReceiver.xml                
2016-04-25 17:56:58.420457 I [1706/1779] SSDP ssdpcache.cpp:132 (Remove) - SSDP Cache removing USN: uuid:69549009-5dce-5f87-de48-3d0e35f050a2::urn:samsung.com:service:TestRCRService:1 Location http://192.168.50.54:52235/rcr/RemoteControlReceiver.xml                      
2016-04-25 17:57:21.708550 I [1706/1761] TVRecEvent tv_rec.cpp:3685 (TuningFrequency) - TVRec[1]: TuningFrequency                                                                                                                                                              
2016-04-25 17:57:37.675676 I [1706/1779] SSDP ssdpcache.cpp:116 (Insert) - SSDP Cache adding USN: uuid:e17980d4-e85b-6e47-76bf-b0595abd8da8::upnp:rootdevice Location http://192.168.50.54:52235/dmr/SamsungMRDesc.xml                                                         
2016-04-25 17:57:37.700065 I [1706/1779] SSDP ssdpcache.cpp:116 (Insert) - SSDP Cache adding USN: uuid:e17980d4-e85b-6e47-76bf-b0595abd8da8 Location http://192.168.50.54:52235/dmr/SamsungMRDesc.xml                                                                          
2016-04-25 17:57:37.723385 I [1706/1779] SSDP ssdpcache.cpp:116 (Insert) - SSDP Cache adding USN: uuid:e17980d4-e85b-6e47-76bf-b0595abd8da8::urn:schemas-upnp-org:device:MediaRenderer:1 Location http://192.168.50.54:52235/dmr/SamsungMRDesc.xml                             
2016-04-25 17:57:37.747203 I [1706/1779] SSDP ssdpcache.cpp:116 (Insert) - SSDP Cache adding USN: uuid:e17980d4-e85b-6e47-76bf-b0595abd8da8::urn:schemas-upnp-org:service:RenderingControl:1 Location http://192.168.50.54:52235/dmr/SamsungMRDesc.xml                         
2016-04-25 17:57:37.771538 I [1706/1779] SSDP ssdpcache.cpp:116 (Insert) - SSDP Cache adding USN: uuid:e17980d4-e85b-6e47-76bf-b0595abd8da8::urn:schemas-upnp-org:service:ConnectionManager:1 Location http://192.168.50.54:52235/dmr/SamsungMRDesc.xml                        
2016-04-25 17:57:37.795273 I [1706/1779] SSDP ssdpcache.cpp:116 (Insert) - SSDP Cache adding USN: uuid:e17980d4-e85b-6e47-76bf-b0595abd8da8::urn:schemas-upnp-org:service:AVTransport:1 Location http://192.168.50.54:52235/dmr/SamsungMRDesc.xml                              
2016-04-25 17:57:37.819311 I [1706/1779] SSDP ssdpcache.cpp:116 (Insert) - SSDP Cache adding USN: uuid:21e41ca1-ca1a-6eee-db34-4f0fa98f279c::upnp:rootdevice Location http://192.168.50.54:52235/pmr/PersonalMessageReceiver.xml                                               
2016-04-25 17:57:37.843099 I [1706/1779] SSDP ssdpcache.cpp:116 (Insert) - SSDP Cache adding USN: uuid:21e41ca1-ca1a-6eee-db34-4f0fa98f279c Location http://192.168.50.54:52235/pmr/PersonalMessageReceiver.xml                                                                
2016-04-25 17:57:37.867092 I [1706/1779] SSDP ssdpcache.cpp:116 (Insert) - SSDP Cache adding USN: uuid:21e41ca1-ca1a-6eee-db34-4f0fa98f279c::urn:samsung.com:device:PersonalMessageReceiver:1 Location http://192.168.50.54:52235/pmr/PersonalMessageReceiver.xml              
2016-04-25 17:57:37.891213 I [1706/1779] SSDP ssdpcache.cpp:116 (Insert) - SSDP Cache adding USN: uuid:21e41ca1-ca1a-6eee-db34-4f0fa98f279c::urn:samsung.com:service:MessageBoxService:1 Location http://192.168.50.54:52235/pmr/PersonalMessageReceiver.xml                   
2016-04-25 17:57:37.915301 I [1706/1779] SSDP ssdpcache.cpp:116 (Insert) - SSDP Cache adding USN: uuid:69549009-5dce-5f87-de48-3d0e35f050a2::upnp:rootdevice Location http://192.168.50.54:52235/rcr/RemoteControlReceiver.xml                                                 
2016-04-25 17:57:37.940738 I [1706/1779] SSDP ssdpcache.cpp:116 (Insert) - SSDP Cache adding USN: uuid:69549009-5dce-5f87-de48-3d0e35f050a2 Location http://192.168.50.54:52235/rcr/RemoteControlReceiver.xml                                                                  
2016-04-25 17:57:37.963285 I [1706/1779] SSDP ssdpcache.cpp:116 (Insert) - SSDP Cache adding USN: uuid:69549009-5dce-5f87-de48-3d0e35f050a2::urn:samsung.com:device:RemoteControlReceiver:1 Location http://192.168.50.54:52235/rcr/RemoteControlReceiver.xml                  
2016-04-25 17:57:37.987064 I [1706/1779] SSDP ssdpcache.cpp:116 (Insert) - SSDP Cache adding USN: uuid:69549009-5dce-5f87-de48-3d0e35f050a2::urn:samsung.com:service:TestRCRService:1 Location http://192.168.50.54:52235/rcr/RemoteControlReceiver.xml                        

Above I believe is the initial discovery when the TV starts.

Below is when a browse of the device is attempted.

Code: Select all

2016-04-25 17:57:43.165810 I [1706/4485] HttpServer112 upnpcds.cpp:759 (HandleGetFeatureList) - UPnpCDS::ProcessRequest : /CDS_Control : X_GetFeatureList                                                                                                                      
2016-04-25 17:57:43.606777 I [1706/4485] HttpServer110 upnpcds.cpp:759 (HandleGetFeatureList) - UPnpCDS::ProcessRequest : /CDS_Control : X_GetFeatureList

Below the logs for when iOS VLC player selects mythtv and lists nothing. It would seem no browse type action is recognized or logged.

Code: Select all

2016-04-25 18:14:16.379429 I [1706/1779] SSDP ssdpcache.cpp:116 (Insert) - SSDP Cache adding USN:  Location 
2016-04-25 18:14:23.045684 I [1706/1779] SSDP ssdpcache.cpp:132 (Remove) - SSDP Cache removing USN:  Location 

Any suggestion on how to further debug or resolve this issue. My use of MythTV as a PVR system is pretty much dead in the water.

Thanks
Raymond

[stuartm]

We will be implementing a workaround for this, but the simple answer is that all of the clients/devices which no longer work are not UPnP compliant. VLC's UPnP stack in particular is a steaming pile that will actively DOS UPnP servers, if it was able to connect in the first place which it's not.

So we WILL provide a fallback for broken clients from our end, but I'd also ask that you report these issues to the developers/manufacturers of the client devices you are using otherwise they'll never bother to fix them.

[kcorey]

Any idea when the workaround fallback will go into effect? I have two Samsung TVs (2013 and 2014) that allows me to browse folders on the myth server, but doesn't let me see the files. I'm running 0.28 on Arch.

Sent from my Nexus 6 using Tapatalk

[marbaz]

Hello.

I have the same problem.

I use MythTV UPNP since 2011 with a samsung UE55D8000 and until last days it works very good.

But since i upgrade to Ubuntu 16.04 with MythTV 0.28, i can't read my records any more.

I can navigate in the records repertory but when i want to play one the TV show this message : "Not supported file format".

I have no hope for un upgrade to my old TV by Samsung...

[dany2mythtv]

Hello,

Same problem with Samsung UE40F6500SDXZT after upgrade from mythtv 0.27 to mythtv 0.28.

The TV found the mythtv server (with a new icon) but all folders are empty.

Thanks
Daniele

[ris2t]

Any idea when the workaround fallback will go into effect? I have two Samsung TVs (2013 and 2014) that allows me to browse folders on the myth server, but doesn't let me see the files. I'm running 0.28 on Arch.

Nudge, some guidance on when or if backwards compatibility will be available would be appreciated. Similarly, older Samsung TV no hope of it being patched.

As its stands Myth Tv 0.28 is no good as my PVR system. Can't justify upgrading all my playback devices.

Options?
- down grade to 0.27, proving challenging as no direct ubunto ppa/repo for Ubuntu 16.04 - keeps wanting to drag it to 0.28 (even with forcing the version).

- is the proposed mode (for bad upnp/dlna players) tabled for 0.28 or 0.29? Just want to know which stream to monitor.

Thanks
raymond

[paulh]

The problem we have at the moment is lack of interested developers. Those that are interested don't have the time to work on it.

There's always the third option. Work out what the problem is and provide a patch that fixes it

[ris2t]

Thanks - knowing the state of play is appreciated.

Got the impression from the 0.28 rewrite that more than patching might be involved. Will relook at the upnp traffic to see atleast where the Samsung TV is going wrong and how far off its from the desire. It discovers just doesn't list content.

VLC player, yikes that traffic seemed messy so I understand the previous comments about its implementation.

Any reference UPNP document links/recommendations would be appreciated. Googling brought me up short on anything basic/clear.

[paulh]

You've got an advantage over most of us in that you have the hardware to test things on.

Stuart Morgan is the man to ask for help if you can get his attention. I guess it was him who made the changes that fixed it to not work in 0.28 Might have better luck on IRC #mythtv (harder to ignore you on there ).

If it was working in 0.27 and isn't in 0.28 then you might be able to figure out what change broke things by looking at the commit log. If you have a git checkout then you can search the log by doing something like

Code: Select all

git log -i --grep="upnp"

As for docs I can't help you there, Stuart would know if they are available. Not sure how much they would help since it sounds like UPnP is one of those areas where everyone interprets the specs in different ways and implements the bits they want and ignoring the bits they don't need leading to the fun and games you are having.

See also #12767 and #12284

[jimcor101]

I too am having severe problems with Upnp in .28

My Samsung TV's as well as numerous uPnP clients on the Apple TV (including VLC) have stopped working in one fashion or another.

This was a major component of my MythTV setup for *years*, I truly hope we can get interest going to get these issues resolved. I can certainly understand the desire to make it comply with standards, but I am really shocked that it has broken a large component of clients.

Thanks,
Jim Cornacchia

[pvr4me]

I too am having severe problems with Upnp in .28

My Samsung TV's as well as numerous uPnP clients on the Apple TV (including VLC) have stopped working in one fashion or another.

This was a major component of my MythTV setup for *years*, I truly hope we can get interest going to get these issues resolved. I can certainly understand the desire to make it comply with standards, but I am really shocked that it has broken a large component of clients.

Re VLC and UPNP:

https://code.mythtv.org/trac/ticket/12767

Craig