Transcode Sessions Dropping After 60 Seconds On Pause

[Jcheinaman 19]

Hello,

I already had a thread going, however, I haven’t been getting much help or views there. I’m trying to figure out this aggravating issue. Whenever a stream is transcoding, it doesn’t matter if it’s audio or video or both. If you pause it, exactly 60 seconds after it is paused the stream session drops. It doesn’t matter if it’s in the middle of transcoding or if the transcode has been completed. When you resume playing it changes to direct play and then switches back to a transcode. This causes the entire transcode process to start over from the beginning and causes playback issues for myself locally as well as users remotely, not to mention the fact that it’s using more resources than necessary due to the transcode starting from the beginning instead of resuming the already transcoded stream. It doesn’t matter what client is being used. It can be on the web browser (Edge, Chrome, Firefox), the Emby app, Emby theater, Apple TV and Emby for Samsung. It happens both local and remotely. 
 

I want to add that this does not happen if the stream is direct play, the session will not drop while it’s paused. Only during transcode sessions.

I am willing to help diagnose this issue in any way that I can. If I need to enable verbose logging or full trace or something, please let me know. When you look at the logs, it only says that user has stopped playing the movie or show. I attached logs in my previous post and they didn’t seem to point anything out directly. I’m leaning toward this being a Emby server bug.
 

Please see my attached screen recording. Take note 60 seconds in it completely drops the stream. If this is a setting issue or something I need to change please let me know. I have been trying to figure this out for a long time now. Also take notice that the paused stream is still actively transcoding the file when it drops. This has to be an Emby server bug, correct? I was running 4.8.8.0 with the same issue. I’m currently running on the latest beta with no improvement. I want to say that this issue started sometime in the 4.8 release cycle.

I am running the Emby beta currently on Unraid inside a docker container using the official Emby beta channel  

 

Thank you!!

 

 

 

Edited July 26, 2024 by Jcheinaman

[Jcheinaman 19]

I was able to troubleshoot further and verify this is an Emby bug or setting that needs to be changed. 
 

I installed Emby media server directly on a Windows 11 PC. I used all default settings and installed no plugins or other third party software.  I added one movie file to a folder and added the library to my new windows 11 Emby server installation. I played the movie in Google Chrome on the local Emby host pc, which of course caused the audio to transcode the stream. I paused the transcoding stream and waited 60 seconds. The issue happened exactly the same as it does on my Unraid server. At exactly 60 seconds the paused transcoded stream drops from user sessions and reports that the user stopped the playback in the logs. This hardly seems like it should be designed this way. Transcoded streams are the only streams that drop after 60 seconds, direct play does not drop. 
 

Can someone from the dev team please tell me if you are looking into this issue? It would be greatly appreciated  thanks!

 

@Luke

Edited July 27, 2024 by Jcheinaman

[Luke 42077]

Hi, resources get cleaned up after one minute of idle time so this is normal. You don’t really know if user is going to come back or not so we can’t rely on them to actually click stop.

[Happy2Play 9780]

Just commented in other topic but yes might need to be configurable but to a point can be a good thing when it comes to abandoned sessions.

[Jcheinaman 19]

4 minutes ago, Luke said:

Hi, resources get cleaned up after one minute of idle time so this is normal. You don’t really know if user is going to come back or not so we can’t rely on them to actually click stop.

Well, this is causing issues. I don’t understand why that wouldn’t be configurable on the user side. Is this something that can be implemented? Obviously most people are going to pause for longer than 60 seconds.

[Luke 42077]

What issue?

[Jcheinaman 19]

2 minutes ago, Happy2Play said:

Just commented in other topic but yes might need to be configurable but to a point can be a good thing when it comes to abandoned sessions.

I agree it can be a good thing. I think 60 seconds is way too low and it should be user configurable. Who would pause a stream for 60 seconds? I know when I pause a movie it’s usually for a few minutes to go use the bathroom or maybe get a snack. It’s even worse if you turn on transcode throttling. It causes my transcoded streams to jump all over the place and drop a bunch of frames.

[Jcheinaman 19]

16 minutes ago, Luke said:

What issue?

Seriously? I’ve explained the issue numerous times. It’s forcing transcoded streams to drop from sessions. It doesn’t seem to do it when it’s a direct play file. If you pause the transcoding stream and resume that stream, it causes the transcode to start from the beginning and honestly that’s more of a resource hog than anything because you have to re-transcode the entire video or audio file which in my opinion is completely unnecessary. Eventually, the client player catches up and realizes that it’s playing a stream that’s no longer available. Then it skips around and syncs to the new transcoded stream.

I can tell you this was not an issue in 4.7. Something isn’t right and it’s giving me a degraded user experience. 

Edited July 27, 2024 by Jcheinaman

[Jcheinaman 19]

60 seconds is a really low threshold. Do you honestly pause for less than 60 seconds usually? Also, why would I want my server which is hosting more than just Emby media server to use additional hardware and software resources to re-transcode a stream that was just transcoded not even 60 seconds ago? Most of the time when I was doing my testing, the stream was still actively transcoding while paused, but Emby still decided to drop it    

audio streams are easily transcoded obviously. However, video streams not so much unless you’re using hardware transcoding. 
 

is it possible to get a setting to be user configurable in a future update? Maybe even added to the diagnostic options plugin or something?

if that’s not possible, maybe make it so the clients wait for the new trans code before they start playing again? Because it tries to play the old paused transcode. Then when it realizes that file is no longer there, I’m assuming in the memory buffer of the client, then it freaks out trying to get onto the new stream.

Edited July 27, 2024 by Jcheinaman

[Happy2Play 9780]

I guess this may be client specific then.

 

Edited July 27, 2024 by Happy2Play

[Jcheinaman 19]

11 minutes ago, Happy2Play said:

I guess this may be client specific then.

 

Was either the audio or video transcoding? It only happens to transcodes. Direct play works perfectly fine.

[Jcheinaman 19]

Here’s an example from the iOS client. 

 

 

[Happy2Play 9780]

1 hour ago, Jcheinaman said:

Was either the audio or video transcoding? It only happens to transcodes. Direct play works perfectly fine.

Yes it was transcoding so there has to be a client variable or something.

20:04:42.618 Stream mapping:
20:04:42.618   Stream #0:0 (h264_qsv) -> vpp_qsv:default
20:04:42.618   vpp_qsv:default -> Stream #0:0 (h264_qsv)
20:04:42.618   Stream #0:1 -> #0:1 (copy)

 

[Q-Droid 989]

A few things.

1. No logs?

11 hours ago, Jcheinaman said:

If you pause the transcoding stream and resume that stream, it causes the transcode to start from the beginning and honestly that’s more of a resource hog than anything because you have to re-transcode the entire video or audio file which in my opinion is completely unnecessary.

2. That's not how it works.

11 hours ago, Jcheinaman said:

It’s even worse if you turn on transcode throttling. It causes my transcoded streams to jump all over the place and drop a bunch of frames.

3. Something else is likely causing this. Perhaps the server is not up to the task?

 

[Jcheinaman 19]

4 hours ago, Q-Droid said:

A few things.

1. No logs?

2. That's not how it works.

3. Something else is likely causing this. Perhaps the server is not up to the task?

 

Maybe you missed the part where I installed Emby on a different machine, on completely different Operating system, completely took the network and original machine out of the equation and played one file with direct play video and transcoded audio stream from the local host machine and experienced the exact same issue? By the way, this test windows machine has an Intel 14900k and 64 gigs of ram as well as a NVME drive.

I tested this on Jellyfin and do not have the same experience on my primary server with or without hardware transcoding. 

How many cores would you suggest Emby needs to run? Is 16 cores 32 threads, 128gb ram, 2TB NVME cache drive not sufficient? If so why is this experience not the same on Jellyfin? Why don’t I experience any other issue with any of my other services that are hosted on the same machine? The same machine that’s been running Emby for years without an issue is suddenly a problem?

Are you implying that a basic up to date cpu can’t transcode an audio stream? Because it doesn’t have to be video, the video in these examples are direct play, the audio is transcoded and repackaged as a direct stream. Even if the video is transcoding and the audio is direct play, I use hardware encoding for that.

Did you watch the video files I attached showing how far ahead the transcode was? 

You tell me what logs you want, and I’ll provide them for you. I don’t think it will do any good for you as this has been proven now to not be due to a specific machine or network. 

Edited July 27, 2024 by Jcheinaman

[Q-Droid 989]

Since you didn't provide any logs at all, server or transcoding, there is no way for anyone to guess what kind of hardware you're using to run Emby. This was unknown until you just posted it. Some people run Emby on their routers then complain when it's slow...

When you resume a stream it does not transcode from the beginning unless you're resuming it from the beginning.

It is preferable to have throttling enabled. It would slow the work done while paused instead of continuing to the end of the video. Having streams jump and lose frames when throttling is enabled is not normal or common. So again, something about your environment could be different.

I'm not disputing the behavior you're seeing as far as what the Emby server does when pausing sessions. But I haven't seen any problems resuming playback either. Sometimes I pause my Shield TV for 30 minutes or more and playback resumes as if nothing changed. When I do a test from a browser it's the same. Yes, the backend session drops after 60 seconds including the transcoding process. Then it resumes from where it was paused.

My puny i3 handles this fine. So for the Emby team to be able to help you it's important to give relevant information for troubleshooting the problem.

Dropped frames can be misleading. I can trigger dropped frames by messing with the browser tabs. I'm not saying this is what you're doing and only adding my experience as a reference.

 

 

 

[Happy2Play 9780]

@Q-DroidLuke already confirmed it is normal behavior, but really surprised it has not been reported before now unless it is new.  There has to be variables here as I showed above in ET.

But for it causing issue yes that would have to be troubleshot further as yes it will create playback issues as the session has to be restarted when unpaused the transcode has to be redone.

 

But further testing appears to be playback position related but have no idea of the threshold of killing the session as was only know so far pausing at the beginning under a minute will kill the session per tests and videos provided.

[Jcheinaman 19]

6 minutes ago, Happy2Play said:

@Q-DroidLuke already confirmed it is normal behavior, but really surprised it has not been reported before now unless it is new.  There has to be variables here as I showed above in ET.

But for it causing issue yes that would have to be troubleshot further as yes it will create playback issues as the session has to be restarted when unpaused the transcode has to be redone.

 

But further testing appears to be playback position related but have no idea of the threshold of killing the session as was only know so far pausing at the beginning under a minute will kill the session per tests and videos provided.

I’ve been getting complaints for a bit, but I typically stop and resume instead of pausing. I’ve just been troubleshooting since people keep complaining about it. 

[Happy2Play 9780]

Best guess here would be Playback Resume variables.

[Q-Droid 989]

13 minutes ago, Happy2Play said:

Best guess here would be Playback Resume variables.

But those apply to stop/start (leaving) , right? Not for pausing? 

[Happy2Play 9780]

1 minute ago, Q-Droid said:

But those apply to stop/start (leaving) , right? Not for pausing? 

Potentially yes but there has to be a variable that kills a paused session at a specific playback position.  Guess the only way to know would be pausing every minute to see when it no longer kills the session after 60 seconds of being paused.

[Jcheinaman 19]

2 minutes ago, Q-Droid said:

But those apply to stop/start (leaving) , right? Not for pausing? 

That’s my understanding. This only happens when resuming from a paused state while transcoding. The only variable I can connect is that Emby drops the user session of transcoded streams after 60 seconds of idle time. If Emby doesn’t drop the user session, the issue doesn’t exist. Otherwise everything is good to go.

[Happy2Play 9780]

3 minutes ago, Jcheinaman said:

The only variable I can connect is that Emby drops the user session of transcoded streams after 60 seconds of idle time.

And can you test say pausing in the middle of the media as I have shown works in ET and Browser?  To me there is a playback position variable.

As I showed it being killed at 60 in my first image ie paused after a few seconds of playback but my last image show playback at 49 minutes maintained the pause for over 7 minutes.

[Jcheinaman 19]

1 minute ago, Happy2Play said:

And can you test say pausing in the middle of the media as I have shown works in ET and Browser?  To me there is a playback position variable.

As I showed it being killed at 60 in my first image ie paused after a few seconds of playback but my last image show playback at 49 minutes maintained the pause for over 7 minutes.

When I get some time, I can do this. But I’ve previously tested at various different points during the time line with similar results. I’ll try and do this tonight. 

[Happy2Play 9780]

Pause at 5 minutes via browser.

Still held at 4:02 minutes.

 

But pause at 4:00 minutes session was killed after 60 seconds.

Only testing via Edge browser.

Edited July 27, 2024 by Happy2Play
update testing