Crashing with Large Speaker Groups in Express Branch

Question

Crashing with Large Speaker Groups in Express Branch

codahq opened this issue 6 years ago · 9 comments

I have a speaker group with 11 (sometimes 12 and 13) devices in it. Some of the devices are attached to AVRs so they are turned off when the AVR is turned off. At any rate, even if I turn all devices on and let things settle down I still get crashes.

Are these IDs something I shouldn't be sharing? Let me know if I should take this screenshot down, please.

Answer 1 · 2019-03-03T21:16:15.000Z

Ids are fine, they're just local. Will look into it. Looks like the problem is in one of the libraries though. So maybe it won't be possible to fix.

Answer 2 · 2019-03-04T18:53:10.000Z

Have you tried setting autoConnect to false? Either start the api with --autoConnect=false or post {"api":{"autoConnect":false}} to /config.

Answer 3 · 2019-03-05T08:33:44.000Z

--autoConnect=false feels like it helps or maybe even solves the issue. However, two or three concurrent casts (from the other issue I opened) almost always seem to bring it down.

If you can fix the other bug I think it will be easier to tell if that parameter is stabilizing large speaker groups.

Answer 4 · 2019-03-05T15:38:10.000Z

I thought the crash occurred when the large speaker group with its members was discovered and connected?
If that's the case can you confirm autoConnect false fixes it?

Answer 5 · 2019-03-05T16:17:44.000Z

Sorry for the confusion. This was/is not on discovery. Discovery seems to always work regardless of the parameter. It is a crash that happens on a TTS call when a large group is trying to sync I believe.

Answer 6 · 2019-03-06T12:58:23.000Z

Alright, can you verify the following behavior:

start the api, with autoConnect=false
wait for all devices to come up
connect to your group (/device/groupId)
wait for the device to connect
one playMedia request to the group device
crash

Thats how I understand the issue so far.

Answer 7 · 2019-03-06T23:09:12.000Z

Pretty much. Except that I can't reproduce it immediately after startup. Some time has to pass after startup and potentially something else happens with the devices that are attached. This particular group has no speakers that turn on or off but there is potentially a device that loses connection?

What I'm trying to say is I don't have steps to reproduce this. I was hoping that the stack trace might have shown you something obvious and you could make a change based on that. If not, that's okay. I'll try and pin down steps to reproduce reliably.

Even though I can't reproduce it reliable the crash does happen consistently. The express branch (with ST and Hubitat actually using it) almost never stays up longer than a day or two before I find this stack trace and the reason I think it's large groups is because it didn't start crashing until I added virtual devices for my largest two speaker groups and started putting those in automations.

Answer 8 · 2019-03-07T12:59:40.000Z

Alright. Can you maybe try to post the full log output? If you keep the api up with forever, it should keep a log file. Just run forever list and it should shoe you where it keeps it.

Answer 9 · 2019-03-18T05:08:19.000Z

Yeah, next time I start that VM I'll try to get you better logs. I rolled back to an earlier snapshot but I'll get the broken one going again sometime for us.