Stutter when playing movie via recorded TV, but not if watched via Videos (1 Viewer)

Bernie_W

Portal Member
May 16, 2016
26
6
Home Country
Germany Germany
Hi,

I have some strange effect with Mediaportal 1.17.
I recorded a TV movie that was in HD. It is stored on a media server and the client is accessing this .TS file via GB network.

Now, if I watch this recorded movie via the TV section using "Recorded TV" the movie stutters and jumps like hell. But if I watch the same movie via the "Videos" section, all runs smooth. So it is certainly not the network speed or the graphics/CPU performance.
All the other settings are the default ones as I didn't touch them.

I also set the flag to use video codecs for TV (actually all codecs are set to LAV). Of course I tried to change the splitter and other codecs but the phenomenon persists.

Any idea where to look further into details to solve this?

Thanks

PS: No other codecs installed (fresh WIN 10 installation) and no extensions installed.
 

Bernie_W

Portal Member
May 16, 2016
26
6
Home Country
Germany Germany
No, not without access to log files.

Hi and thanks, and a big sorry for my late reply.

I checked the TSReader.log shortly and there are entries appearing after a short while - i.e. when the stuttering starts - that says "Demux : Video to render too late"

What I did:
I removed all logs and then started the play of the recording using the TV portion of MP, where stuttering started. After a couple of seconds, I ran the same recording via the Video portion that showed no stutter. So both should be part of the log files, if I didn't do anything wrong.

And many thanks in advance for helping me with this.
 

mm1352000

Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    Thanks for the log files Bernie (y)

    They show that despite what you said about your codec settings, MP is not using the LAV video codec when playing the recording via the recorded TV section:
    [2017-09-17 18:26:02,907] [Log ] [MPMain ] [DEBUG] - Check graph connections for: Enhanced Video Renderer
    [2017-09-17 18:26:02,908] [Log ] [MPMain ] [DEBUG] - Check graph connections for: Default DirectSound Device
    [2017-09-17 18:26:02,908] [Log ] [MPMain ] [DEBUG] - Check graph connections for: MediaPortal AudioSwitcher
    [2017-09-17 18:26:02,908] [Log ] [MPMain ] [DEBUG] - Check graph connections for: Microsoft DTV-DVD Video Decoder
    [2017-09-17 18:26:02,909] [Log ] [MPMain ] [DEBUG] - Check graph connections for: LAV Audio Decoder
    [2017-09-17 18:26:02,909] [Log ] [MPMain ] [DEBUG] - Check graph connections for: TsReader

    On the other hand, MP is using the LAV video codec when playing the recording from the videos section:
    [2017-09-17 18:26:56,414] [Log ] [MPMain ] [DEBUG] - Check graph connections for: Default DirectSound Device
    [2017-09-17 18:26:56,414] [Log ] [MPMain ] [DEBUG] - Check graph connections for: Enhanced Video Renderer
    [2017-09-17 18:26:56,414] [Log ] [MPMain ] [DEBUG] - Check graph connections for: LAV Video Decoder
    [2017-09-17 18:26:56,414] [Log ] [MPMain ] [DEBUG] - Check graph connections for: LAV Audio Decoder
    [2017-09-17 18:26:56,415] [Log ] [MPMain ] [DEBUG] - Check graph connections for: \\SERVER\D Server\recorded tv\Twins - Zwillinge.ts

    This fact may fully or partially explain what you're seeing.

    Please attach screenshots of your LAV video codec settings.
     

    Bernie_W

    Portal Member
    May 16, 2016
    26
    6
    Home Country
    Germany Germany
    Thanks for the log files Bernie (y)

    They show that despite what you said about your codec settings, MP is not using the LAV video codec when playing the recording via the recorded TV section:
    [2017-09-17 18:26:02,907] [Log ] [MPMain ] [DEBUG] - Check graph connections for: Enhanced Video Renderer
    [2017-09-17 18:26:02,908] [Log ] [MPMain ] [DEBUG] - Check graph connections for: Default DirectSound Device
    [2017-09-17 18:26:02,908] [Log ] [MPMain ] [DEBUG] - Check graph connections for: MediaPortal AudioSwitcher
    [2017-09-17 18:26:02,908] [Log ] [MPMain ] [DEBUG] - Check graph connections for: Microsoft DTV-DVD Video Decoder
    [2017-09-17 18:26:02,909] [Log ] [MPMain ] [DEBUG] - Check graph connections for: LAV Audio Decoder
    [2017-09-17 18:26:02,909] [Log ] [MPMain ] [DEBUG] - Check graph connections for: TsReader

    On the other hand, MP is using the LAV video codec when playing the recording from the videos section:
    [2017-09-17 18:26:56,414] [Log ] [MPMain ] [DEBUG] - Check graph connections for: Default DirectSound Device
    [2017-09-17 18:26:56,414] [Log ] [MPMain ] [DEBUG] - Check graph connections for: Enhanced Video Renderer
    [2017-09-17 18:26:56,414] [Log ] [MPMain ] [DEBUG] - Check graph connections for: LAV Video Decoder
    [2017-09-17 18:26:56,414] [Log ] [MPMain ] [DEBUG] - Check graph connections for: LAV Audio Decoder
    [2017-09-17 18:26:56,415] [Log ] [MPMain ] [DEBUG] - Check graph connections for: \\SERVER\D Server\recorded tv\Twins - Zwillinge.ts

    This fact may fully or partially explain what you're seeing.

    Please attach screenshots of your LAV video codec settings.


    Hi MM,

    thanks for your reply in nano-seconds :)

    Actually I didn't change the settings or the codecs as such, so it is really interesting that the LAV filters seem not to be in use. Which means I am totally lost now.

    Please find the image attached. Hope it is readable. Clipboard01.jpg

    Many thanks in advance for your kind help.
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    You ought to:
    • select "DXVA2 (native)" for the "hardware decoder to use" setting
    • untick the UHD resolution (your HD 5450 GPU doesn't support it)
    • untick the HEVC codec for HW decoding (your HD 5450 GPU doesn't support it)
    I think that should be a good start. If the problem persists, please provide new log files.
     

    Bernie_W

    Portal Member
    May 16, 2016
    26
    6
    Home Country
    Germany Germany
    You ought to:
    • select "DXVA2 (native)" for the "hardware decoder to use" setting
    • untick the UHD resolution (your HD 5450 GPU doesn't support it)
    • untick the HEVC codec for HW decoding (your HD 5450 GPU doesn't support it)
    I think that should be a good start. If the problem persists, please provide new log files.


    Hi and thanks again,

    indeed a good start as I think the stuttering has reduced. I also added the LAV filter again via the Media Portal Extension manager, as I thought they might be of newer date.

    I attached the new log-files, this time just playing the recording in the TV section of MP.

    I still wonder why there is no stuttering, when I watch the recording through the Video section of MP instead of the TV section. Shouldn't both use the same set of codecs? Might be a stupid question.

    Truly thanks for your kind help.

    PS: I am sorry, forgot to mention that I took this log being remotely logged in via RDP, but having a wired GBit LAN. The difference of having stutter using TV and no stutter using Video was still clearly visible.
     
    Last edited:

    mm1352000

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

    I still wonder why there is no stuttering, when I watch the recording through the Video section of MP instead of the TV section. Shouldn't both use the same set of codecs? Might be a stupid question.
    There's more to playback than codecs.

    For example, the video section uses the LAV splitter and accesses the recording via UNC path (SMB share), whereas the TV section uses our TsReader splitter and streams the recording via RTSP/RTP.


    Several points come to mind when I look at your log files:
    • Your HD-5450 GPU is barely capable of hardware-accelerated full HD h.264 video decoding with good quality deinterlacing
    • Your display refresh rate - 32 Hz - is highly highly unusual. You should expect dropped frames given that you haven't enabled the refresh rate changer and the video frame/field rate is 50 Hz.
    • The recording doesn't appear to have been created by MediaPortal's TV Server.
    • The "video to render too late" and "audio to render too late" messages you see in the TsReader log suggest either timing issues (eg. the refresh rate stuff I mentioned), streaming/bufferring issues (eg. variable network latency or insufficient buffer size) or decoding issues (eg. GPU or CPU overloaded).
    In summary, I'm not sure whether the issue is caused by:
    • a fundamental incompatibility between the recording source/encoder and our TS splitter (TsReader)
    • a network issue (eg. a bad NIC driver, or a bad wireless link somewhere in the chain between the machine that hosts the file and the machine that plays it)
    • a decoding issue (eg. non-optimal GPU/codec config, or CPU/GPU overload due to over-zealous security software scanning)
    • etc. etc. etc.
    Extra info about the source of the recording, the network chain between the host and playback machines, and the unusual display refresh rate would be helpful.

    Also, I suggest you use task manager to check the CPU load while viewing the recording to help determine whether it's overloaded.
     

    Bernie_W

    Portal Member
    May 16, 2016
    26
    6
    Home Country
    Germany Germany
    Hello again


    There's more to playback than codecs.

    For example, the video section uses the LAV splitter and accesses the recording via UNC path (SMB share), whereas the TV section uses our TsReader splitter and streams the recording via RTSP/RTP.


    Several points come to mind when I look at your log files:
    • Your HD-5450 GPU is barely capable of hardware-accelerated full HD h.264 video decoding with good quality deinterlacing
    • Your display refresh rate - 32 Hz - is highly highly unusual. You should expect dropped frames given that you haven't enabled the refresh rate changer and the video frame/field rate is 50 Hz.
    • The recording doesn't appear to have been created by MediaPortal's TV Server.
    • The "video to render too late" and "audio to render too late" messages you see in the TsReader log suggest either timing issues (eg. the refresh rate stuff I mentioned), streaming/bufferring issues (eg. variable network latency or insufficient buffer size) or decoding issues (eg. GPU or CPU overloaded).
    In summary, I'm not sure whether the issue is caused by:
    • a fundamental incompatibility between the recording source/encoder and our TS splitter (TsReader)
    • a network issue (eg. a bad NIC driver, or a bad wireless link somewhere in the chain between the machine that hosts the file and the machine that plays it)
    • a decoding issue (eg. non-optimal GPU/codec config, or CPU/GPU overload due to over-zealous security software scanning)
    • etc. etc. etc.
    Extra info about the source of the recording, the network chain between the host and playback machines, and the unusual display refresh rate would be helpful.

    Also, I suggest you use task manager to check the CPU load while viewing the recording to help determine whether it's overloaded.

    ---------------------------------------------------
    Hi MM1352000,

    thanks for sharing your experience. Very interesting.
    Well I did a couple of additional tests shortly described:

    What I tested in addition: On the client where the logs are from seems not to be under a heavy load. It is a Phenom II X6 and the task manager showed a maximum of 30% CPU load and the stream used in average around 5Mbit/s of the Gigabit line.

    Then I setup another client on a quite strong machine with a I5 Skylake and a dedicated Nvidia GT950. This PC also has wired GBit LAN and 32GB memory. I did this just to make sure, there is no limitation in the network or the HW. And unfortunately the effect is the same. Btw there is only a GBit switch between the client and the server, no router and no NAT/Firewall. Same stutter.

    Third test was then using the Android mobile (Wifi) using Ampdroid playing the same recording of course and no stutter there. I chose FFMpeg HQ as profile there. And interestingly, no stutter there. My - possibly wrong - assumption for doing this test is to see if the server has enough power, as the server compresses the video. It is just an I3 Skylake with 32GB Ram and GBit LAN and SSD,

    And another test then was to play the recording on the server directly (connected to a TV) through the TV section. As expected all was smooth and no stutter. The two clients and the server are all running MP 1.17. And the Server uses a Ramdisk for timeshifting.

    Finally this leads me somehow to the assumption that there is something wrong with the recording itself.

    Maybe then a word to the recordings. The recordings are all done via MP. But I use comskip and MCEBuddy to strip the commercials. But I do not re-encode and just use TS Uncompressed in MCEBuddy. But I know also that .ts is quite sensible concerning those tools.

    Next test will then be to do a HD recording, not using MCEBuddy and Comskip to see if there is an effect.

    Again many thanks, I think you narrowed down the whole issue with your observations and your knowledge. I will post what the outcome is. Of course if you have any further ideas for a test or any assumptions, I am more than happy to listen and learn.

    Thanks.
     

    Bernie_W

    Portal Member
    May 16, 2016
    26
    6
    Home Country
    Germany Germany
    Alright, here comes the update.

    I did a new recording of a HD stream and watched it on the client without MCEbuddy used. Worked fine, no stutter. Then ran MCEBuddy and it also worked fine :)
    That puzzled me a bit.
    So I checked the TV cards for discontinuities, but there were none.

    Actually - to whatever reason - a couple of recent recordings seem to be corrupted. Could have been Windows and the never-ending updates. Or a possible temporary driver issue, temporary USB issue or just a weak signal for some time. In other words, not really a chance to find the culprit. I will check on some upcoming recordings and see, if it starts again and if so, if there is some kind of pattern.

    So I would start watching the issue and if you allow - just in case it should start again - drop another post here.

    Anyhow, many thanks for guiding me in this matter and sharing your experience.
     

    Users who are viewing this thread

    Top Bottom