Playback Freeze shortly after fast forward (UHD MKV mux)

[VJzenzub 2]

Taking a guess at the attached log, it looks like my system got into some sort of infinite loop of transcoding failure. Please correct me if I am mistaken, as I'm very much a novice with this. I don't know if Emby has anything to do with the issue, but this is my first couple weeks using Emby Server, streaming in this case to a Sony with Android TV for the Emby client side. The file in question is an mkv I muxed to bring together the 2 parts of an LOTR UHD movie. The same issue is present with each combined mkv for each of the 3 movies in the trilogy, so it may be I should just avoid this mux business and stick with the separate files, though I have verified my mux job was done properly. Strange part is, the files so far appear to operate fine if I avoid fast forwarding, odd as that is. That leads me to think there is something else afoot. 

If anyone can spare some wisdom or analysis, it'd be greatly appreciated. 

ffmpeg-transcode-6c77b59d-7b1e-448d-8050-e926cd0c3a5e_1.txt

[Carlo 4331]

Looking at your log file, the media itself has a lot of issues.

My question to you would be if you have issues with other media?

[VJzenzub 2]

@cayarsThanks for taking a look. No, I only recently ripped 4k content and all those files have been absolutely fine. If these logs just confirm something is wrong with my use of MKVToolNix to append 2 parts of a film together, that's good to know. It's not a show stopper if that's all that's going on here and I'll be glad to be sure the server to client part is A ok. 

Only other issue I've had with playback has been 3 MPEG2 files on a Roku 1 (which does not support MPEG2) , so I converted to MP4 but they still won't play on that Roku 1 device. Probably something faulty with the conversion. I can live with that not working; it's not a big deal. 

[VJzenzub 2]

@cayarsTried with just the native ripped .mkv files this time. No joining/appending or any of that. Title of the film is Fellowship of the Ring. Still experienced the freeze upon fast forward. I've sent a log from the Emby Android TV client app around 6:15 EST, and here are the attached logs from the server, including my last hardware detection.

I can see in that particular log, among other things, "error initializing an MFX session." I had no idea what that means, but I searched around the forum here, and per this old thread, it looks like the transcoding just isn't happening like it should. Forgive me if I am barking up the wrong tree; just trying to do some leg work to help fix this. Any advice on where to go from here would be appreciated. I might be about out of ideas myself.

P.S. I'll note that no errors whatsoever occurred during the rip with this or any other of my handful of 4k discs, so it doesn't look like the problem is with the media itself. As for the server, transcoding thread count is set to auto and the H264 CRF is 23 for what that's worth. Thanks again for working with me on this.

ffmpeg-transcode-09faff37-b3c6-408e-a540-0a22c63d8725_1.txt ffmpeg-transcode-134ef7d3-c7d1-41d4-a6eb-3f2978dcd93d_1.txt ffmpeg-transcode-c32a04df-551e-46e1-91a7-93209c13e277_1.txt ffmpeg-transcode-cd39f948-7640-4c8f-bbc8-c70af4cfd69c_1.txt ffmpeg-transcode-efa31b38-683e-43a0-85e0-9fd768089190_1.txt hardware_detection-63758686322.txt

Edited June 7, 2021 by VJzenzub

[Carlo 4331]

Some of these files are converting at under 1% real-time and I do see an error in one "[AVHWFramesContext @ 00000189cea8aec0] Could not create the staging texture (887a0005)" where the conversion is aborted.

Let's see if @softworkz has any good info to add.

[rbjtech 4333]

I have never had great success merging the LOTR remux's via MKVToolNix - it seems to screw up the timing and as a consequence, your ff/rw doesn't work as you have found out.

On the 1080p versions I successfully managed to do it by demuxing the streams using EAC3TO, then merging the streams using ffmpeg and then remuxing back together again using MKvtoolnix.

For the 4K extended remux however, I didn't bother as frankly nobody is going to watch a 6hr film without a break anyway so I left them as two parts..   

I just used the multi-resolution 'feature' to name then Part 1 and Part 2 and you just select the part you want to play (to avoid duplicate entries in the dB/display)

 

[VJzenzub 2]

Thanks again for the follow-up @cayars. 

@rbjtechThe part that really throws me is my 'part 1' and 'part 2' files are also freezing out after a fast forward. So even with merging/appending totally out of the equation, I'm getting a similar symptom. Thanks for showing the sweet trick with the multi-resolution selection box. You're darn right, duplicate entries be damned. 

[Luke 37251]

HI, so are you still having an issue?

[VJzenzub 2]

@LukeSure am. 

[VJzenzub 2]

@Luke Took another look at server settings, deselected the option to let Emby "throttle" back transcoding demand on the CPU, and re-tested. No more freezing behavior. Consider the issue solved. 

[Luke 37251]

16 hours ago, VJzenzub said:

@Luke Took another look at server settings, deselected the option to let Emby "throttle" back transcoding demand on the CPU, and re-tested. No more freezing behavior. Consider the issue solved. 

Hi, are you sure? Can you test it a few more times to ensure the result is consistent? Thanks.

[VJzenzub 2]

1 hour ago, Luke said:

Hi, are you sure? Can you test it a few more times to ensure the result is consistent? Thanks.

I have run another file through, and it fast forwarded fine without a freezing problem. It just seeks for a few seconds to find and load the appropriate frames and resumes without a hitch. Previously, it would take a longer time, resume briefly and then freeze totally. 

This test was with a joined/appended mkv via MKVToolNix. To reiterate, the only variable in operation that I have changed from the initial problem report was simply to de-select "Enable Throttling" from the Transcoding submenu. Attached are the logs. I'm too much a novice to understand them in detail, but if there's anything still apparently wrong with them, I'd like to know. From a user's point of view, however, the playback appears fine. 

ffmpeg-transcode-6997dbe8-0a7d-47cd-ad0c-1a76e39e4982_1.txt ffmpeg-transcode-e213eb59-c17a-4623-b28c-e82b04275d9b_1.txt ffmpeg-transcode-fadb7f20-c5bb-4240-a85c-028611fc31be_1.txt

[browneye253 2]

This is an old thread... but I was having the same issue and unchecking "Enable Throttling" has resolved my fast-forward problems too.  It also seems to make the initial playback quicker.