Glitching, stuttering and freezing on a handful of MKV BR rips

[GothsterC 47]

I have a problem that I just noticed recently on some files created from BRs using MakeMKV.  I have thousands of BRs and rips, so it is strange that it just happens with some.

Upon playing these files through Emby (same results on Fire TV, Android Tablet, Roku and the Web interface, but it does seem to work properly on my Android phone), the playback starts glitching especially in scenes with more movement.  Sometimes it freezes up completely.  I've done a lot of testing and it seems to happen to just a few files.  It doesn't appear to be the network, as I've played this locally using Ethernet.  I've tried reducing the bit rate and resolution and even when I take it down to the lowest 480p option, the glitching still happens.  It also appears to be behaving differently from network issues which I had in the past.

The file itself seems fine as I can play it using VLC without any issues.

I am running an up-to-date Windows server and the latest Emby.

I've attached the logs including the transcode logs which shows I tried different bitrates.  One of the movies causing problems is Sorority Row.  I did notice that the transcode log has a message: Invalid track number 7, but as far as I can tell there is no Track 7, unless it is referring to the JPEG attachment.

Thanks for any insights.

ffmpeg-transcode-0d4728f1-eba2-4820-9332-7e71f8bd5d29_1.txt ffmpeg-transcode-4ee49617-70d7-4d40-9369-2a00c7b64324_1.txt ffmpeg-transcode-36f15056-936e-460d-b29b-5d0e0a603025_1.txt embyserver (5).txt

[GothsterC 47]

Just another bit of data, I removed "Track 7" which was the JPG attachment and tried again with a very low 480p 424 kbps transcode and the same thing happened including just freezing up.

Here is the transcode log from that attempt.

 

ffmpeg-transcode-930fc1d6-ecaf-43db-91dc-028f36609938_1.txt

[Luke 39421]

Hi, are you still having an issue with this? Is this on a remote connection?

[GothsterC 47]

Yes, I am.  No, this is not on a remote connection, but on the local ethernet.

Thanks

[visproduction 243]

Goth,

The master video has multiple audio including DTS and it looks like your converter settings must be fairly high quality.  The conversion appears to try to keep up and eventually bogs down to speed= 3.36x (line 517).  I would guess that you reach a limit that conversion is too slow to play back the video.

The summary shows encoding duration 1.85 seconds conversion elapsed time 51.89 (lines 523 - 524).

1) The master video with DTS audio appears too much for your system to convert fast enough to the quality setting you have, so there is no possiblity of real time conversion.  Either you get  a) much faster server b)  hardware encoder c) make a lighter weight original file without DTS and extra audio or d) turn down your quality requirements.

These are guesses.  I don't actually use real time encoding.  I pre convert all my videos so no conversion is required.  I use AVIdemux and changing audio from AC-3 to AAC on an average notebook Win 64 takes about 20 minutes.  Then your master would not have DTS, nor AC3 and the problem would probably be solved.

Hope that helps.

 

[GothsterC 47]

Thank you.  I will ty re-encoding it to see if that helps.

[GothsterC 47]

Re-encoding doesn't help.

[visproduction 243]

Goth,

I am still guessing that your encoding settings are trying to get a quality that your server may not be able to handle when the video is larger than some file size. There are many possible problems.  That's why the log file of the playback session is important.  

A good approach is to test with a clean demo video that you download from a demo source online.  These are videos that were made professionally for a particular codec combination and should have NO internal errors.  When these videos work, then it points to your video file, or your encoder causing some problem.  When the demo fails, then you know it's probably an transcoding or server speed issue.  When you don't use demo videos, it could be either.  Demo videos help narrow down the problem.  If you post the log, I am sure, one of the guys who really knows the logs inside out, which is not me, will probably pinpoint the issue.

Just to show how many master video problems you can have, even after you supposidly did a perfect encode, look here: https://www.stellarinfo.com/article/fix-video-errors-problems.php

What's also frustrating is a program like VLC is very forgiving on errors and plays things fine, even the the video needs help.  There are helper programs like MP4Box or MkvTools that you can take a video and run a check to clean up and "Look at that!... It's fixing a video, that I thought was already okay..."

Hope that helps.

[Luke 39421]

Have you tried Edge to see how it compares with Chrome?

[GothsterC 47]

Yes, Luke, I have tried Edge with the same results.  This is strange.  If it wasn't for it working fine in VLC, I would just think I have a bad disk even though it ripped without issues.  Like Visproduction said, maybe this file is just too intensive or high-quality to transcode on my server and VLC is better at covering up issues.  However, my server is pretty good, and I have equally high-quality rips from other BRs that play without issue.  Transcoding didn't help either.  I tried re-ripping it to a different drive thinking that maybe the drive has issues but that didn't help either.  The drive scans fine as well.  The only way I can know for sure is to go out and rebuy the BRs and try again but would rather not do that.

I just wanted to put this out there in case there is something you can find in the logs that could help improve Emby.   I am willing to perform tests and send you the logs.  Just let me know.

Thanks.

 

[Luke 39421]

As a test, if you turn off hardware transcoding in server transcoding settings, how does that compare?

[GothsterC 47]

Same results unfortunately.

[rbjtech 4888]

#1 Does this BR have multiple 'cuts or editions' on one disk - ie it has seemless branching on the original BR ?

#2 Is the VLC playback 'streaming' the media the same as Emby would be (ie you have chosen to use VLC as a 3rd party playback in emby and emby initiates the use of VLC) - or do you mean you are opening VLC, navigating to the file and then it plays it back ?   They are very different playback methods - so it's key we understand which one you are referring to. 

All indicators suggest this is something the emby client cannot handle in the file itself -  especially if it always fails in exactly the same spot on a specific file.

Tks.

[GothsterC 47]

To rbjtech, #1, no multiple editions as far as I can tell.  Here is one of the discs I am having problems with:  Sorority Row Blu-ray.

#2, I have compared using VLC outside of Emby which works.  When I play using Emby it fails on Amazon Fire TV, Roku TV box, TV with Roku built-in, Android phone app and on various web browsers on Windows.  Yes, it always glitches in the same place and the same manner.  I've not tried using Emby with VLC.

I have found 3 original BR rips with this problem so far.  However, 100s of others have no issue.

Strange.

[rbjtech 4888]

32 minutes ago, GothsterC said:

  Yes, it always glitches in the same place and the same manner. 

ok - so the fact it stalls in the same place is good. 

In mkvtoolnix - drag the mkv to it, change the output file to test.mkv, then go into output and create a 5-10 second using the hh:mm:ss in the 'Parts' section covering where the issue happens. (see example below)

This will then create a small snippet of the MKV.

If this snippet has the same issue (which it should) then this can be used to further investigate - and be sent onto Luke et all (and me if you like) to try and re-produce the issue.

Edited October 18, 2023 by rbjtech

[GothsterC 47]

This is strange.  I made several snippets.  It's still messing up but in a different manner.  Before it was glitching like skipping ahead like a scratched vinyl.  With the snippet, it plays mostly okay, but I am getting green/purple blocks at the top occasionally.

Sorority Row [2009] - HD (1).mkv

[rbjtech 4888]

Looks like a corrupt file - lots of glitches even in the above snippet with Windows Media Player - but as you say, plays back perfectly in VLC and AVIdemux (but evidence of corrupt frames if you go a frame at a time @ the 12 second mark.

At least emby can take a look, but I suspect its authoring issues on the BR itself - and VLC is managing to error correct them, other players are not.

Edited October 18, 2023 by rbjtech

[GothsterC 47]

Thanks.  That is probably the most logical explanation.  Looks to be a re-buy.  Time for some new disks.  That's sometimes the problem when you buy used, but Makemkv seems to fail if there is any error at all, so that is why I'm surprised.

  Any way that Emby can manage the play as good as VLC?  You said something about using VLC as a third-party player within Emby?

Thanks

[rbjtech 4888]

Just now, GothsterC said:

  Any way that Emby can manage the play as good as VLC?  You said something about using VLC as a third-party player within Emby?

Yea on AndroidTV, you can specify to use a 3rd party player - so choose VLC if you have it installed, but you do lose all the emby UI while in playback mode (you get VLC's instead).    Not sure about clients I'm afraid as that's all I use.

[Mashster 0]

I tried using Handbrake to reduce the file size of the ripped files. It worked on some

[GothsterC 47]

It's been a long time, but I finally found a solution.  I simply used MKVToolNix GUI to re-encode the MKV.  I didn't have to exclude any tracks.  I just ran that over the existing MKV and it fixed all of the errors and the resulting file works perfectly.

[created1ders 0]

I'm having this same problem with The Mindy Project television shows. I have zero problems with any other mkv in my libraries. I downloaded the software you mentioned but how do use it like you did?

[pwhodges 1801]

Drop the video file on the window and press the Start Multiplexing button.

Paul

[Carlo 4535]

22 hours ago, pwhodges said:

Drop the video file on the window and press the Start Multiplexing button.

Paul

Doesn't get much easier than that!