TC 'Crash' issue
-
I have a project in which I am getting a stream of position, size, and movement data from a LiDAR system on stage and I'm using TCP (TCP In Watcher - Text) to ingest the data into Isadora.
The data streams in very well and I'm able to parse and utilize the data just fine. However, most of the time Isadora will just unexpectedly close. This behavior may happen after just a few minutes or more than an hour. Most of the time it is just sitting there running with no human interaction with Isadora and it just closes itself. There are no 'crash' reports, there are no message, there are no 'warnings', there is no discernable 'behavior' changes of Isadora, etc. - Isadora just closes.
Of course, I have to use the TCP Stream Control actor along with the TCP In Watcher. If I do not 'activate' the TCP Stream then Isadora works just fine and operates as expected. If I activate it, then it becomes a question of when Isadora will just unexpectedly close.
This behavior happens on two different machines running Isadora with different configurations. A visual inspection of the data stream from the server side appears all fine.
Thoughts/Suggestions?
Izzy 3.2.6 Windows 11 Pro 64-bit, 13th Gen Intel Core i9-13900H 2.60 GHz, 64GB RAM, 2TB SSD, NVIDIA GeForce GTX 4070
-
Set up your patch to write the data to a text file to see what message might be causing the problem. it'll be the last line. IF the last line is the same in multiple cases, then we may be able to find out something about the data's formatting or content which may be causing the problem.
-
Wolands idea of setting up some logging of the sent data is a great start. If it is in fact some parsing error, that should point out the issue.
Do you have the issue if you periodically close the TCP connection? How quickly is the data being set to Isadora?
-
Data is being sent at 20Hz. Data is in JSON format
I'm not sure of the best approach to building a log file (capture data [json format] and write to external file). Using a Data Array would require me to write the file but I may not get to 'write' the file if Izzy just closes. A search of the forum does not yield a lot of results on options/examples of writing a log file before a 'crash'.Suggestions?
Izzy 3.2.6 Windows 11 Pro 64-bit, 13th Gen Intel Core i9-13900H 2.60 GHz, 64GB RAM, 2TB SSD, NVIDIA GeForce GTX 4070
-
I imagine you could use a Value Delay Line actor as a way to ensure you can write any incoming value to a data array before passing it along to the rest of the patch.
This should allow you to determine if the issue is before or after the Value Delay Line, and if its after, you should be able to see the data saved to the txt file. If the issue is before the Value Delay Line (which I think should be directly after the receiving actor) we can look more closely at the TCP parsing side of things. -
We continue to work on this issue since we are still running into the unexplained 'crashes'. Additional information that we were able to deduce today is as follows:
1) Isadora runs for about 20 minutes or so with the TCP stream active and the TCP in Watcher running before 'crash'. This time span is variable. Is there some kind of known issue about running TCP related actors for long periods of time?2) We developed a python script to run simultaneously to do the same thing as Isadora and it does not run into any problems.
3) Using the Data Array actor to capture the incoming data stream, we do not see any odd characters, etc. The last message is truncated but that may be due to the fact that Isadora 'crashed'.
The use of the TCP data stream is critical for this project so any input, assistance, suggestions would be greatly appreciated.
