1.14.0 Micro stutter on one particular channel during LIVE TV (Solved because: Probably hardware related) (1 Viewer)

Damandan

Portal Pro
May 19, 2007
111
12
39
Tegelen
Home Country
Netherlands Netherlands
MediaPortal Version: 1.13.0

Description
When watching Veronica HD using MediaPortal 1.13, but also the earlier versions, I get small hickups in the video (not audio) which only occur during LIVE TV playback.
When I have a simultaneous recording of that same channel at the same time, the recording is fine!

I believe this rules out problems on the signal quality side of things, but I am running fast out of options of what could cause this problem other then some sort of error on the TsReader side of things...

Hope you guys can help.

What I have tried so far:

1. Move Live TV folder from networkdrive back to HDD. --> Problem persists
2. Move LIVE TV folder from HDD to SSD. --> Problem persists
3, Use different codecs, while still using SSD as Timeshift folder. --> Problem persists
4. Change Power Options and disable throttling of CPU. --> Problem persists

I have now reverted back to the original situation, All buffers are now saved over the network to my NAS. I have yet to find another channel which has the same problems.

Maybe the logs can point anyone in the right direction.
(Recording is in there aswell. Live TV showed a hickup at around the 45 seconds mark...but recording is fine at that point.)

Thanks in advance, Damandan

Steps to Reproduce:
Watch Veronica HD via Ziggo cable provider.
 
Last edited:

mm1352000

Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    Hello Damandan

    Can you please provide a separate attachment of only the log files (without the recording)? I'm on a limited internet data cap...
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    No problem. Done!
    Thanks.
    I'm very sorry to say that unfortunately the TV Server log level is set to "warning". Therefore I can see almost nothing in the TV service log. Please can you change the log level to "debug", reproduce the problem again, then provide new log files. Again, I'm sorry to have to ask you to do this, but I'm not able to help without the debug level log files...
     

    Damandan

    Portal Pro
    May 19, 2007
    111
    12
    39
    Tegelen
    Home Country
    Netherlands Netherlands
    Again, no problem. I'm just glad that someone is spending their free time looking into this. I have stopped the stream a few seconds after the problem occurred again.
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    Thank you for your understanding. :)

    It looks like there could be a combination of causes here.

    In the earlier log files there are:
    1. Continuity errors in the TsWriter log file. In other words, the stream that TV Server was receiving was already missing parts. Continuity errors are usually caused by signal strength/quality or storage access speed (eg. too high latency) issues. In your case it is also possible that they might be caused by decryption issues. These are direct causes of stutter, pixellation etc.
    2. A PCR (program clock reference) jump in the TsWriter log file. In my experience these are relatively rare. They may or may not indicate that the channel provider is not encoding the timings for the channel properly. Failure to encode timing properly can result in decoding problems such as the micro-stutter that you described.
    3. Late video/audio errors in the TsReader log file. These are direct indicators of micro-stutter and could be connected to (2) and (4).
    4. Late samples and dropped frames in the EVR log file. These are direct indicators of micro-stutter and could be connected to (2) and (3).
    In the latest log files there are no issues in the TsWriter log, but still:
    1. "PES 0-0-1" errors in the TsReader log file. These indicate that parts of the stream were sometimes still encrypted when they reached TsReader. This may or may not be a problem.
    2. A late audio error in the TsReader log file. As above: this is a direct indicator of micro-stutter.
    3. Late samples and dropped frames in the EVR log file. As above: this is a direct indicator of micro-stutter.

    So, how to solve the problem?

    First, I would strongly recommend to untick "single seat setup: force RTSP usage" in MP Configuration -> TV/radio -> advanced options as shown here:
    http://wiki.team-mediaportal.com/1_...iaPortal_Configuration/22_TV/Advanced_Options

    I can't think of any reason why you'd want to enable that option. Most likely it can only cause problems for you by unnecessarily increasing traffic through the network interface/stack.

    Second, if the above change doesn't help, I'd recommend to increase the TsReader "BufferingDelayInMilliSeconds" setting in the registry (HKEY_CURRENT_USER\Software\Team MediaPortal\TsReader). Overriding that value can help with the late video/audio samples indicated by the TsReader and EVR log files.

    Finally, despite what you said, I would recommend to avoid using NAS for time-shifting (or recording) if possible. I know that you said that there was no difference between using the NAS and SSD, but if there are multiple causes for the micro-stutter (as I suspect) then you wouldn't have seen any difference until you eliminated the other causes as well.


    Please don't hesitate to ask if any of the above information or recommendations are not clear. :)
     

    Damandan

    Portal Pro
    May 19, 2007
    111
    12
    39
    Tegelen
    Home Country
    Netherlands Netherlands
    Ok, thanks so far. I will try these suggestions as soon as I get the time and will post back here if they had any positive result.
     

    Damandan

    Portal Pro
    May 19, 2007
    111
    12
    39
    Tegelen
    Home Country
    Netherlands Netherlands
    I am sorry to say that all of the suggestions above did not work yet.

    I have changed the timeshiftbuffer location to a local HDD so the network latency is eliminated.
    localHDDTimeshiftBuffer.png

    I have changed the mentioned TSReader registry key to a higher value (5000) which also did not result in a noticeable change of behaviour.
    HighBufferDelay.png
    I restarted the PC to make sure the settings were active. (Didn't know if the settings were cached somehow.)
    I also disabled the single seat option in the advanced options menu.

    I then even increased the waiting time for descrambling on the tv server
    WaitLongerForDescramble.png

    I then started timeshifting from the TvServer configuration.
    I saw then that there where some discontinuity errors and moved the timeshift folder to the SSD instead of the local HDD.

    That removed the continuity errors. (Maybe the HDD is overused since I have MySQLs databases on that disk.)
    However, the hickups during live tv still persist. New logs attached.
    Any other suggestions?

    Thanks, Damandan

    Additional information: I let the TV Server timeshift Veronica HD for about 10 minutes. Still no discontinuities after 10 minutes. I think this proofs that cabling and signal quality are OK, but that something else is causing the problem.
    CablesOK.png
     
    Last edited:

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    Okay, let's go point by point... :)

    I have changed the timeshiftbuffer location to a local HDD so the network latency is eliminated.
    Logs confirm - thanks.

    I have changed the mentioned TSReader registry key to a higher value (5000) which also did not result in a noticeable change of behaviour.
    This change was not successful. The log is saying:
    [2016-01-02 13:26:46,984] [11dc02e0] [1aa4] - --- Buffering delay = 0 ms (default value, allowed range is 0 - 10000)

    ...which means that the default value is being used.
    The problem is that you have specified the value as hexidecimal (base 16). As you can see in your screenshot, 0x5000 means 20480. 20480 is outside the allowed range (0 - 10000).
    Please try this one again. :)

    I also disabled the single seat option in the advanced options menu.
    Logs confirm - thanks.

    I then even increased the waiting time for descrambling on the tv server
    Sorry, that won't make any difference for this problem.

    I then started timeshifting from the TvServer configuration.
    I saw then that there where some discontinuity errors and moved the timeshift folder to the SSD instead of the local HDD.

    That removed the continuity errors. (Maybe the HDD is overused since I have MySQLs databases on that disk.)
    You could use Windows task manager -> resource monitor if you want to know which processes are using the HDD most.
    It might also be a good idea to check DPC latency with LatencyMon.

    [edit: ...but to be clear, I think for now it's best to stay with the SSD if it's the only option that guarantees zero TsWriter continuity errors. Once the problem is solved then you could consider moving the TS folder to another location.]

    However, the hickups during live tv still persist. New logs attached.
    Any other suggestions?
    In short: no.
    In these logs I don't see any issues in the TsWriter log.
    The TsReader log still contains:
    • ..."PES 0-0-1 fail" messages, but for now I'm not too fussed about them because they're only at the start of the timeshifting (therefore they could be normal).
    • ...one "audio to render late" message, which should hopefully be solved when you increase the buffer size properly.
    So for now the most important thing to try is the TsReader buffer setting.
     
    Last edited:

    Damandan

    Portal Pro
    May 19, 2007
    111
    12
    39
    Tegelen
    Home Country
    Netherlands Netherlands
    Unfortunately, the problem still exists even when the correct changes in the registry have been made. (Set the value to 9999, and the logs reflect that change)
    I will have a go at the latencyMon to see if that could shine some light on what the h is going on.

    Thank you for your help.

    Edit: The latency tool points to MtsBda as being the driver with the highest DPC latency. It just so happens to be my TV-Tuner card driver, so I am going to try some other driverversions to see if these help solve the problem.
     
    Last edited:

    Users who are viewing this thread

    Top Bottom