3.0 RC1 disconnections

[obcocav]

Is anyone else experiencing disconnections when a vMix button is pressed in the latest RC? Conection shows green until I try an action then disconnects momentarily. Then reconnects but action never fires. Feedbacks do not work either. Thanks

[obcocav]

Nevermind. Just realized my web controller/port had been reenabled.....:)

[obcocav]

Ok so I thought that was it. Turns out I'm still having the problem. error: Function Socket err: connect ETIMEDOUT 192.168.200.101:8099 is the error in the log. Disabling and reenabling usually fixes it after a pause.

[thedist]

I'm unable to reproduce this issue, the connection logic in Companion 3.0 RC1 has been the same throughout the beta of 3.0, and is also mostly the same that's used in Companion 2.4 so it's largely unchanged for well over a year now and I've not received any other reports, especially as a large portion of vMix users were already running the Companion v3 beta for months.

Please ensure that you have a stable connection between Companion, and the vMix machine, as well as that nothing else is running on port 8099 (you can use the web controller, it just has to be on any other port than 8099 as vMix uses that as the TCP port)

[obcocav]

@thedist . I'm going to try to catch it on the log today. FYI there is someone else having the issue over on the FB Companion User group if you haven't seen it as well. I'll send my logs if I can catch it.

[obcocav]

Finally caught it. Here you go @thedist It crashes. Tries to reconnect a couple times then does and works. This all happens when I press the first key for an action. It connects initially until then. Let me know how I can help!

[thedist]

Nothing in those logs is particularly helpful, but the issue you describe where it may seem to connect fine but when you run an action it breaks is indicative of you connecting to the vMix Web Controller, which is not correct.

Please ensure you're connecting to vMix on port 8099 (the vMix TCP port) and that the Web Controller is NOT set to that port. You can have the Web Controller enabled, it just MUST NOT be on port 8099 or otherwise it'll block Companion from connecting to the proper TCP port.

[obcocav]

@thedist. I checked that first thing. It is connected to 8099. Web controller is not enabled but is set to 8088. Looking at CurrPort I dont see anything else using 8099.. :(

[obcocav]

@thedist . Something definately up. When I do cycle the module and it reconnects the actions are delayed and "laggy" both in execution and feedback. I have backed the refresh time down to 100ms just to see and it is noticeably more laggy than that and inconsistent. Is there anything else I can do to help diagnose? Anyone else?? Thank you!

[thedist]

If it gets worse when you make it poll the API faster, that would be indicative of your system running Companion not being capable of polling that fast, so slow it down. Please keep in mind that the more inputs you have in vMix, and the larger any List inputs are, that will increase the amount of data that is being processed every time the API is requested.

[noitvmere]

Hi, I have your same problem. With version 2.4 no problem. With the 3 the same problem as yours arises. I haven't been able to fix it yet.

(sorry for my english, is google translate)

[obcocav]

I’m still trying to narrow down a sequence to recreate it but something is up.  Reinstall of 2.4.2 still works perfect every time and without lag.  Seems a I have a few other modules with some connection type issues as well.  The Vizio Smartcast randomly disconnects after a while and I have to cycle it to get it back.  VICREO listener does the same.  Doesn’t connect properly on startup and cycling the module reconnects it.  Also the Denon recorder module.  Cycling required every so often.Sent from my iPhoneOn Jun 13, 2023, at 07:03, noitvmere @.***> wrote: Hi, I have your same problem. With version 2.4 no problem. With the 3 the same problem as yours arises. I haven't been able to fix it yet. (sorry for my english, is google translate)

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you modified the open/close state.Message ID: @.***>

[obcocav]

@thedist. Is there anyway to see if there is some commonality between this module, the SmartCast module, and the Denon recorder module since those are the ones that have some form of disconnection issue? Though the problem here with the vMix module does appear to be some kind of conflict maybe. But like I said I have changed nothing in my setup and reinstalling 2.4.2 solves the problem every time. 2.4.2 = no issue. 3.0 beta (up to latest as of 2 days ago)=disconnections.

It does appear that it may be linked to maybe the module "timing out" waiting on vMix to start? My companion instance is alway on. When vMix is started it is after long periods of the module attempting to connect. Though like I said before sometimes it appears to connect with a checkmark but at the first attempted action it crashes.

I hope this helps track something down. I can do any other troubleshooting you need to help find a fix!

Thank you!

[thedist]

What system are you running Companion on? We've had some reports of several modules having some issues when running on a Raspberry Pi that are not present when running Companion on a more capable machine.

[obcocav]

It's running on a i7 4770k Windows 10 PC

On Sun, Jun 18, 2023 at 7:43 AM Jeff Martin @.***> wrote:

What system are you running Companion on? We've had some reports of several modules having some issues when running on a Raspberry Pi that are not present when running Companion on a more capable machine.

— Reply to this email directly, view it on GitHub https://github.com/bitfocus/companion-module-studiocoast-vmix/issues/209#issuecomment-1596131600, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMGCL73OI5633HF6C7CVIUTXL3ZXRANCNFSM6AAAAAAYYYPB4A . You are receiving this because you modified the open/close state.Message ID: <bitfocus/companion-module-studiocoast-vmix/issues/209/1596131600@ github.com>

[noitvmere]

It's running on a i7 4770k Windows 10 PC … On Sun, Jun 18, 2023 at 7:43 AM Jeff Martin @.***> wrote: What system are you running Companion on? We've had some reports of several modules having some issues when running on a Raspberry Pi that are not present when running Companion on a more capable machine. — Reply to this email directly, view it on GitHub <#209 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMGCL73OI5633HF6C7CVIUTXL3ZXRANCNFSM6AAAAAAYYYPB4A . You are receiving this because you modified the open/close state.Message ID: <bitfocus/companion-module-studiocoast-vmix/issues/209/1596131600@ github.com>

My system is similar. Is an hp with I7, windows 10.

[noitvmere]

@thedist. C'è comunque da vedere se c'è qualche comunanza tra questo modulo, il modulo SmartCast e il modulo del registratore Denon poiché quelli sono quelli che hanno qualche forma di problema di disconnessione? Anche se il problema qui con il modulo vMix sembra essere forse una sorta di conflitto. Ma come ho detto non ho cambiato nulla nella mia configurazione e reinstallare 2.4.2 risolve il problema ogni volta. 2.4.2 = nessun problema. 3.0 beta (fino a 2 giorni fa)=disconnessioni.

Sembra che possa essere collegato forse al "timeout" del modulo in attesa dell'avvio di vMix? La mia istanza companion è sempre attiva. Quando vMix viene avviato è dopo lunghi periodi in cui il modulo tenta di connettersi. Anche se come ho detto prima a volte sembra connettersi con un segno di spunta ma alla prima azione tentata si blocca.

Spero che questo aiuti a rintracciare qualcosa. Posso fare qualsiasi altra risoluzione dei problemi di cui hai bisogno per aiutarti a trovare una soluzione!

Grazie!

My problem is the same. With 2.4 is all ok, with 3.0 only vmix have trouble.

[thedist]

If it's not a Pi issue then it's going to be hard to diagnose, as none of any of the testers who have been using 3.0 in production since January have experienced what you are.

Could you please share your Companion config so I can look in to if it's a configuration issue, or misconfigured actions/feedbacks

[obcocav]

@thedist Its attached. Also just noticed that when I add a second instance of the vMix module for testing changing the ip address from the default 127.0.0.1 to the correct 192xxx address and clicking save does NOT save until after I restart the module. I don't recall that being the case before. Could it be that the module is defaulting to the Local machine address sometimes and that restarting the module resets it? Thanks! >>>ADDED .PDF ON THE END TO GET IT TO UPLOAD<<<

CompanionServerNEW_custom-config_20230619-1913.companionconfig.pdf

[noitvmere]

Same thing for me. Same issue! In two system and two networks: one with satellite, one direct.

[thedist]

I've found the issue you refer to with changing the config not correctly updating until the instance is disabled/enabled again, I'll have a fix for that shortly. The issue only impacted the moment you changed the config, once the config was changed and the module restarted it would always be using the correct config values and so is not related to the main issue you're experiencing.

My current thoughts about the issue at the moment is that the TCP socket used for sending functions is idle between initialization and sending actions, so there may be some odd situation where the connection is being dropped by vMix or a network device between Companion and the vMix machine due to inactivity. I've never heard of vMix dropping connections even if idle for days at a time, but it's the only thing I think may be an issue, so as well as some additional TCP connection status logging to debug I've also added PING messages to the connections that are usually idle, so if the connection does die for whatever reason it should realise it much sooner and recover rather than only finding out when you send an action.

I've pushed an update and will reply when it's added to a Companion build.

[noitvmere]

Thanks! We want upgrade to 3.0 version for use the new functions.

[thedist]

The latest Beta build, 3.0.0+5975, has the latest vMix update in it.

[obcocav]

Downloaded 5975 and havent seen the issue...BUT now my i7 4770 slowly bogs down to unusable with 70% CPU usage. When I turn vMix instance off usage drops back to 20% or so. Any ideas on that? Thanks for your help!

[thedist]

Check the log for the vMix instance and see what sort of messages are shown that may indicate an error.

Looking at my CPU usage, with a 52 input vMix project the Node.js process for my vMix instance in companion sits at 0%, going up to 7% when I have lots of video inputs concurrently running, then drops down to 0% when those inputs stop playing.

The only errors I notice are the pings throwing an error if there's no connection to vMix, which will be handled in the next commit but is not related to CPU usage.

[obcocav]

Hmm. Nothing in the log. The vMix node is running around 20-25% CPU usage sometimes closer to 30. When disabled the entire GUI is much more responsive regardless if CPU. Just tried it on a i5 12450h with a similar result although the total CPU usage was lower obviously.

[thedist]

What sort of vMix project are you working with? ie, how many inputs and what sort of types, do you have lots of of concurrent audio/video inputs playing (and if so, do you notice a CPU difference when these inputs are not playing).

Also, can you try with an empty vMix project and see what the CPU usage for the vMix Node process is like then.

[obcocav]

@thedist. My project has 80 inputs. Most are copies to provide different side by side compositions. Only 6 live shots via NDI/SDI. Also using External output and two fullscreen outputs. Dante Audio input and 1 looping animated logo video that's about 10sec long. Another 5 minute preroll video that's about 5 minutes but it only plays once before the broadcast. Like I said nothing has changed there since 2.4.2 which worked great!

I tried a blank document and it did appear to decrease the CPU usage to 4-5%. So something is up.

I did notice today that there are two node instances that run the CPU up when vMix module is enabled. each around 15-20%. When I disable both drop off. Any way to see what each Node instance is in the Task manager? Any other diagnosing ideas? Thanks for your help!

[obcocav]

@thedist. Ok so I've been playing some more. Maybe I don't understand how the "API Polling" Option Works? I had it set to 100. Finally thought to change it to 0 for disabled after reading the note and CPU dropped off. But my feedbacks still work...?? What am I missing on that? Thanks

[thedist]

The only thing I can think to try at the moment is if you could send me your API data from vMix so that I can try run that through as a test sample and see if I encounter what you're experience. You can get this data by going to your vMix Web Interface and adding /api. So for example if you're running vMix locally, and have the Web Controller set to 8088, you'd go to http://localhost:8088/api. Then just copy all of that and paste it in a text file. That way I can work with the data your vMix is using without needing any of your actual vMix project.

I tried a blank document and it did appear to decrease the CPU usage to 4-5%. So something is up.

A blank vMix project should use almost 0% CPU. There's literally barely any data to process so there's nothing to use the CPU, and even when I add in more verbose logging none of my testers can replicate this.

I did notice today that there are two node instances that run the CPU up when vMix module is enabled. each around 15-20%. When I disable both drop off. Any way to see what each Node instance is in the Task manager? Any other diagnosing ideas?

Each instance will be a single Node process in Companion 3, so you could disable the vMix instance, make a note of what Node process ID's are running, then enable the vMix instance and see which is a new process ID and that'll be the vMix instance.

Ok so I've been playing some more. Maybe I don't understand how the "API Polling" Option Works? I had it set to 100. Finally thought to change it to 0 for disabled after reading the note and CPU dropped off. But my feedbacks still work...?? What am I missing on that?

Even when API polling is disabled there will still be a connection to vMix for Activator data. This means that feedback based on Activator data will still be possible, but the vast majority of feedbacks and instance variables will not work as vMix Activators only provide very basic info and for a select handful of data points.

[obcocav]

@thedist. OK..I think I have finally ruled out vMix itself now that I figured out that the polling time got changed somehow. Sitting at 250 now and all appears stable. I think my memory issue was a coincidence with a problem in the update to the TPlink Kasas module.

https://github.com/bitfocus/companion-module-tplink-kasasmartplug/issues/15

That said. It does appear something strange changed around 5970 as like I said Companion shows a parent process there and before in Task Manager and only the Nodejs processes after.

[thedist]

The latest Companion beta build should also help resolve some of these performance related issues, and potentially allow for faster polling again.

If the issues come back we can reopen the issue.