GNOME Bugzilla – Bug 653894
Seeking does not work with Samsung TV
Last modified: 2019-02-22 05:57:35 UTC
Trying to seek in media does not work with Samsung TV and Rygel. It does work with Samsung TV and MiniDLNA. I tracked the problem down to a difference in the HTTP response headers. Rygel sends: contentFeatures.dlna.org : * MiniDLNA sends: contentFeatures.dlna.org: DLNA.ORG_OP=01;DLNA.ORG_CI=0 If I change Rygel to send the same header as MiniDLNA seeking works. i.e. diff --git a/src/rygel/rygel-http-get-handler.vala b/src/rygel/rygel-http-get-handler.vala index 243fa7c..60a98b1 100644 --- a/src/rygel/rygel-http-get-handler.vala +++ b/src/rygel/rygel-http-get-handler.vala @@ -55,7 +55,7 @@ internal abstract class Rygel.HTTPGetHandler: GLib.Object { assert (tokens.length == 4); request.msg.response_headers.append ("contentFeatures.dlna.org", - tokens[3]); + "DLNA.ORG_OP=01;DLNA.ORG_CI=0"); } } catch (Error err) { warning ("Received request for 'contentFeatures.dlna.org' but " +
There is a slight problem; this would violate DLNA requirement 7.3.30.x You can only add DLNA.ORG_OP and DLNA.ORG_CI if you have a DLNA.ORG_PN parameter. And for profile-less files you mustn't have one, hence you can't append those. You can work around the issue by installing a custom DLNA profile, see https://live.gnome.org/Rygel/IOP, section "Samsung UE46B7070".
(In reply to comment #1) > There is a slight problem; this would violate DLNA requirement 7.3.30.x > > You can only add DLNA.ORG_OP and DLNA.ORG_CI if you have a DLNA.ORG_PN > parameter. Isn't that for DIDL-Lite only? This is headers in HTTP response we are talking about.
Sorry, forgot to mention what 7.4.26.6 says: "The value of the contentFeatures.dlna.org HTTP header must be the same value as the fourth field of the content's res@protocolInfo value"
(In reply to comment #3) > Sorry, forgot to mention what 7.4.26.6 says: > > "The value of the contentFeatures.dlna.org HTTP header must be > the same value as the fourth field of the content's res@protocolInfo value" Ah it that case, we'll need to know if the TV accepts the headers with DLNA.ORG_PN specified in this header as well. However it will still not work for media that we do not have PN detection for but then again thats another issue and we must not work around that.
It should, since that's what adding a custom profile does and Andreas(fatal) says it works for him on the IOP page. Also there's just no solution but a custom profile for files where there simply is no PN like Theora, MKV, WebM etc.
(In reply to comment #1) > There is a slight problem; this would violate DLNA requirement 7.3.30.x > > You can only add DLNA.ORG_OP and DLNA.ORG_CI if you have a DLNA.ORG_PN > parameter. And for profile-less files you mustn't have one, hence you can't > append those. You can work around the issue by installing a custom DLNA > profile, see https://live.gnome.org/Rygel/IOP, section "Samsung UE46B7070". Ah, okay I missed that page. With that custom profile seeking does indeed work, and the TV can now also play some MKVs served by Rygel. But some MKVs still do not play, they play fine when using MiniDLNA though. I guess that's because that profile restricts it to only H264+AC3, and I have also MKVs with H264+DTS and H264+AAC. So I have 2 questions: - How do I change the custom profile so that it applies to all MKVs, regardless of codecs used? - Is it possible that Rygel can be changed to serve the custom profile by default, perhaps by adding some quirks for Samsung TVs? So that we can have Rygel just work out of the box with Samsung TVs and people don't have to hunt down a custom profile from a wiki.
It looks like there are (going to be) official profiles for H264+AC3 in MKV - Trying to figure out how official they are.
Looks pretty official.
And I commented on the wrong bug, sorry ;)
(In reply to comment #6) > - Is it possible that Rygel can be changed to serve the custom profile by > default, perhaps by adding some quirks for Samsung TVs? So that we can have > Rygel just work out of the box with Samsung TVs and people don't have to hunt > down a custom profile from a wiki. I think we can fix that more easy now we that split up the device hacks stuff
Created attachment 204148 [details] [review] core: Add Samsung hacks Samsung TVs need a minimum protocol info to be able to seek. Helps of course only those devices that have a User-Agent set.
Created attachment 204151 [details] [review] Update, only set ByteSeek flag if the resource is really byte-seekable.
Created attachment 204153 [details] [review] Add missing file from previous patches.
Created attachment 204154 [details] [review] Forgot to actually add changes
Unfortunately the patch doesn't help with this issue, because Samsung doesn't set the User-agent header when retrieving the actual media. It does set the header for all the soap related requests though. According to the source code of minidlna this is a common problem with clients, mindlna solves this by using a client cache. Comments from minidlna upnphttp.c: /* If the client type wasn't found, search the cache. * This is done because a lot of clients like to send a * different User-Agent with different types of requests. */
(In reply to comment #15) > Unfortunately the patch doesn't help with this issue, because Samsung doesn't > set the User-agent header when retrieving the actual media. It does set the > header for all the soap related requests though. > > According to the source code of minidlna this is a common problem with clients, > mindlna solves this by using a client cache. > > Comments from minidlna upnphttp.c: > > /* If the client type wasn't found, search the cache. > * This is done because a lot of clients like to send a > * different User-Agent with different types of requests. */ Hmm.. an interesting idea indeed. Never thought of that.
Created attachment 204287 [details] [review] Add a user-agent cache to GUPnPContext
Created attachment 204355 [details] [review] Add user-agent cache to GSSDP client
Created attachment 204356 [details] [review] Add skeleton ARP lookup function
Created attachment 204357 [details] [review] Fill user-agent cache from SSDP packets
Created attachment 204358 [details] [review] Cache user agents per IP
Review of attachment 204358 [details] [review]: ::: libgupnp/gupnp-context.c @@ +56,3 @@ #include "http-headers.h" +extern char *gssdp_arp_lookup (const char *); If anyone comes up with a better idea than this - please speak up...
(In reply to comment #22) > Review of attachment 204358 [details] [review]: > > ::: libgupnp/gupnp-context.c > @@ +56,3 @@ > #include "http-headers.h" > > +extern char *gssdp_arp_lookup (const char *); > > If anyone comes up with a better idea than this - please speak up... I need to think about it but your implementation is not doing any ARP or lookup so why have this function if its just duplicating string? It will just give wrong impression to people.
I'm still looking into alternatives on how to do that portable and by not parsing "/proc/net/arp", but I already wanted to share the basic infrastructure without that implementation detail. I thought about it and I think we can just add a pointer to the gupnp context in the hostpath data, it shouldn't live longer than the context anyway and then have a add_cache_entry or sth. in GSSDPClient
Created attachment 204372 [details] [review] Add skeleton ARP lookup function
Created attachment 204373 [details] [review] Add user-agent cache to GSSDP client
Created attachment 204374 [details] [review] Fill user-agent cache from SSDP packets
Created attachment 204375 [details] [review] Cache user agents per IP
Created attachment 204413 [details] [review] Add skeleton ARP lookup function
Created attachment 204414 [details] [review] Add user-agent cache to GSSDP client
Created attachment 204415 [details] [review] Fill user-agent cache from SSDP packets
Created attachment 204416 [details] [review] Add ARP lookup for Linux
Hi, I see that you use both User-Agent and Server headers to fill the cache. I probably should point out that Samsung TVs periodically sends out SSDP NOTIFY messages advertising a MediaRenderer and RemoteControlReceiver device with a Server header that's different than the User-Agent header used by the client. Client: POST /Control/MediaExport/RygelContentDirectory HTTP/1.0 HOST: 192.168.1.10:47621 CONTENT-LENGTH: 415 CONTENT-TYPE: text/xml;charset="utf-8" USER-AGENT: DLNADOC/1.50 SEC_HHP_TV in bed room/1.0 SOAPACTION: "urn:schemas-upnp-org:service:ContentDirectory:1#Browse" Server: NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=1800 LOCATION: http://192.168.1.11:52235/dmr/SamsungMRDesc.xml NT: urn:schemas-upnp-org:device:MediaRenderer:1 NTS: ssdp:alive USN: uuid:945c22c4-7312-1e8a-edb3-8a8fc0d28e0c::urn:schemas-upnp-org:device:MediaRenderer:1 SERVER: Linux/9.0 UPnP/1.0 PROTOTYPE/1.0 CONTENT-LENGTH: 0
Okay, technically the renderer will be the device that finally does the request but probably I should remove the SERVER line.
hm, just reading in the guidelines (7.3.32.3) that you can use DLNA.ORG_OP on non-DLNA content.
Created attachment 207782 [details] [review] Allow OP, CI and PS params without DLNA profile This is allowed according to the guidelines 7.3.32.3, 7.3.36.2 and 7.3.35.3.
Can you check if this patch against gupnp-av helps you? Please make sure that you undid every other change and custom profiles you're using. I need to know if we can omit DLNA.ORG_CI as stated by DLNA or if Samsungs need it.
All my samsung tv needs is the ORG_OP part to allow seeking, not a profile name.... (I initially did the same hack as described in the original post of this bug report to make sure ORG_OP was included, until I was told how to work around it by creating custom profiles.)
*** Bug 674280 has been marked as a duplicate of this bug. ***
Attachment 207782 [details] pushed as a5071dc - Allow OP, CI and PS params without DLNA profile