home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Area 51 - Testing Area
RTSP streaming library update
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="mm1352000" data-source="post: 1171350" data-attributes="member: 82144"><p>You're right - no sign of errors there. Interestingly there are also no signs that the TsReader change is having any effect. I would have known by the presence of certain log entries... but those tell-tale entries are completely absent.</p><p></p><p>Previously I had thought that the duration of the streaming - which ties in with the too-complex-to-fully-explain "PCR roll-over" mentioned in my previous reply - was the sole determinant of what you were seeing. Comparing the duration of this test with the previous test, we have:</p><p>[2016-01-10 10:20:43,732] [Log ] [MPMain ] [INFO ] - TVHome.ViewChannelAndCheck(): View channel=BBC ONE HD</p><p>...</p><p>[2016-01-11 04:23:55,015] [Log ] [MPMain ] [DEBUG] - VMR9Helper: Playing -> Repainting, Frames 0</p><p></p><p>[2016-01-12 20:28:01,235] [Log ] [MPMain ] [INFO ] - TVHome.ViewChannelAndCheck(): View channel=BBC TWO HD</p><p>...</p><p>[2016-01-13 17:41:34,746] [Log ] [MPMain ] [INFO ] - TVHome.ViewChannelAndCheck(): View channel=BBC ONE HD</p><p></p><p>...so ~18 hours vs. ~21 hours. If my previous theory was correct then a longer test <em>should</em> have run into the same issue as the previous test and either passed (due to the TsReader change) or failed with the same symptoms... but to have no issues <em>and</em> no effect from my change makes no sense.</p><p></p><p></p><p>Considering the technicalities of PCR roll-overs...</p><p></p><p>A [hopefully!] simple way to understand what I'm talking about is to imagine that there are 2 timers associated with the stream. These timers are used as references for decoding and syncing the video, audio, subtitles etc. correctly. Each timer counts from 0 to ((2^33) - 1) [let's call it PCR-max for ease of explanation], and then rolls-over and starts at 0 again. Timer 1 is the broadcaster's timer. It could be anywhere between 0 and PCR-max when you start streaming. Timer 2 is TV Server's timer. It always starts at 0 when you start streaming. These timers [should!] count up at a consistent rate, such that it takes approximately 26.5 hours to get back to where they started from (ie. if a timer starts at 0, it will take 26.5 hours before it gets back to 0).</p><p></p><p>In the previous log files the issue <em>seemed </em>to start when the broadcaster's clock rolled over... though I was unable to be certain of that due to the limited history in the TsWriter log.</p><p></p><p>In these log files I can confirm that the broadcaster clock rolled over:</p><p>[2016-01-12 20:28:31,592] [743d818] [157c] - Recorder: TIMESHIFT Info : Next broadcaster program clock reference rollover : 0 days 17:00:00 0</p><p></p><p>...and like clockwork, 17 hours later:</p><p>[2016-01-13 13:28:33,074] [743d818] [157c] - Recorder: TIMESHIFT Info : Normal broadcaster program clock reference rollover passed !</p><p>[2016-01-13 13:28:33,074] [743d818] [157c] - Recorder: TIMESHIFT Info : Normal broadcaster program clock reference rollover passed !</p><p></p><p>As you've said there were no apparent problems. This essentially destroys my previous theory.</p><p></p><p>It's unfortunate that the latest test didn't quite get to the 26.5 hour mark when the TV Server clock would have been expected to roll over. That would have been interesting to see/test. However, 21 hours with a broadcaster PCR roll-over <em>should </em>have been enough to trigger the problem.</p></blockquote><p></p>
[QUOTE="mm1352000, post: 1171350, member: 82144"] You're right - no sign of errors there. Interestingly there are also no signs that the TsReader change is having any effect. I would have known by the presence of certain log entries... but those tell-tale entries are completely absent. Previously I had thought that the duration of the streaming - which ties in with the too-complex-to-fully-explain "PCR roll-over" mentioned in my previous reply - was the sole determinant of what you were seeing. Comparing the duration of this test with the previous test, we have: [2016-01-10 10:20:43,732] [Log ] [MPMain ] [INFO ] - TVHome.ViewChannelAndCheck(): View channel=BBC ONE HD ... [2016-01-11 04:23:55,015] [Log ] [MPMain ] [DEBUG] - VMR9Helper: Playing -> Repainting, Frames 0 [2016-01-12 20:28:01,235] [Log ] [MPMain ] [INFO ] - TVHome.ViewChannelAndCheck(): View channel=BBC TWO HD ... [2016-01-13 17:41:34,746] [Log ] [MPMain ] [INFO ] - TVHome.ViewChannelAndCheck(): View channel=BBC ONE HD ...so ~18 hours vs. ~21 hours. If my previous theory was correct then a longer test [I]should[/I] have run into the same issue as the previous test and either passed (due to the TsReader change) or failed with the same symptoms... but to have no issues [I]and[/I] no effect from my change makes no sense. Considering the technicalities of PCR roll-overs... A [hopefully!] simple way to understand what I'm talking about is to imagine that there are 2 timers associated with the stream. These timers are used as references for decoding and syncing the video, audio, subtitles etc. correctly. Each timer counts from 0 to ((2^33) - 1) [let's call it PCR-max for ease of explanation], and then rolls-over and starts at 0 again. Timer 1 is the broadcaster's timer. It could be anywhere between 0 and PCR-max when you start streaming. Timer 2 is TV Server's timer. It always starts at 0 when you start streaming. These timers [should!] count up at a consistent rate, such that it takes approximately 26.5 hours to get back to where they started from (ie. if a timer starts at 0, it will take 26.5 hours before it gets back to 0). In the previous log files the issue [I]seemed [/I]to start when the broadcaster's clock rolled over... though I was unable to be certain of that due to the limited history in the TsWriter log. In these log files I can confirm that the broadcaster clock rolled over: [2016-01-12 20:28:31,592] [743d818] [157c] - Recorder: TIMESHIFT Info : Next broadcaster program clock reference rollover : 0 days 17:00:00 0 ...and like clockwork, 17 hours later: [2016-01-13 13:28:33,074] [743d818] [157c] - Recorder: TIMESHIFT Info : Normal broadcaster program clock reference rollover passed ! [2016-01-13 13:28:33,074] [743d818] [157c] - Recorder: TIMESHIFT Info : Normal broadcaster program clock reference rollover passed ! As you've said there were no apparent problems. This essentially destroys my previous theory. It's unfortunate that the latest test didn't quite get to the 26.5 hour mark when the TV Server clock would have been expected to roll over. That would have been interesting to see/test. However, 21 hours with a broadcaster PCR roll-over [I]should [/I]have been enough to trigger the problem. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Area 51 - Testing Area
RTSP streaming library update
Contact us
RSS
Top
Bottom