In order to figure out way my EXIP418 still reboots at least once a day(after the fixes in the past couple of days), I added a few lines to the code for debugging:
After I pulled a day worth of log data from VDR, a few lines of Python code showed, that the commands being sent to a particular device sometimes come in without any delay:
waiting: 250.0ms
command: PLAY
uri: rtsp://10.6.66.254/STREAM_ID?delpids=18
device: [device 2]
waiting: 1.0ms
command: PLAY
uri: rtsp://10.6.66.254/STREAM_ID?src=1&freq=11685&pol=v&ro=0.35&msys=dvbs&mtype=qpsk&plts=off&sr=22000&fec=56
device: [device 2]
The standard 250ms delay always seems to be missing right before a new channel is requested.
I also found that after a TEARDOWN, the plugin did not wait before issuing OPTIONS, SETUP & PLAY:
In order to figure out way my EXIP418 still reboots at least once a day(after the fixes in the past couple of days), I added a few lines to the code for debugging:
The "error" line was added to each RTSP function , in order to see when a command was issued. The cleaned up log then looked like this:
After I pulled a day worth of log data from VDR, a few lines of Python code showed, that the commands being sent to a particular device sometimes come in without any delay:
The standard 250ms delay always seems to be missing right before a new channel is requested.
I also found that after a TEARDOWN, the plugin did not wait before issuing OPTIONS, SETUP & PLAY: