Samsung TV: Video found but cannot be played (works on minidnla, trace attached)

[probonopd]

Thanks for this useful piece of software.

UE46F... Series 6 Samsung TV shows icons for the videos served by dms in the DNLA browser, but trying to play the videos results in a black screen followed by an error message that the format is not supported "at this time". (So I think that this is different from #56 where not even the icons can be seen.)

However, minidnla can serve the exact same video files to the same Samsung TV just fine.

Attached are pcap traces of good (minidnla) and bad (dms) attempts to play the video on the Samsung TV.

pcap.zip

I noticed that minidnla sends quite some more DNLA-related HTTP headers than dms when serving the video, but there are other differences as well.

Please let me know how I can help further to test/debug this.

[anacrolix]

@probonopd thanks for the pcap! It looks like dms returns HTTP 500 errors for the SOAPACTION "urn:schemas-upnp-org:service:ContentDirectory:1#X_GetFeatureList". I expect there could be a more appropriate error to return for this unsupported request, that may have the Samsung handle the results better. It may be aborting whatever it was attempting, rather than trying to proceed with an unsupported action. The other choice would be to implement the action.

I won't look into that just now, I'm not active on this project at the moment.

[probonopd]

Thanks @anacrolix for your analysis. Searching for X_GetFeatureList in Golang code, I found the rclone project which, among many other features, can also serve directories on the local filesystem to DLNA devices. I can confirm that the Samsung TV can play the same video using rclone indeed.

Looking at the rclone code, the solution may be rather easy:

https://github.com/rclone/rclone/blob/66e08e0cc8972000d84a61f262286f5644d9fdee/cmd/serve/dlna/cds.go#L325-L341

Where would this need to be plugged into the dms code?

[anacrolix]

@probonopd Thanks for finding this. I've submitted an issue to rclone, hopefully they are interesting in contributing their improvements on this. As for plugging it in, it would go alongside the code that was copied there in the first place 😆 .

[anacrolix]

@probonopd can you try #86?

[claes]

I have a Samsung UE46D6300 (so similar but not identical), and I can confirm this problem with v.1.6.0

[anacrolix]

I have a Samsung UE46D6300 (so similar but not identical), and I can confirm this problem with v.1.6.0

@claes Did you try #86 ?

[claes]

@anacrolix No, but since it was merged I assumed it was part of 1.6.0, but perhaps it isn't?

[anacrolix]

You are quite right. I'll leave the issue open.

[WithoutPants]

Stash recently had a PR (stashapp/stash#4784) submitted to fix what appears to be a related issue (stashapp/stash#1768).

The change was to add the following headers when streaming a file:

• transferMode.dlna.org set to Streaming
• contentFeatures.dlna.org set to DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000

I can see that the former is already included upstream. Having had a look at

dms/dlna/dlna.go

Line 35 in 6b89c44

func (cf ContentFeatures) String() (ret string) {

it looks like the latter already corresponds to a ContentFeatures instance with SupportTimeSeek = false, SupportRange = true, and Transcoded = false. The only other difference is that the DLNA.ORG_FLAGS value starts with 015 instead of 017.

I don't have a Samsung TV to test with, nor do I know the DLNA protocol well enough to be confident that this change would be the solution to this original problem. A request was made to contribute the fix upstream, but as far as I can tell there doesn't appear to be anything useful to contribute.

[anacrolix]

@WithoutPants that's really helpful, appreciated.