weixin_39937447
weixin_39937447
2020-12-01 23:05

Crash streaming to cast group from live application

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 [11:48:21.239391] handle_http:1139 [0x69608470]: responding: 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/AirConnect

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

7条回答

  • weixin_39955825 weixin_39955825 5月前

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

    点赞 评论 复制链接分享
  • weixin_39937447 weixin_39937447 5月前

    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.

    点赞 评论 复制链接分享
  • weixin_39955825 weixin_39955825 5月前

    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

    点赞 评论 复制链接分享
  • weixin_39955825 weixin_39955825 5月前

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

    点赞 评论 复制链接分享
  • weixin_39937447 weixin_39937447 5月前

    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!

    点赞 评论 复制链接分享
  • weixin_39955825 weixin_39955825 5月前

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

    点赞 评论 复制链接分享
  • weixin_39955825 weixin_39955825 5月前

    Would you mind closing the issue?

    点赞 评论 复制链接分享

相关推荐