Autoplay not always working anymore

[Protected 86]

Weird stuff. It looks like Emby will no longer always automatically play the next item in a playback queue when it reaches the end of playback for the current item. When that happens, I need to use the next item button or up next list to manually play the next item.

As you may have internalized from some of my other posts, I use the web client. I have two instances, one on windows, the other on linux. This issue seemed to be manifesting on both of them, even though they have separate servers and clients. They were both installed roughly at the same time and have both been in use.

At first I thought I'd messed up while modifying the server or client. So I replaced the entire emby-server/system directory with the contents from the portable 7z distribution of the latest version (4.8.10). I deleted all locally stored information in the web browser, including the cache, and restarted it. I disabled all my plugins and restarted the server. Unfortunately, this issue still manifests! I don't understand. This was working fine not too long ago.

I searched the forum and it seems several other people are experiencing or have experienced a similar issue in recent months. Still, I'm not entirely sure there isn't some kind of setting or some solvable mistake I've made. I actually have a server log for you this time, which is attached. The playback that generated that log reached the end of the video file and stopped. The next video in the playlist was the second episode of that show.

There are HLS errors in the browser console, but I don't know if they're relevant. The following HLS error always seem to be logged at the end of playback on my freshly installed vanilla client:

HLS Error: Type: mediaError Details: bufferStalledError Fatal: false Reason: 

The issue also manifests when using the client at app.emby.media, however it doesn't log the HLS errors to the console.

A friend of mine (using the same stack in his own computer and browser) can also reproduce the issue. Does this have to do with how the videos that cause the issue are decoded? Or is it some kind of local cache or database getting exhausted? Maybe some recent update to the underlying technology? Because I'm 100% sure these videos used to autoplay before...

EDIT: I've also tried accessing the local client using an IP address, 127.0.0.X, in the event the hostname mattered. (No improvement.) And to be clear, I've tried accessing both servers using app.emby.media .

embyserver.txt

Edited October 9, 2024 by Protected

[Protected 86]

Any hints about this one? Is this the same known issue that's already being investigated? Am I doing something wrong? Is more information needed?

It's a little vexing; so far I've been able to fix or circumvent all the other issues we've encountered with our Emby setup on my own, but this one has me completely baffled. If you tell me a browser update broke it, I'll readily believe it.

[Luke 42079]

Hi, does this happen when the episodes are direct playing?

[Protected 86]

I don't know. We're experiencing the occasional ffmpeg error reported by emby when trying to generate a hls segment for a client (I'll be trying to reproduce this cleanly this week so I can post about it with logs). In the client, the result is a black screen or a "no streams available" popup. Since I also occasionally see clients reporting a pause event at the end of a video, I've been suspecting lack of autoplay might happen when the ending segment of the video didn't transcode? That would make sense.

[Luke 42079]

I'm trying to reproduce. My guess is this won't happen when there is no transcoding.

[Protected 86]

Sorry for the delay on my end. I've been busy with an unforeseen "final" (before I can publish the source code) snag in my plugin.

Based on casual observation, I wonder if it's easier to reproduce while transcoding *and* if the load on the server hardware (CPU?) is higher? Or maybe it might happen with certain videos, but not with others.

While I haven't yet produced a clean log, I do have one sample of the one ffmpeg error I spotted in the logs from last week, due to sending it to someone on Discord. I've seen several of this error and they all looked basically like this. I hope it helps with anything. Let me know if it's a different issue.

message.txt

[Protected 86]

I just added a workaround to my plugin for this issue. It was already keeping track of the PositionTicks for each user reported through TimeUpdate events. I noticed that when the web client's video player stalls at the end of the video in this manner, it will continue to send TimeUpdate events, but the position will no longer change.

So I'm using a play request or stop request from the server to forcibly play the next video in the queue/stop playing if there are no more videos, if two TimeUpdate events are received with the exact same position for the same user, and that position is within 5s of the end of the video (could probably be even tighter but I figured this was a nice comfortable margin).

I haven't tested it too many times yet but it seems to work, despite the delay of up to 10 seconds at the end of the video. Perhaps the vanilla server can use a similar strategy, or the client itself (which would allow for a shorter delay).

At this point I can confirm that this problem is easy to reproduce with specific videos, but the exact point where the video stops *as reported by the UI* seems to change a little each time.

Edited October 29, 2024 by Protected