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 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 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. 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... 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. 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...? > Is there any chance for a workaround/fix, or do I need to look for > another solution? If the device has a proper user-agent, then yes. Samsungs sucked at that > until recently. > Please forgive my ignorance, is "user-agent" some king of software I can add or configure? If it refers to the software component in 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.... I don't mind begging, if that's going to make my Onkyo and Samsung work with Rygel ;-) Any chance for a workaround or any kind? 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 Your work, and your help, are very much appreciated! Thanks, Andrej Falout
_______________________________________________ rygel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/rygel-list
