On Sa, 2013-03-09 at 13:58 +1300, Andrej Falout wrote: > Thanks Jens, > > > Ah, sorry: Can you try to set my-dlnaprofile=MP3 and see if that > helps? > > I forgot that without that there are no flags generated. > > > Unfortunately no difference that I can observe. > > > > Now I see that my Samsung TV has the same issue. Both my TV > and Onkio > > receivers are DLNA certified, so I wonder.... how did they > pass DLNA > > test 7.3.33.4 ? > > > For Samsung: There's a reason their implementation is called > AllShare. > > > Samsung AllShare is an marketing name / family of products, that > includes products such as Allshare Play, Allshare Cast Hub, and > others. Some of them use DLNA, some dont. Primary focus of this > product group / marketing name is transparently sharing media between > devices regardless of location, as described here: > http://www.samsung.com/nz/support/usefulsoftware/ASPS/JSP > > > Samsung DLNA capable devices are all Digital Living Network Alliance > certified, and advertised and marked as such on the device, packaging, > and marketing material: > > www.samsung.com/us/pdf/dlna_guide.pdf
> > > For Onkio: Don't know. > > > As far as I can see, there are only two answers possible: > > > 1) requirement of the functionality exercised in test 7.3.33.4 is > ambiguous, and allow non-specified/undocumented behaviors to satisfy > the test, and/or That requirement is pretty clear: no DLNA.ORG_OP parameter -> no seek headers allowed, not even those requesting the whole file. And endless streams as produced by GstLaunch are not seekable. > 2) the test 7.3.33.4 implemented in Rygel testing suite is not exactly > the same test that was used to obtain certification for Samsung and > Onkyo devices, for whatever reason that may be. I can assure you it's the same testing suite. > I would expect the goal of Digital Living Network Alliance to be > interoperability between devices. Passing or failing a test has very > little value for the end user trying to use two devices together. > Having them work together, has a value. Yeah. In theory. > As any human endeavor, specific implementations of any stated goal > will have flaws, even if the goal is achieved. As an example, > Microsoft Media Player has no problem achieving this functionality > (Streaming) with both devices, as much as this observation makes me > wonder about the methods they used to achieve it.As a developer, I > question them, and where I can, try to avoid them. As a user, I have > little choice but to applaud them. > As an comparison, I wonder how many computers on this planet would > actually work, if they refused to boot on any computer with > non-compliant ACPI implementation... It would be a better place since it would force people to fix their shit. Working around things never helps. Shit needs to be fixed. > I also note that devices known for exhibiting this behavior (Samsung, > Onkyo and Sharp - that I personally know about) represent more then > 50% of the DLNA devices on the planet, and therefore more then 50% of > the potential user base of Rygel will be affected by this issue. No. It's perfectly fine for 98% of end-user use-case: Serving files. > The thing is this is mostly with GstLaunch which is a > debugging/"rapid > stream prototyping" tool. > > > So is there another way to achieve this in non-debugging / non-rapid > stream prototyping way? I so far failed to find user-level alternative > to Rygel for creating a UPnP audio stream...? What is the final thing you want to achive? > Please forgive my ignorance, is "user-agent" some king of software I > can add or configure? If it refers to the software component in User-Agent: A string devices SHOULD use to identify themselves. Samsung sucks at that hard times up until until the 2011 models. See http://en.wikipedia.org/wiki/User_agent Although I just realised with commit https://git.gnome.org/browse/rygel/commit/?id=32311fd80d1101c91b7796c2ea0920999c4bb142 that should be at least solved for the recent models. Trying to make a patch. > Samsung/Onkyo firmware, then this is never going to happen, because > as far as this companies are concerned, they are fully DLNA compliant, > and have certification to prove it.... So does Rygel, kind-of: http://certification.dlna.org/certs/REG56214158.pdf which is using Rygel at this commit: https://meego.gitorious.org/maemo-multimedia/rygel/commit/a27f7f81ea4fcd2df1f8bb86f9175d6ae8575b9f > This patch is still marked as Committed - did it not fix the issue or > was it not really committed because of your comment about breaking the > test? > https://bugzilla.gnome.org/attachment.cgi?id=201807&action=diff It was reverted since it broke DLNA conformity tests for the N9. _______________________________________________ rygel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/rygel-list
