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)
Continuity error... in tswriter.log
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: 1221395" data-attributes="member: 82144"><p>[USER=130239]@mike1[/USER]</p><p>Thanks again for allowing me to connect to your server. I have some information to report already...! <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin :D" loading="lazy" data-shortname=":D" /></p><p></p><p>Thanks to the TS dump and log files that I captured, I was able to see when/why TV Server is reporting the continuity error. Here's the technical explanation for [USER=83973]@Owlsroost[/USER] and anybody else who is interested.</p><p></p><p>First, an example sequence of packets that cause TsWriter to log a continuity error.</p><p><strong>packet #1</strong></p><p>47 00 FF 1C ... (the rest doesn't matter)</p><p></p><p><strong>packet #2</strong></p><p>47 00 FF BD B6 00 ... (0xb5 / 181 bytes of padding FF) ... <strong>00</strong></p><p><strong></strong></p><p><strong>packet #3</strong></p><p>47 40 FF 1E 00 00 01 ... (the rest doesn't matter)</p><p></p><p>TsWriter thinks packet #2 is missing. Why?</p><p>If you check the continuity counter values (C => D => E) there's no gap. However the transport_scrambling_control and adaptation_field_control field values [for packet #2] are 01b (=> user defined ==> interpreted by TsWriter as meaning "scrambled/encrypted") and 11b (=> adaptation field followed by payload) respectively. That combination causes TsWriter to drop the packet in the pre-processing code. The justification for doing that is that packets which contain encrypted payload won't be able to be processed by decoders. In my opinion that's reasonable.</p><p></p><p>The things that strike me as odd/important about this sequence are:</p><ol> <li data-xf-list-type="ol">That packet #2 only contains one payload byte. Note the value of that byte is 00 in this case, but from other sited examples it seems that byte can take other values.</li> <li data-xf-list-type="ol">That the CAM has not marked packet #2 as unscrambled/non-encrypted as it does for [almost] all other packets in the stream.</li> <li data-xf-list-type="ol">That [TS] packet #3 starts with a new PES packet (0 0 1...).</li> </ol><p>My best guess is that the last byte in packet #2 is not true payload content. For example it could be part of a CRC or other PES/ES packet trailer field. If that's true, a CAM may determine that it doesn't need to decrypt that part of the "payload", and so neglect to mark the TS packet as unscrambled/non-encrypted. Such an explanation would represent an unfortunate but somewhat understandable CAM firmware bug. Unfortunately TsWriter has no way to workaround such bugs because it doesn't parse the contents of PES or ES packets (...and nor should it have to in my opinion).</p><p></p><p>The question that comes to my mind is: if that single byte is not true payload (by which I mean: not required for correct video/audio/subtitles/<whatever> decoding), why does playback stutter?</p><p>My first assumption would've been that the dropping of a packet containing a non-critical byte and the logging of a continuity error wouldn't cause a problem for the decoding chain. However, perhaps I'm wrong. I can think of at least two plausible explanations for how/why I might be wrong:</p><ol> <li data-xf-list-type="ol">If continuity error triggers flushing or other resync-type coping mechanisms in TsReader, streaming server or codecs. This would obviously cause an observable playback glitch.</li> <li data-xf-list-type="ol">If the logging [of the continuity error] itself causes the playback glitch. We've seen this sort of thing before when over-zealous security software is scanning the log folders.</li> </ol><p></p><p>Does this explanation make any sense to you Owlsroost?</p><p>Any thoughts about whether TsReader might be flushing?</p><p></p><p></p><p>[USER=130239]@mike1[/USER] </p><p>About the second possible cause (logging)...</p><p>I remember seeing your Windows Defender configuration excludes the MP and TV Server processes + time-shift and recording folders from scanning. However I don't think the log folders were excluded. I know we reproduced the problem with Windows Defender disabled. Nevertheless, please can you try to exclude the log folders from scanning too.</p></blockquote><p></p>
[QUOTE="mm1352000, post: 1221395, member: 82144"] [USER=130239]@mike1[/USER] Thanks again for allowing me to connect to your server. I have some information to report already...! :D Thanks to the TS dump and log files that I captured, I was able to see when/why TV Server is reporting the continuity error. Here's the technical explanation for [USER=83973]@Owlsroost[/USER] and anybody else who is interested. First, an example sequence of packets that cause TsWriter to log a continuity error. [B]packet #1[/B] 47 00 FF 1C ... (the rest doesn't matter) [B]packet #2[/B] 47 00 FF BD B6 00 ... (0xb5 / 181 bytes of padding FF) ... [B]00 packet #3[/B] 47 40 FF 1E 00 00 01 ... (the rest doesn't matter) TsWriter thinks packet #2 is missing. Why? If you check the continuity counter values (C => D => E) there's no gap. However the transport_scrambling_control and adaptation_field_control field values [for packet #2] are 01b (=> user defined ==> interpreted by TsWriter as meaning "scrambled/encrypted") and 11b (=> adaptation field followed by payload) respectively. That combination causes TsWriter to drop the packet in the pre-processing code. The justification for doing that is that packets which contain encrypted payload won't be able to be processed by decoders. In my opinion that's reasonable. The things that strike me as odd/important about this sequence are: [LIST=1] [*]That packet #2 only contains one payload byte. Note the value of that byte is 00 in this case, but from other sited examples it seems that byte can take other values. [*]That the CAM has not marked packet #2 as unscrambled/non-encrypted as it does for [almost] all other packets in the stream. [*]That [TS] packet #3 starts with a new PES packet (0 0 1...). [/LIST] My best guess is that the last byte in packet #2 is not true payload content. For example it could be part of a CRC or other PES/ES packet trailer field. If that's true, a CAM may determine that it doesn't need to decrypt that part of the "payload", and so neglect to mark the TS packet as unscrambled/non-encrypted. Such an explanation would represent an unfortunate but somewhat understandable CAM firmware bug. Unfortunately TsWriter has no way to workaround such bugs because it doesn't parse the contents of PES or ES packets (...and nor should it have to in my opinion). The question that comes to my mind is: if that single byte is not true payload (by which I mean: not required for correct video/audio/subtitles/<whatever> decoding), why does playback stutter? My first assumption would've been that the dropping of a packet containing a non-critical byte and the logging of a continuity error wouldn't cause a problem for the decoding chain. However, perhaps I'm wrong. I can think of at least two plausible explanations for how/why I might be wrong: [LIST=1] [*]If continuity error triggers flushing or other resync-type coping mechanisms in TsReader, streaming server or codecs. This would obviously cause an observable playback glitch. [*]If the logging [of the continuity error] itself causes the playback glitch. We've seen this sort of thing before when over-zealous security software is scanning the log folders. [/LIST] Does this explanation make any sense to you Owlsroost? Any thoughts about whether TsReader might be flushing? [USER=130239]@mike1[/USER] About the second possible cause (logging)... I remember seeing your Windows Defender configuration excludes the MP and TV Server processes + time-shift and recording folders from scanning. However I don't think the log folders were excluded. I know we reproduced the problem with Windows Defender disabled. Nevertheless, please can you try to exclude the log folders from scanning too. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Support
Watch / Listen Media
Television (MyTV frontend and TV-Server)
Continuity error... in tswriter.log
Contact us
RSS
Top
Bottom