Opened 5 years ago

Last modified 5 years ago

#12284 new Bug Report - General

Latest Trunk DLNA service not working anymore with Samsung TV's

Reported by: tomi.orava@… Owned by: dblain
Priority: minor Milestone: unknown
Component: MythTV - UPnP Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

The DLNA support has been working fine with two different Samsung TV's and Skifta Android application until the commit:

commit ef72dc4aeef10ae0c9f2c3ecc16074d8fef5b4de Author: Stuart Morgan <smorgan@…> Date: Fri Aug 1 23:20:08 2014 +0100

Remove definition of m_pHttpServer from MediaRenderer? and use the one in the base class, UPnP

After the above commit, the older 2011 model Samsung doesn't even list the mythbackend as a DLNA server anymore.

The commit below was the one that caused also the newer 2013 model Samsung TV to start malfunctioning. After the below commit, the newer Samsung lists the mythtv backend as a DLNA server, but the TV fails to see any files.

commit a44606fc2cb907e9ee347ee5100e3f11f27c2690 Author: Stuart Morgan <smorgan@…> Date: Sun Aug 10 15:12:43 2014 +0100

UPnP: Refactor various parts of the code

The way we build the object tree has changed allowing for a tree depth greater than one. e.g. Genre > Artist > Album > Tracks.

The number of queries required to build results has been significantly reduced which should improve response times.

XBox and WMP 11 specific hacks have been disabled. In part to allow users of these systems to test new UPnP behaviour, but also because these non-upnp compliant bits need better segregation from the core code.

Searching and sorting has been disabled because the existing implementation was incomplete and broken. This will be finished and re-enabled soon.

There will be bugs, if you absolutely depend upon UPnP then please hold off updating for a little so I can fix issues found by wider testing. Of course if nobody tests UPnP then issues won't get found ...

Although the Android app BubbleUPnP works even with the latest Trunk versions a good test app has been now discontinued Skifta android app, which seems to work & fail quite the same way as the Samsung TV's in this household.

A quick search found the following links for the skifta app, although it has been deprecated from play.google.com during this summer.

http://androidsite.in/software/view/10839713 http://www.eagleget.com/apps/apk-file/4040/

Skifta is unable to see the current trunk master version of the mythbackend DLNA server at all, exactly like the older Samsung TV.

Attachments (6)

minidlna.log.gz (4.7 KB) - added by tomi.orava@… 5 years ago.
minidlna.log with debug enabled (old Samsung TV as a client)
minidlna.2.log.gz (8.0 KB) - added by tomi.orava@… 5 years ago.
Debug.log showing old MythTV recording served by minidlna to old Samsung TV.
skifta.log.gz (5.5 KB) - added by tomi.orava@… 5 years ago.
Skifta <-> minidlna accessing DVB-T recording
samsung_old.log.gz (3.4 KB) - added by tomi.orava@… 5 years ago.
Old Samsung TV accessing DVB-T recording served by minidlna
mythtv.log.gz (3.6 KB) - added by tomi.orava@… 5 years ago.
Old Samsung TV accessing DVB-T recording served by mythbackend
samsung_new.log.gz (8.3 KB) - added by tomi.orava@… 5 years ago.
New Samsung TV accessing all 4 files using minidlna

Download all attachments as: .zip

Change History (19)

comment:1 Changed 5 years ago by Stuart Morgan <smorgan@…>

In 72db26812ff2613e4eccbee0f4a2cca365314d05/mythtv:

UPnP: Add MPEG_PS_PAL and MPEG_PS_NTSC to the list of supported DLNA protocols. Refs #12284

comment:2 Changed 5 years ago by tomi.orava@…

Thanks for your fast response. I tested with your latest commit and suddenly the older Samsung was again showing the mythbackend server with all the contents. However, trying to playback an avi content which has been working in the past, failed with Samsung disconnecting from the mythbackend & removing the server from the list:

2014-09-28 16:51:35.268389 I HTTPRequest::SendResponse?( File ) :200 OK -> 192.168.9.142: 2014-09-28 16:51:35.268403 I SendResponseFile? ( /net/nas/movies/kids/movie.avi ) 2014-09-28 16:51:35.268657 I HTTPRequest::TestMimeType?(/net/nas/movies/kids/movie.avi) - type is video/avi 2014-09-28 16:51:35.289200 I SendResponseFile?( /net/nas/movies/kids/movie.avi ) Error: 104 [Connection reset by peer] 2014-09-28 16:51:35.289267 E socket(-1) - Error returned from SendResponse?... Closing connection QAbstractSocket::waitForBytesWritten() is not allowed in UnconnectedState? 2014-09-28 16:51:35.297778 I ExtractMethodFromURL(end) : GetVideo? : /Content 2014-09-28 16:51:35.297817 I ServiceHost::ProcessRequest?: GetVideo? : GET /Content/GetVideo??Id=222 HTTP/1.0

The newer Samsung still doesn't see any content files and Skifta doesn't see the whole mythbackend server.

comment:3 Changed 5 years ago by stuartm

I'm uncertain how to fix the 'avi' problem. It appears to be a Samsung bug rather than something we're doing wrong.

I'm wary of installing Skifta, an app that was removed from the Play Store, has no official website and only remains available through dodgy third party sources. However I did install it, and I'm none the wiser, since I can't view it's source code and/or I can't speak to it's devs. I can't say why it's ignoring the server, other than to guess that it's not DLNA/UPnP compliant, surprisingly many clients/servers which claim support, are not compliant (XBMC for example).

I'm going to look at adding a setting to disable DLNA compliance as it should help with some non-compliant devices. However if they aren't UPnP compliant, then ultimately we may have to give in and go back to providing optional device specific hacks.

comment:4 Changed 5 years ago by stuartm

For what it's worth, the reason your Samsung is likely unable to see any files is because it doesn't support any of them! If those same files work with a different upnp server, then we'll need some information on how they are being described by that server (mime types, DLNA profiles etc).

comment:5 Changed 5 years ago by tomi.orava@…

Ok, I understand. Both of the TV's do work fine with the minidlna 1.1.4, although I don't know how compliant minidlna is.

I can of course provide some wireshark traces from the minidlna and/or old/new mythtv connections if you like.

The skifta was provided by qualcomm and it did have the web site until june/july this summer. Unfortunately the bubbleupnp works somewhat differently compared to Samsung TV's ... I just wish these big companies would bother to follow standards. Installing some NUC or similar box next to the TV doesn't sound that interesting either.

comment:6 Changed 5 years ago by stuartm

It would be helpful to know what minidlna is reporting for both supported protocols, and what protocols it lists for recordings, avi etc.

Changed 5 years ago by tomi.orava@…

Attachment: minidlna.log.gz added

minidlna.log with debug enabled (old Samsung TV as a client)

comment:7 Changed 5 years ago by tomi.orava@…

Ok, I've got the minidlna 1.1.2 debug log from a test box. Just tell me if it helps enough, or if you need tcp/udp dumps.

comment:8 Changed 5 years ago by stuartm

I've played with minidlna. The only meaningful differences I can find are that it's unable recognize broadcast AVC and it describes AVI with the alternate video/x-msvideo. It describes SD digital recordings exactly the same as we do.

It otherwise advertises every single DLNA protocol, even those it doesn't provide (breaks the DLNA spec, but then we also do this to a lesser extent).

It's worth a try using the other avi mimetype, the IANA don't have an official value and Microsoft themselves can't seem to agree on a single standard (some of their documentation uses video/avi, some uses video/x-msvideo).

Changed 5 years ago by tomi.orava@…

Attachment: minidlna.2.log.gz added

Debug.log showing old MythTV recording served by minidlna to old Samsung TV.

comment:9 Changed 5 years ago by tomi.orava@…

I tried to serve an old MythTV recording (of type MPEG transport stream data according to file command) and of course the Samsung disconnected again.

The same file was served via minidlna and I've attached the log as minidlna.2.log.gz in case you can see something usefull from it.

The MythTV test box doesn't have any video grabber card, so the only thing I can do is to serve invidual video files as a test case.

comment:10 Changed 5 years ago by stuartm

How was this recording created? Has it been transcoded?

It's being listed by MiniDLNA as using a PS container. This would only be the case for some framegrabbers, or if the recording had been transcoded. If it was transcoded, was it transcoded by MythTV?

comment:11 Changed 5 years ago by tomi.orava@…

It's just an old DVB-T recording (mpeg2) recorded using MythTV 0.25 (most likely) a few years ago. No additional processing has been done to my knowledge.

I've created three more logs, which are al showing the access to the recording2.mpg using Samsung TV <-> minidlna, Skifta <-> minidlna and Samsung <-> mythbackend.

The file "recording2.mpg" is recorded today using DVB-T Nanostick T2 E290.

Changed 5 years ago by tomi.orava@…

Attachment: skifta.log.gz added

Skifta <-> minidlna accessing DVB-T recording

Changed 5 years ago by tomi.orava@…

Attachment: samsung_old.log.gz added

Old Samsung TV accessing DVB-T recording served by minidlna

Changed 5 years ago by tomi.orava@…

Attachment: mythtv.log.gz added

Old Samsung TV accessing DVB-T recording served by mythbackend

comment:12 Changed 5 years ago by tomi.orava@…

Ok, it seems that I missed the yesterdays commit:

commit f593666afbc073581f69af11a3ea826d2556b478 Author: Stuart Morgan <smorgan@…> Date: Sun Sep 28 16:43:36 2014 +0100

UPnP: Try a different mimetype for AVI in the hope that it stops Samsung TVs crashing

Anyway, after I updated to the latest current commit (MPEG transport stream data", I no longer get disconnects with the old Samsung when trying to play a file (avi,mkv or mpeg2) ---> Now I just get "not a supported format".

This is certainly an improvement already!

The newer samsung still doesn't see any files, so I quess I could attach a minidlna.log that might show what it is looking for when accessing the same files as yesterday with the older TV.

Changed 5 years ago by tomi.orava@…

Attachment: samsung_new.log.gz added

New Samsung TV accessing all 4 files using minidlna

comment:13 Changed 5 years ago by stuartm

I've been doing some searching and it appears to be a well known problem with Samsung TVs that they won't play AVI and MKV over UPnP unless you tell them the file is actually MPEG*. In other words we can't make these files playable without device specific hacks, which I had hoped to avoid (we should be so lucky).

They also seem to require a contentFeatures header despite the DLNA spec stating:

7.4.1.3.11.4.3
 Tolerance to unavailable contentFeatures.dlna.org header
[GUIDELINE] If a Rendering Endpoint sends an HTTP HEAD or GET request using generic HTTP
URLs including a valid getContentFeatures.dlna.org HTTP header, and if the response omits the
contentFeatures.dlna.org HTTP header, then the Rendering Endpoint shall accept the response as
if it included the header.

[COMMENT]
a) Some legacy devices have been designed to retrieve res@protocolInfo information using the
contentFeatures.dlna.org header instead of using the available resource metadata. Generic
HTTP URLs could point to servers located in the Internet, which are not capable of including
this header in a response message.
b) The contentFeatures.dlna.org HTTP header carries the same information as the
res@protocolInfo property, which is always available for a Rendering Endpoint.

So only 'legacy' devices should expect to use the header and servers may be unable to provide it. That's the case currently for MythTV, our web server is decoupled from the upnp, requiring a hack to insert dynamic upnp headers into responses. I'm working on just such a hack.

What stands out in the minidlna log is that it 'supports' a Samsung proprietary feature which appears equivalent to, but different in format, to the standard UPnP Shortcut feature (which we offer). I can try adding this custom Samsung feature and see if that makes a difference.

Note: See TracTickets for help on using tickets.