Just upgraded, working ;-) . Can see when I change TV channels the screen goes black (as before), then I get a glimt of the previous channel before I get the one I have tuned to. The chanel changing time seems to be the same as before (2-3 sec.) This isn't a problem for me at all. Just wanted to mention it.Oops, I was sure that I had upgraded my client to 1.12 (I almost always upgrade the clients when new software comes along.
Doing an upgrade now, I'll post back my comments
GreatJust upgraded, working ;-)
Yes, this was also reported in internal testing. As far as we could see, that behaviour was already existing before the update was applied.Can see when I change TV channels the screen goes black (as before), then I get a glimt of the previous channel before I get the one I have tuned to.
The performance improvements are related to simplification/reduction of the RTSP requests sent to the server. Savings are probably 200 ms at most, depending on network speed/latency. This may be most obvious at start of live TV or recording playback, and during skipping/seeking.The chanel changing time seems to be the same as before (2-3 sec.) This isn't a problem for me at all. Just wanted to mention it.
GreatJust upgraded, working ;-)
Yes, this was also reported in internal testing. As far as we could see, that behaviour was already existing before the update was applied.Can see when I change TV channels the screen goes black (as before), then I get a glimt of the previous channel before I get the one I have tuned to.
Can you confirm that you saw this before applying the update, or do you think it is new behaviour?
This may have happened sometimes before, but now it seems to be always.
The performance improvements are related to simplification/reduction of the RTSP requests sent to the server. Savings are probably 200 ms at most, depending on network speed/latency. This may be most obvious at start of live TV or recording playback, and during skipping/seeking.The chanel changing time seems to be the same as before (2-3 sec.) This isn't a problem for me at all. Just wanted to mention it.
[2015-10-25 09:08:23,056] [11297fe8] [4888] - CRTSPClient:lay(): start = 1805.464966, duration = 6002.535156
[2015-10-25 09:08:23,056] [11297fe8] [4888] - CRTSPClient:lay()
[2015-10-25 09:08:23,557] [11297fe8] [4888] - CRTSPClient:lay(): RTSP PLAY timed out
25-10-2015 09:08:23.79 StreamingServer:: Seek-> 1805.465000/6001.535156
25-10-2015 09:08:23.80 seek to 1805.465000 filepos:5983e1d4 pid:30
25-10-2015 09:08:24.564 stop seek: 1805.453717 at 5ff7a07d - target: 1805.465000, diff: 0.011283
25-10-2015 09:08:24.564 ts seekStreamSource 1805.465000 / 6001.535156 ->1501815266
25-10-2015 09:09:42.980 StreamingServer:: Seek-> 1805.465000/6001.535156
25-10-2015 09:09:42.981 seek to 1805.465000 filepos:5983e1d4 pid:30
25-10-2015 09:09:42.982 stop seek: 1805.453717 at 5ff7a07d - target: 1805.465000, diff: 0.011283
25-10-2015 09:09:42.982 ts seekStreamSource 1805.465000 / 6001.535156 ->1501815266
For now I prefer to keep testing with the current time-out (500 ms). I would have expected the current value would be more than necessary (even excessive) for RTSP on a local network. Maybe the problem only happens when the HDD needs to spin up??? Anyway, please let me know if you notice problems again, and how often it happens. If it happens frequently then we will need to increase the value. Log files will be required to decide how much to increase it.yep maybe it could be nice idea to increase the timeout