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
Support
Watch / Listen Media
Television (MyTV frontend and TV-Server)
Locked time-shift files cause failure to change channel
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: 1173488" data-attributes="member: 82144"><p>[USER=83973]@Owlsroost[/USER]</p><p>A brief outline of what I've been thinking...</p><p></p><p>The thing that stands out to me first is the streaming server suddenly starting to fail to calculate the stream duration properly:</p><p>26-01-2016 04:14:03.364 generateSDPDescription() duration 4514.054199 : a=range:npt=0-4514.054</p><p>26-01-2016 04:14:09.869 generateSDPDescription() duration 0.000000 : a=range:npt=0-</p><p></p><p>If you adjust for the clock difference between client and server (~1m 11s) that timing seems to coincide nicely with the TsReader duration requests starting to time out:</p><p>[2016-01-26 04:12:57,652] [1a00eaf0] [ ba4] - CRTSPClient::UpdateDuration(): RTSP DESCRIBE timed out, message = liveMedia6</p><p>[2016-01-26 04:13:01,375] [1a00eaf0] [ ba8] - CRTSPClient::ThreadProc(): recreate RTSP client</p><p></p><p>So, I assume these events are connected in some way. However a zero-value duration would not be directly interpreted as a time-out. Time-out is independent:</p><p><a href="https://github.com/MediaPortal/MediaPortal-1/blob/EXP-Upgrade_LIVE555/DirectShowFilters/TsReader/source/RTSPClient.cpp#L522" target="_blank">https://github.com/MediaPortal/MediaPortal-1/blob/EXP-Upgrade_LIVE555/DirectShowFilters/TsReader/source/RTSPClient.cpp#L522</a></p><p></p><p>Therefore I'm left uncertain as to exactly what the connection is.</p><p></p><p></p><p>I suspect the CPU usage on the server side is TsWriter spinning its wheels trying to create/reuse files, and all the logging. This seems to start some time after the streaming server duration calculation failure:</p><p>[2016-01-26 04:32:49,964] [48ca9b0] [1b24] - MultiFileWriter: failed to create file E:\\live9-0.ts.tsbuffer5.ts</p><p>[2016-01-26 04:32:49,964] [48ca9b0] [1b24] - Failed to reopen old file. It's currently in use. Dropping data!</p><p></p><p>Based on the ~10 minute gap between creation timestamps on the time-shift files (as shown in the screenshots), I'm wondering if the delay between the streaming server and TsWriter problems starting could coincide with the time it takes TsWriter to fill a single time-shift buffer file. If it did, I was thinking maybe the failure in streaming server was responsible for locking the buffer file, thereby triggering the TsWriter problems. However the delay is a little bit on the long side so I'm uncertain...</p><p></p><p></p><p>Currently my thinking is that the frozen screen on the client side is just a delayed symptom of the streaming server and/or TsWriter problems. The thing that doesn't make sense to me is the delay. From the continuity errors in the TsReader log I assume that TsReader is receiving data (and codecs are decoding/displaying, and renderers are rendering) until ~4:22. That's smack bang between the streaming server and TsWriter problem start times. I can't figure out why it should be that time, and not at the same time as either streaming server or TsWriter falling over. I did note with some interest during my LIVE555 update testing that TsReader seems to be able to continue playing an RTSP stream even without duration updates. On that basis I'm assuming it's more likely to be the TsWriter issue that directly causes TsReader to stop receiving data (=> freeze). However perhaps streaming server's failure to calculate durations is a symptom of a wider problem that eventually causes it to stop streaming completely.</p><p></p><p>Lots of uncertainties... <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /></p></blockquote><p></p>
[QUOTE="mm1352000, post: 1173488, member: 82144"] [USER=83973]@Owlsroost[/USER] A brief outline of what I've been thinking... The thing that stands out to me first is the streaming server suddenly starting to fail to calculate the stream duration properly: 26-01-2016 04:14:03.364 generateSDPDescription() duration 4514.054199 : a=range:npt=0-4514.054 26-01-2016 04:14:09.869 generateSDPDescription() duration 0.000000 : a=range:npt=0- If you adjust for the clock difference between client and server (~1m 11s) that timing seems to coincide nicely with the TsReader duration requests starting to time out: [2016-01-26 04:12:57,652] [1a00eaf0] [ ba4] - CRTSPClient::UpdateDuration(): RTSP DESCRIBE timed out, message = liveMedia6 [2016-01-26 04:13:01,375] [1a00eaf0] [ ba8] - CRTSPClient::ThreadProc(): recreate RTSP client So, I assume these events are connected in some way. However a zero-value duration would not be directly interpreted as a time-out. Time-out is independent: [URL]https://github.com/MediaPortal/MediaPortal-1/blob/EXP-Upgrade_LIVE555/DirectShowFilters/TsReader/source/RTSPClient.cpp#L522[/URL] Therefore I'm left uncertain as to exactly what the connection is. I suspect the CPU usage on the server side is TsWriter spinning its wheels trying to create/reuse files, and all the logging. This seems to start some time after the streaming server duration calculation failure: [2016-01-26 04:32:49,964] [48ca9b0] [1b24] - MultiFileWriter: failed to create file E:\\live9-0.ts.tsbuffer5.ts [2016-01-26 04:32:49,964] [48ca9b0] [1b24] - Failed to reopen old file. It's currently in use. Dropping data! Based on the ~10 minute gap between creation timestamps on the time-shift files (as shown in the screenshots), I'm wondering if the delay between the streaming server and TsWriter problems starting could coincide with the time it takes TsWriter to fill a single time-shift buffer file. If it did, I was thinking maybe the failure in streaming server was responsible for locking the buffer file, thereby triggering the TsWriter problems. However the delay is a little bit on the long side so I'm uncertain... Currently my thinking is that the frozen screen on the client side is just a delayed symptom of the streaming server and/or TsWriter problems. The thing that doesn't make sense to me is the delay. From the continuity errors in the TsReader log I assume that TsReader is receiving data (and codecs are decoding/displaying, and renderers are rendering) until ~4:22. That's smack bang between the streaming server and TsWriter problem start times. I can't figure out why it should be that time, and not at the same time as either streaming server or TsWriter falling over. I did note with some interest during my LIVE555 update testing that TsReader seems to be able to continue playing an RTSP stream even without duration updates. On that basis I'm assuming it's more likely to be the TsWriter issue that directly causes TsReader to stop receiving data (=> freeze). However perhaps streaming server's failure to calculate durations is a symptom of a wider problem that eventually causes it to stop streaming completely. Lots of uncertainties... ;) [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Support
Watch / Listen Media
Television (MyTV frontend and TV-Server)
Locked time-shift files cause failure to change channel
Contact us
RSS
Top
Bottom