search

bitfocus / companion-module-figure53-qlab-advance

MIT License
4 stars 8 forks source link

qlabfb without TCP on Windows not firing #143

Closed taylorglad closed 3 weeks ago

taylorglad commented 3 weeks ago

Is this a bug in companion itself or a module?

Is there an existing issue for this?

Describe the bug

We have Companion 3.4.3 installed on a windows machine, and it won't trigger QLab unless TCP is turned on in the Companion connection configuration. We just get the error "Error executing action: Assignment to constant variable."

Steps To Reproduce

No response

Expected Behavior

No response

Environment (please complete the following information)

Additional context

No response

Julusian commented 3 weeks ago

Probably this line at fault https://github.com/bitfocus/companion-module-figure53-qlab-advance/blob/145fca44ac1cac2a933cb78a76349e9089cfb813/qlabfb.js#L376

istnv commented 3 weeks ago

Yeah. That's been in for over a year. I'm surprised anyone still uses UDP mode. I have to rearrange a couple of in-progress feature updates before I can submit a fix. Every time I try stash -> fix -> reapply, things break.

taylorglad commented 3 weeks ago

To the point of us still using UDP mode, for our current case it hasn't been an issue, but a network engineer didn't love the amount of traffic he was seeing while TCP mode was on.

On a separate occasion last year - which I didn't report on at the time and was intending to do more testing to see if this is still the case - I had a QLab show with over 4,000 cues, and was reaching out to QLab support about it being slow and freezing up on a brand new M2 Max. QLab support's conclusion from looking at the logs was that it was being caused by all the TCP traffic from Companion. So I turned off TCP and it was back to normal and didn't take 2 minutes to save! So I'm not sure if that's been fixed since then, but that has made me hesitant to use TCP from Companion with QLab since then.

istnv commented 3 weeks ago

The UDP error will be fixed in an upcoming beta release. There have been some code optimizations recently so try TCP again when you have time. I regularly work with a workspace that has over 11000 cues. That one takes about 3 minutes to load even disconnected. Turning off 'Use tenths' will also reduce network traffic.

MattRogish commented 1 week ago

We're also seeing a lot of problems with TCP mode - basically getting constant qLab disconnects and backed up TCP requests (e.g. we call a cue and nothing happens for a few seconds). This is running on a brand new M4 MacMini (base config), running latest qLab/Companion, and both Companion and qLab are on the same machine, so it isn't a networking issue (and prior to this, didn't see this issue

Switching to Generic OSC "fixed" the issues (e.g. it's not a qLab problem) but we'd like some of the feedbacks qLab-advance provides, so Generic OSC only really allows it to function.

My guess is the pulse timer is too aggressive for certain configurations and could use a longer interval (maybe that's a good config item to expose so we can tweak it?).

istnv commented 1 week ago

Which module version in companion? There is a setting called 'Use tenths' that increases the timing. Try with that off.

MattRogish commented 1 week ago

v3.4.3 of Companion; not sure what the version of the module is (whatever ships with v3.4.3?); "Use tenths" is/was off / was never on (MacOS 15.1 if that matters)

istnv commented 1 week ago

There are some updates in the Beta release that are not yet in stable.

MattRogish commented 1 week ago

Ok should I try with "3.5.0+7577 - 2024-11-20" ?

istnv commented 1 week ago

Save/export your config first. There are some file changes in 3.5.

MattRogish commented 1 week ago

Switching to v.3.5 fixed UDP issue, and I can execute lots of commands!

However, enabling TCP causes the module to get backed up basically immediately. Clicking a few cues and the commands start piling up:

24.11.20 17:13:30 Instance/Wrapper/qLab: Error executing action: Call timed out
24.11.20 17:13:31 Instance/Wrapper/qLab: Error executing action: Call timed out
24.11.20 17:13:34 Instance/Wrapper/qLab: Error executing action: Call timed out
24.11.20 17:13:36 Instance/Wrapper/qLab: Error executing action: Call timed out

Eventually they go through, very slowly.

In v3.4.3, if the cue queue got backed up enough it would crash the qlab-advance module, fwiw. With 3.5 I can't get it to crash but it is effectively frozen until all the cue messages clear.

istnv commented 1 week ago

Some improvements, but not enough. A feature request was added to put cue notes into a variable. That is sometimes a LOT of data. The module tries to keep as much in memory for quick access, but I think it is overwhelming RAM and swap space. The web gui will slow down the entire system trying to hold/display a copy of the 'variables'

MattRogish commented 1 week ago

Ah. I checked and we don't have anything in notes, so I don't think that's the issue.

qLab Advance does create/update a ton of variables, I wonder if that has something to do with it? I do see the "node" process jump up a ton of CPU when I press a cue start button... Anyway, I'll stick with UDP for now and/or drop back to Generic OSC - thanks! Happy to debug any changes you might want to make with this since it's pretty easy to reproduce!

istnv commented 1 week ago

There are a lot of variables that are not directly visible. For example, every Cue name is available, but not listed in the GUI.