Playback stops 4 mintues from the end of the video

[TeamB 2438]

I have a weird situation where a few of my videos stop playback 4 minutes from the end of the video. This is with playback in Firefox browser.

When I look in the logs it looks like ffmpeg failed to start when processing the last part of the video.

I have logs for both 4.5 and 4.6 beta. They both exhibit the issue at the same point with the video stopping but with the latest beta 4.6 the playback recovers, after a few video pauses, and is able to play the last 3 minutes, it looks like it is retrying and somehow gets over the issue.

Has anyone else seen this? @Luke do you want the logs?

[Luke 42078]

Hi, yes that would be great, thanks.

[TeamB 2438]

38 minutes ago, Luke said:

Hi, yes that would be great, thanks.

log files PM'ed

[Carlo 4561]

Does this only happen with certain files?
Does it only happen with firefox or other browser/clients as well?

[TeamB 2438]

its only with certain files and only if DirectStreaming to the web client

[Carlo 4561]

Certain types of files or just a handful of files in general?

The reason I ask is because typically issues like this are often times the media itself.  Sometimes just remuxing the file will fix headers.

[TeamB 2438]

I re-encoded a season or two of Sar Trek TNG using Handbreak (nvidia) and a few of them exhibit this issues.

Kodi plays them all the way though and also if I play them using the windows media player it works fine.

From what I can see in the log files it has something to do with Emby/ffmpeg processing the last chunk of the video, it looks like ffmpeg is asked to process only the last 30 seconds of the file and it does this and returns ok but Emby must think it failed? Finished too fast perhaps?

[Carlo 4561]

Just me, but I'm not a fan of handbrake and never have been.

Accessing a video by file is a lot easier than by segmented streams and often times little "flaws" in media won't show up in file based players while they will in stream based players.

Anyway you could upload one of these problem files for me to take a look at?

[TeamB 2438]

I have tried a few different encodings of the original file and even re tested the original source file and they all fail the same way, playback stops at about 3 minutes from the end.

Looking at the log files again I still think that the error and failed message is due to the ffmpeg process exiting so quickly, that is just my take.

[Carlo 4561]

8 hours ago, cayars said:

Anyway you could upload one of these problem files for me to take a look at?

 

[TeamB 2438]

15 hours ago, cayars said:

Anyway you could upload one of these problem files for me to take a look at?

I will pm you a link today with the download

[TeamB 2438]

@cayars I added you to the PM with the logs and link to the file

[Carlo 4561]

Do you have this same problem in Chrome or any chromium browsers?

What version of Firefox are you using?

[TeamB 2438]

Latest version of firefox.

Latest edge browser did not have the problem but it was reporting direct play instead of dirrct stream in stats for nerds

[Carlo 4561]

What does the detail screen (bottom) show for the Media Info?
 

[TeamB 2438]

Are you able to reproduce with the video file?

[Carlo 4561]

I'm downloading it right now and will test shortly.

[Carlo 4561]

Getting ready to test this but did notice a funny bit of audio naming.  The audio track title is DTS but the codec is 2 channel AAC LC.

[Carlo 4561]

I tested with firefox 88.0.1 and Emby Server 4.6.0.48

I jumped to about 7 minutes left and let it play in firefox and it played just fine (direct streamed).

I did this a couple of different times and it always played.

The only "issue" for me is QUALITY choice that show up on the Cog menu.  The higherst I could set it is "480o-4Mbps" and the video is 720.

 

[Luke 42078]

4.6 should be a little more resilient about retrying and recovering, yes. Now as far as why it happens in the first place...

Can you do a quick test and see if it also occurs with hardware transcoding disabled on the server?

[Carlo 4561]

It doesn't need transcoding at all so that's not a factor.

[TeamB 2438]

9 hours ago, cayars said:

I tested with firefox 88.0.1 and Emby Server 4.6.0.48

I jumped to about 7 minutes left and let it play in firefox and it played just fine (direct streamed).

I did this a couple of different times and it always played.

The only "issue" for me is QUALITY choice that show up on the Cog menu.  The higherst I could set it is "480o-4Mbps" and the video is 720.

Yes as i said in my op 4.6 was able to play the file to the end with some small jerks and pauses. 4.5 consistently stops playback with 3:22 left to play.

9 hours ago, cayars said:

Getting ready to test this but did notice a funny bit of audio naming.  The audio track title is DTS but the codec is 2 channel AAC LC.

The audio name probably comes from the original source file this file was transcoded from, handbreak probably used the original name for the stream.

2 hours ago, Luke said:

4.6 should be a little more resilient about retrying and recovering, yes. Now as far as why it happens in the first place...

Can you do a quick test and see if it also occurs with hardware transcoding disabled on the server?

I still think this is due to the fact it is just processing the last chunk of the video which is only seconds and mostly black frames and ffmpeg is finishing and exiting too quickly for emby to detect it correctly started.

Not sure why there is 45 or so seconds of black frames at the end of this video, probably just the way the original source was captured, but that makes it very fast to process as the data is very small.

[Carlo 4561]

Well the good news is 4.6 was released today so hopefully your production system won't have any issues with these files moving forward after it updates!

[TeamB 2438]

Just now, cayars said:

Well the good news is 4.6 was released today so hopefully your production system won't have any issues with these files moving forward after it updates!

Yes true but while 4.6 is able to chug through to the end it still stutters, i think the root cause is still there its just 4.6 handles retrying better as luke mentioned.

I will test again today with the new stable release.

[Carlo 4561]

Thanks, it's appreciated!