airupnp issue with two renderers

[6b6561]

I just found your project and aircast works just great with my Chromecasts, but airupnp is giving me gray hairs.

I'm trying to use airupnp v0.2.30.0 on "4.9.0-12-amd64 #1 SMP Debian 4.9.210-1+deb9u1 (2020-06-07) x86_64 GNU/Linux" and aircasting from an ios 14.2 device.

Renderers:

• Philips AW3000 Streamium Speaker
• Samsung D5700 TV

Launching upnp properly detects my two DLNA renderes, a Philips speaker and a Samsung TV.

<device>
<udn>uuid:3209df11-f41c-0446-5628-adc1af7ddfa5</udn>
<name>[TV]UE40D5700+</name>
<mac>bb:bb:7b:d1:55:fb</mac>
<enabled>1</enabled>
</device>
<device>
<udn>uuid:F00DBABE-AA5E-BABA-DADA-188ED5720302</udn>
<name>Kitchen+</name>
<mac>bb:bb:d5:72:03:02</mac>
<enabled>1</enabled>
</device>

But for some reason I'm not getting any audio output.

The following is debug output from attempt to stream to the TV. Log for speaker starts at 14:58.

[14:55:32.763232] rtsp_thread:357 got RTSP connection 14
[14:55:43.572121] handle_rtsp:405 [0x7f88ac000990]: challenge u3Gh23roNAOgZZMICKVDow==
[14:55:43.594449] handle_rtsp:398 [0x7f88ac000990]: received ANNOUNCE
<SNIP>

While streaming to the Philips speaker look's like it's starting to stream, but no output from the speaker.

[14:58:38.212703] rtsp_thread:357 got RTSP connection 13
[14:58:46.137735] handle_rtsp:405 [0x7f88ac00a0d0]: challenge Z9/kf/cirRYbCgWidTp8AQ==
[14:58:46.154588] handle_rtsp:398 [0x7f88ac00a0d0]: received ANNOUNCE
[14:58:46.164024] handle_rtsp:604 [0x7f88ac00a0d0]: responding:
RTSP/1.0 200 OK
Audio-Jack-Status: connected; type=analog
CSeq: 4
<SNIP>

[6b6561]

Another interesting thing is that if I try to launch it with an unmodified stored config file then it will crash on me.

root@linchpin:/home/kea/gits/AirConnect/bin# ./airupnp-x86-64 -i config.xml all=debug
[15:06:51.518679] main:1398 Starting airupnp version: v0.2.30.0 (Nov 26 2020 @ 17:04:27)
[15:06:51.571215] Start:1111 Binding to 192.168.0.99:49152
[15:06:56.955747] AddMRDevice:995 [0x7f22a9140010]: adding renderer (Kitchen)
[15:06:56.971546] MasterHandler:660 [0x7f22a9140010]: subscribe success
[15:06:57.032279] AddMRDevice:995 [0x7f22a91424c0]: adding renderer ([TV]UE40D5700)
[15:06:57.034943] MasterHandler:660 [0x7f22a91424c0]: subscribe success
[15:07:12.778529] Stop:1174 terminate update thread ...
[15:07:12.778749] Stop:1179 flush renderers ...
[15:07:12.779317] Stop:1182 terminate libupnp
[15:07:13.300891] Stop:1201 terminate main thread ...
root@linchpin:/home/kea/gits/AirConnect/bin#

[philippe44]

It does not crash, but you have asked to create a config file (-i) and exit. It does what you wanted :-)

Regarding the previous log, unfortunately UPnP is a difficult system due to the lack of proper compliance test, so you have a lot of non-compliant devices floating around and people think they are doing the right thing by coping with them still, and unfortunately that's creating even more problem by reinforcing bad behavior. You end up with spaghetti code

It's a bit the same for HTTP stacks. I'm not saying that my implementation is clean, because it is not, but I'm trying to stick to the standard and not do too many ad-hoc/assumptions. The TV is doing 2 HEAD requests but does not seem to follow with a GET and the Streamium does a GET but does not seem to accept data. Instead, it signals being in "STOPPED" stated despite having received a request to play.

What I have seen a lot on HTTP stacks is many (many) crappy ones that do not respect HTTP at all and assume that they have a content-length, because it's a file being played. Of course, when you use a normal UPnP controller to send a file, it knows the size of that file and can send it in the HTTP response, but by definition AirUPnP does not know, so I can't mention content-length. And standard is pretty clear with that, content-length is optional but unfortunately many stacks either grabbed from a random site or outsourced cheap don't care... well, you get what you paid for

[philippe44]

One thing you could try for the Streamium is to use mp3 instead of flac. I vaguely remember some issues with flac & header management on streamium. And I'm not sure but it seems you've set HTTP latency to zero, I don't recommend doing that.

[philippe44]

I've improved some of my UPnP handling in 0.2.40.0 that I probably should have done before :-). It might satisfy your TV. Could you take a log and post it (creating a zip file would be better)

[6b6561]

Oops, didn't read properly and just assumed -i = USE config.xml and -I CREATE... sorry for this.

I changed the codec to mp3 and added -l 1000:2000 still the same results. You remember correctly that there where an older Streamium issue reported but the reporting user didn't bother to follow up on the case and it ended in your suggestion to set the codec to mp3.

Do you want a debug log or a sdebug log?

[philippe44]

let's go with -d all=sdebug. Will be messy but I won't have to ask you multiple logs

[6b6561]

I did run debug but with 2.30, I will redo it later with the 2.40.

[6b6561]

Here are the two log files. airupnp where launched as:

./airupnp-x86-64 -x config-upnp.xml -l 1000:2000 -d all=sdebug 2>&1

config-upnp.zip streamium.zip TV.zip

[philippe44]

Right - I've made a big update to AirUPnP that I was not keen on doing, but it should not have side-effect. You can have a look at the updated README but basically that allows you to use "chunked-encoding" for your player as well as, in last resort, to define a "fake" content-length which might work in your case. I really did not want to open this Pandora box before but it seems unavoidable in your case and I hope it will solve your issue. Please look at the "-g" option on command line or at \<http_length> entry in config file.

[6b6561]

A big thank you! I where about to suggest the approach of faked content length yesterday, but I didn't do it as I didn't know how much work it would be for you to implement it, either it was easy or you are a quick coder! Great work!

Chunked didn't work with the TV but fake length and mp3 did the trick. The TV figured that it had 37h of content coming, but I guess it might be that it tries to calculate the duration from the first frames, I know from past that the TV has always had it's own view on content length.

Following worked for both the TV and the speaker: ./airupnp-x86-64 -c mp3 -g 0 -l 1000:2000

You could tweak the "(see below)" of the README.md to "(see "HTTP content-length" below)", I had a hard time to find it in the document as I where looking just under the config file parameter section.

A minor thing in README.md is under Pioneer/Phorus/Play-Fi section, where instruction says change flac to mp3, should be just flc.

[philippe44]

Well, it was fast but not because I'm fast, instead I had already spent a lot of time on such issues on my other projects for Logitech Media Server and everything was "almost there". I did not include it at the beginning in AirUPnP because I always try to limit number of options & choices (I think it just brings confusion) and also I had an issue with chunked mode combined with icy-metadata (mp3) that was not solved when I initially released AirUPnP and I then left thing commented out.

It's too bad that chunked does not work for you because it's really the most appropriate option and the "fixed length" is a dirty hack. But that's less an issue in AirUPnP than in my other applications where I close the connection (to move to next track) before the "fake length" has been sent, obviously, and some players really don't like that. In AirUPnP, the track has no real end so it does not matter to cheat about length.

[6b6561]

It looks like it's working based on some quick tests, case closed as resolved.