Re: Rygel created UPnP stream help please

[Andrej Falout <andrej falout org>]

Hi again Jens, and thank you very much for trying to help!

Please find my responses below;

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.

It is then even more necessary to note how pointless it is to blindly obey such specification, when it is possible that at least three major manufacturers obtained certification based on it, while there devices are not implementing it.

 

> 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.

(Opensource) shit that is used by a lot of people, which implies that it works at least to a degree, gets fixed. (Opensource) shit that does not provide useful function to people, in the way they need to use it, does not get fixed, it gets replaced. (Non-Opensource) shit, however, gets fixed if fixing it will make tons of money more then otherwise.

 

> 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.

There are many fine working solutions for serving files over UPnP. I am yet to find another one that will create UPnP stream. I would think that it is at least a lost opportunity to ignore this functionality. I got here based on searching for this functionality, and the only reason I did, was the number of discussions, blogs, howto's, etc, all talking about "how to stream to DLNA devices using Rygel" Try googling for "rygel stream" and be amazed... ;-)

 

> 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?

Create an audio stream that can play on DLNA devices, namely Samsung and Onkyo. And therefore be able to treat DLNA device just the same as Apple Airport Express, Logitech Squeezebox, Sonos or an BlueTooth A2DL device can be treated - as a destination that plays sound, instead of having to depend on control point, built-in or (worse) otherwise. This would solve the problem of renderer needing a CP to skip to next track, problem of gapless playback, as well as for me even larger problem of integration UPnP devices with all other audio network devices I have in one interface... including synchronization, playlist transfer, etc etc...

Anything that can take an audio stream in some (losless or uncompressed) format, and can make this into UPnP compliant stream that UPnP devices can play, would make me very happy :-)

 

> 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

Ah - HTTP 1.1 "user-agent" field.... how about using UPnP "manufacturer" ID instead?

 

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.

That is good to know - does it apply to audio seek issue?

 

>  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

Another proof that not fixing things for the sake of complying with a specification that approved both of this implementation is not helpful.

 

> 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="">

It was reverted since it broke DLNA conformity tests for the N9.

So now we have two certified devices that cant be used together...

 

Thank you for your help,

Andrej Falout