Continuity error... in tswriter.log (1 Viewer)

me1

Portal Pro
March 21, 2008
73
2
Home Country
Germany Germany
I am in weekend;-) When would be a good time for you?
 

mike1

MP Donator
  • Premium Supporter
  • September 7, 2012
    88
    8
    58
    Home Country
    Germany Germany
    Sorry for the delay...
    Would it be possible today or tomorrow evening for you?
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    Yes, I could do it now. I'll be available off and on for the next 12 hours or so.
     

    mike1

    MP Donator
  • Premium Supporter
  • September 7, 2012
    88
    8
    58
    Home Country
    Germany Germany
    You are nearly exact at the other side of the world ;-)
    May be i have a chance tomorrow morning - my time;) So in about 12 hours...
    Are you able to send mail to me - can you see my address?
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    You are nearly exact at the other side of the world ;-)
    Yup, New Zealand is GMT+12.

    May be i have a chance tomorrow morning - my time;) So in about 12 hours...
    ...which is this evening for me. :D
    Yes, I should be available for awhile.

    Are you able to send mail to me - can you see my address?
    No I can't see your address. Only admins could check that kind of stuff. We respect privacy. :)
    I'll send you a private message...
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    @mike1
    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 @Owlsroost and anybody else who is interested.

    First, an example sequence of packets that cause TsWriter to log a continuity error.
    packet #1
    47 00 FF 1C ... (the rest doesn't matter)

    packet #2
    47 00 FF BD B6 00 ... (0xb5 / 181 bytes of padding FF) ... 00

    packet #3

    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:
    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.
    2. That the CAM has not marked packet #2 as unscrambled/non-encrypted as it does for [almost] all other packets in the stream.
    3. That [TS] packet #3 starts with a new PES packet (0 0 1...).
    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:
    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.
    2. 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.

    Does this explanation make any sense to you Owlsroost?
    Any thoughts about whether TsReader might be flushing?


    @mike1
    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.
     

    mike1

    MP Donator
  • Premium Supporter
  • September 7, 2012
    88
    8
    58
    Home Country
    Germany Germany
    :)

    Log files were exlude as file type - nevertheless exluded the Folders -> no change...

    ... in case that the problem is based on a CAM Firmware bug -> my "normal" sony tv and also the DD program and DVB Viewer seem to have found a way around...
     

    mike1

    MP Donator
  • Premium Supporter
  • September 7, 2012
    88
    8
    58
    Home Country
    Germany Germany
    Ahh - that is the latest - it is the only one that is able to decrypt that channels...
     

    Users who are viewing this thread

    Top Bottom