Currently the client halts when an error is encountered.
Would it be possible without much effort to have a wrapper around the example program where errors are treated as they are in moonfire-nvr and the same recourse, e.g. attempt opening a new connection or continue within a set time (this might be parameterized, too), resorted to? It would be helpful to have some parameterized values such as wait-timeout-before-reconnecting which one could use to determine what time is needed before Reolink cameras will accept a new connection and treat it as new rather than resuming an old one.
I have witnessed that if I connect and error will occur. If I immediately launch the example script again, it looks like the client example script immediately errors out because of transmissions from Reolink from the prior session. This is my guess. I find if I wait a few minutes, I can at least make a new connection and get some data before another error is encountered. This time from an opening connection to an error condition seems to vary from 4 seconds to 20 seconds to 1 minute. I can see why Reolink camera's rtsp servers are frowned upon.
Goal: I would like to be able to point multiple sessions of this client to cameras and create log files that document the errors encountered such as in moonfire-nvr. This is to be able to stress test a camera and/or network.
What's good about this client is that it can be run in parallel with other session unlike in moonfire-nvr where everything has to be coordinated for the database.
I tried to make sens of lines 46-57 to see if I could create an indefinite loop, but my lack of understanding rust programming caused me to realize I do not know the fundamental loop structures, not do I know (without doing some code study of moonfire-nvr) what higher level handling occurs when errors are encountered.
Currently the client halts when an error is encountered.
Would it be possible without much effort to have a wrapper around the example program where errors are treated as they are in moonfire-nvr and the same recourse, e.g. attempt opening a new connection or continue within a set time (this might be parameterized, too), resorted to? It would be helpful to have some parameterized values such as wait-timeout-before-reconnecting which one could use to determine what time is needed before Reolink cameras will accept a new connection and treat it as new rather than resuming an old one.
I have witnessed that if I connect and error will occur. If I immediately launch the example script again, it looks like the client example script immediately errors out because of transmissions from Reolink from the prior session. This is my guess. I find if I wait a few minutes, I can at least make a new connection and get some data before another error is encountered. This time from an opening connection to an error condition seems to vary from 4 seconds to 20 seconds to 1 minute. I can see why Reolink camera's rtsp servers are frowned upon.
Goal: I would like to be able to point multiple sessions of this client to cameras and create log files that document the errors encountered such as in moonfire-nvr. This is to be able to stress test a camera and/or network.
What's good about this client is that it can be run in parallel with other session unlike in moonfire-nvr where everything has to be coordinated for the database.
I tried to make sens of lines 46-57 to see if I could create an indefinite loop, but my lack of understanding rust programming caused me to realize I do not know the fundamental loop structures, not do I know (without doing some code study of moonfire-nvr) what higher level handling occurs when errors are encountered.