Companion loses connection to Pro 7.8 when a device app closes

[onfire4g05]

When ProPresenter Remote (iPad version tested) closes/sleeps, commands can no longer be sent to ProPresenter via Companion until the app is reopened/resumed or Companion manually reconnects.

Pro 7.4 = Companion can see the disconnection from iPad app and reconnects to ProPresenter. Pro 7.8 = Companion loses connection and must manually be reconnected to ProPresenter OR the Remote App must be opened again.

A workaround to this bug is to add a reconnect to button presses that interact with Pro; however, variables obviously won't work until it's reconnected so this isn't really a good fix.

I'm not entirely sure where this bug lies (Pro or this module). I'm leaning towards probably Pro, since it looks like it's only wanting to have a single device connected vs allowing for multiple. I plan to do some digging later today to see if I can find a fix for it in the module. In the meantime, if someone is having connectivity issues, this might be the reason.

[onfire4g05]

I think this is a ProPresenter bug and I don't know if it's something that can be fixed since the socket stays open and it doesn't appear that ping/pong works with these connections so we could verify it's still connected.

There's actually a vulnerability in ProPresenter that, if a WS is already authenticated, future connections can piggyback off of the original connection -- no authentication required.

Thus, when the connection is closed it breaks all other connections until a new auth is sent. You can duplicate this by closing the Companion connection to Pro, which then breaks the iPad apps connection.

[greyshirtguy]

Pro7.8 on Win or MAc (or both?) I should prob look into this and try and put in a workaround in time for 2.2 release... The module issues a command {"action":"clockStartSendingCurrentTime"} when it first authenticated. This causes Pro 6/7 (on both Mac/Win) to send regular clock update messages back to the Companion - at least once per second). I could easily check how "stale" the last "clockCurrentTimes" message is and attempt a re-auth (or re-connect). Since this would be a dirty workaround - I'd prob add a config option to turn it off/on.

[onfire4g05]

We're full macOS, so haven't tested Windows.

Your solution should be a great work around. Honestly, I think it's necessary either way to know if the connection has been lost – either thru this, network loss, etc. Perhaps there can be a stale option with a time limit that defaults to like 5s?

[greyshirtguy]

Sure.. I'll have a think about options....If I go the stale timer update triggering a re-auth/connection I'll need to think about an an appropiate retry pattern.

[greyshirtguy]

I'll first try to replicate and see if the websocket is bubbling up any events at all that report it. It may well be sending an error event (which I current don't do much with!!!)

[onfire4g05]

I did try looking at all incoming events using Wireshark and watching for events in the module code itself, but didn't see anything (their own iPad app fails the same way Companion does). I could have definitely missed something tho.

On Thu, Feb 10, 2022, 10:56 PM greyshirtguy @.***> wrote:

I'll first try to replicate and see if the websocket is bubbling up any events at all that report it. It may well be sending an error event (which I current don't do much with!!!)

— Reply to this email directly, view it on GitHub https://github.com/bitfocus/companion-module-renewedvision-propresenter/issues/109#issuecomment-1035884291, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHR7QEM3AAQIKRU3YR7KT3U2SJJNANCNFSM5N54C2ZQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: <bitfocus/companion-module-renewedvision-propresenter/issues/109/1035884291 @github.com>

[greyshirtguy]

There is NO error whatsoever on the socket! I tried that workaround, and when I re-connect and re-authenticate - IT STILL FAILS to receive clock update messages! The only thing I could get working was to disable and re-enable the module! I have added some module vars that allow us to monitor when it happens. Then it's easy to manually reset the module (or even setup a trigger to auto-reset). This is crude - but it works for now.

[greyshirtguy]

Noticed it happens on both Mac and Windows!

[onfire4g05]

If there are no more clock updates, couldn't we just close the socket completely and then reconnect? Or possibly wait a second or so if that doesn't work and then reconnect? This could make the connection much more robust for the future as well, since I've seen Companion disconnect from Pro7 before and we'd have to disable/re-enable or restart companion. I'm not sure what's caused it in the past, since it seemed random.

Also, I did let RV know about the issue. I referenced this issue. They duplicated the issue on their end using two iOS RV apps (to rule Companion out). Hopefully we'll see a fix for this issue/proper WS support soon.