search

philippe44 / AirConnect

Use AirPlay to stream to UPnP/Sonos & Chromecast devices
Other
3.55k stars 218 forks source link

Crash streaming to cast group from live application #132

Closed viboux closed 5 years ago

viboux commented 5 years ago

First of all, thanks for this amazing piece of software. It is absolutely brilliant.

I have some stability issue sometime while switching between Cast device and using groups. Sometimes it fails to start but I can just restart the Airplay streaming.

The worst I got was Airplay streaming to a cast group from a live radio iOS application, I got AirConnect to crash completely on the alac.c file where I got a segmentation fault with an unhandled prediction type. I was unable to reproduce exactly.

Any idea of some latency settings I could try? It is currently set a 0:0 (the default executable with no parameters).

Running on a Raspian OSMC distribution on Raspberry Pi 2 Model B V1.1

/cpuinfo processor : 0 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5

[11:44:51.813552] main:874 Starting aircast version: v0.2.2.4 (Dec 16 2018 @ 16:01:03) [11:44:51.814153] main:882 no config file, using defaults [11:44:51.817285] Start:662 Binding to 192.168.1.xxx [11:44:52.057451] AddCastDevice:593 [0x82278]: adding renderer (Living Room Chromecast) ... [11:48:21.011874] _buffer_get_frame:839 [0x69608470]: drain status [level:147] [W:64614 R:64467] [R:0 S:0] [11:48:21.099874] CastSocketThread:793 [0x82ae0]: Media session id 1 [11:48:21.101402] http_thread_func:938 HTTP close 23 [11:48:21.140661] ProcessQueue:576 [0x82ae0]: Processing PLAY (id:53) [11:48:21.218744] ProcessQueue:569 [0x82ae0]: Processing VOLUME (id:55) [11:48:21.219334] MRThread:267 [0x82ae0]: Cast playing [11:48:21.232028] http_thread_func:919 [0x69608470]: got HTTP connection 23 (silent frames 0) [11:48:21.238717] handle_http:1112 [0x69608470]: received GET

HTTP/1.0 200 OK Server: HairTunes Content-Type: audio/flac Connection: close

FIXME: unhandled predicition type: 2 FIXME: unhandled predicition type: 10 Segmentation fault

philippe44 commented 5 years ago

Can you elaborate a bit the ‘switching’ use case?

viboux commented 5 years ago

I change from a single chromecast speaker to another or to a group of speakers in iOS 12 without hitting pause in the application.

I have a longer log of aircast before the crash occured if you are interested.

philippe44 commented 5 years ago

I'm not able to reproduce the problem on switching. Re latency, for real CC the default is fine. Some 3rd party devices don't do buffering themselves (see README) in which case I recommend 1000:2000

philippe44 commented 5 years ago

Try 0.2.3.0, I've corrected and issue that could lead to crashing when closing a connection

viboux commented 5 years ago

Thanks for the fix, I have installed it and I am unable to reproduce for now with the same application/scenario which is interesting. I will report if I can get it to crash by reproducing the same scenario.

Looked at the changeset and looks like the CCA is not playing fair with HTTP :)

Merci!

philippe44 commented 5 years ago

Yep, I might be wrong but I opened a case with the CC team a while ago and they admitted (kind of) the problem. I really do think that what they do is not compliant. It’s irritating because I’m of the opinion that one of the duties of large companies is to be super strict with standards or make them evolve, but when they take liberties, it’s really destructive for the whole industry. Anyway ...

philippe44 commented 5 years ago

Would you mind closing the issue?