I am using the Eric Sauvageau’s asuswrt_merlin sources for the Asus router RT-AC68U, and the latest version of minidlna1.1.2 coming from Asus’ firmware 374_5047 breaks Samsung SmartTV DLNA capabiliies (e.g. Samsung TV UN32F5500 @V1117), i.e. I get the following error message on the TV when trying to browse the videos on the RT-AC68U device: "Request cannot be completed. MEDIA PLAY will be return to the main screen."
A rollback from minidlna1.1.2 to minidlna1.1.1 is working OK.
I already tried before applying your changes for Samsung devices from:
[e3a53f] Justin Maggard 2014-03-11
clients: separate Samsung BDP and TV client types again
Advertising the DCM10 vendor-specific feature to Samsung Series
C and D (at least) players causes them to always browse ContainerID
1, no matter which section is chosen from their GUI.
Treat TVs and BDPs as separate client types with unique features.
[ce1673] Justin Maggard 2014-03-07
samsung: fix root_container setting
Pretend that we don't support SamsungGetFeatureList if we have a
custom root container specified, or else the Samsung client will
jump straight to our normal A/V/P sections.
Unfortunately they did not help, so I ported your latest minidlna version from the git repository f9c37fb205933e2515100b6a71786622f5cc663b @20140428 to Eric Sauvageau’s latest asuswrt-merlin sources and tried it again, but I got again the error on the Samsung TV.
I am attaching the "filtered" logs I created with minidlna 1.1.1 and latest 1.1.2 from git.
If you diff the two files, then you can see that there seem to be differences:
- One is coming from the TV with these additional XML fields: <action><name>RegisterDevice</name><argumentList><argument><name>RegistrationReqMsg</name><direction>in</direction><relatedStateVariable>A_ARG_TYPE_RegistrationReqMsg</relatedStateVariable></argument><argument><name>RegistrationRespMsg</name><direction>out</direction><relatedStateVariable>A_ARG_TYPE_RegistrationRespMsg</relatedStateVariable></argument></argumentList></action> - Later there is an additional "Features" entry in the HTTP communication: </Feature></Features> - And finally coming from the TV, there is the following SOAPACTION one, which now tries to "#Browse" instead of "X_GetFeatureList" as before: SOAPACTION: "urn:schemas-upnp-org:service:ContentDirectory:1#Browse" - The last "#Browse" SOAP action unfortunately gets the following error response: Returning UPnPError 402: Invalid Args . upnphttp.c debug: HTTP RESPONSE: HTTP/1.1 500 Internal Server Error
Could you please take a look at the changed behavior from 1.1.2 which results in an error only on Samsung F series TVs?
You can count on me in case you need any additional debugging or testing.
Thank you very much,
Log in to post a comment.