Describe the bug/issue
Whenever the Pro7 module is connected to Pro7, URI errors populate the Pro7 log uncontrollably, causing it to grow far past what it ever should and (from what I can put together) also cause hangs and occasional crashes. The errors come in pairs, first naming a presentation (seems random, and RV has never found anything wrong when I've sent them exported presentations for support) then giving the following line: "System.UriFormatException: Invalid URI: The format of the URI could not be determined." It then spouts a bunch of path stuff and mentions something about Boolean directories and repeats. Repeated errors commonly cycle about .07 seconds but can sometimes cycle multiple times per millisecond, leading to the wild log growth. Largest log I've noted in the past 1-1/2 years was 40GB (yes, Gigs) before Pro7 cycled into a new log file. It's common to find logs grown to 10GB over the course of a week or a Sunday morning. I've since implemented a batch file to manually archive the log after the pre-service reboot so the log is new in case the large log file read-write contributes to hangs/crashes.
This behavior happens across all playlists when I've investigated, though we primarily use a single playlist duplicated and modified for Sunday mornings.
Additionally, I noted another error I've never seen before when I tested the connection from a secondary computer (typical connection is internal rather than over the network). This other error notes that Pro7 "Expected a control tower -> websocket sender but didn't find one." Otherwise, it behaved precisely as is typical.
Finally, this behavior is the same even with all Pro7 polling turned off, buttons deleted, and triggers disabled. It seems it's strictly the connection status that causes the errors.
To Reproduce
Steps to reproduce the behavior:
Run Pro7 and Pro7 module simultaneously
Close Pro7
Check Pro7 log
Expected behavior
When the Pro7 module is enabled but no commands are being sent, there's hardly any difference in how Pro7 runs, to the point of being difficult to tell it was even connected if you're looking at technical records.
Screenshots
Please add screenshots (or full text descriptions) showing:
ProPresenter playlist/presentations used
ProPresenter module config.
The config of any Buttons used.
Config of any variables used.
Config of any triggers used.
Pro7 module config:
Log entries for URI error:
Log entries for "control tower" error:
Versions/Environment (please complete the following information):
ProPresenter Version: 7.13.1 (beta) (has been occurring since probably 7.8 or so...? It's been a while)
OS of ProPresenter Machine: Windows 10
Companion Version: 2.4.0 (was happening back on 2.3.x)
OS of Companion machine: Windows 10 (both local and remote tests)
Debug log output when issue occurs: I don't know how to do this and will do that with some help
Describe the bug/issue Whenever the Pro7 module is connected to Pro7, URI errors populate the Pro7 log uncontrollably, causing it to grow far past what it ever should and (from what I can put together) also cause hangs and occasional crashes. The errors come in pairs, first naming a presentation (seems random, and RV has never found anything wrong when I've sent them exported presentations for support) then giving the following line: "System.UriFormatException: Invalid URI: The format of the URI could not be determined." It then spouts a bunch of path stuff and mentions something about Boolean directories and repeats. Repeated errors commonly cycle about .07 seconds but can sometimes cycle multiple times per millisecond, leading to the wild log growth. Largest log I've noted in the past 1-1/2 years was 40GB (yes, Gigs) before Pro7 cycled into a new log file. It's common to find logs grown to 10GB over the course of a week or a Sunday morning. I've since implemented a batch file to manually archive the log after the pre-service reboot so the log is new in case the large log file read-write contributes to hangs/crashes.
This behavior happens across all playlists when I've investigated, though we primarily use a single playlist duplicated and modified for Sunday mornings.
Additionally, I noted another error I've never seen before when I tested the connection from a secondary computer (typical connection is internal rather than over the network). This other error notes that Pro7 "Expected a control tower -> websocket sender but didn't find one." Otherwise, it behaved precisely as is typical.
Finally, this behavior is the same even with all Pro7 polling turned off, buttons deleted, and triggers disabled. It seems it's strictly the connection status that causes the errors.
To Reproduce Steps to reproduce the behavior:
Expected behavior When the Pro7 module is enabled but no commands are being sent, there's hardly any difference in how Pro7 runs, to the point of being difficult to tell it was even connected if you're looking at technical records.
Screenshots Please add screenshots (or full text descriptions) showing:
Pro7 module config:
Log entries for URI error:
Log entries for "control tower" error:
Versions/Environment (please complete the following information):