Since 4.7.13.0, Emby Web app does not maintain connection to server

[asimons04 0]

I noticed after updating Emby server to 4.7.13.0 that my web app clients no longer maintain a persistent connection to the server.  Prior to that release, the web apps would always remain visible in the "Play on" drop down.  Since 4.7.13.0, they are only visible on that menu if they're recently refreshed or are actively playing.  Once playback stops or if they load and sit at the home screen for more than about 5 minutes, they are no longer available when choosing "Play on" from another device.

I've got some web clients I use in browser Kiosk mode connected to my non-smart TVs.  I would use my phone app to transfer playback to whichever device was in the same room as I am.  I can no longer do that as of 4.7.13.0.

I updated to 4.7.14.0 yesterday, but the issue remains.

I have Premiere, but I absolutely do not want to use Emby Theater since 1)  it is Windows only and my playback devices are Debian-based and 2) web client playback has been more than adequate since I started using Emby in 2017.

Now that I've described the issue, is this a feature or a bug?  I consider it a breaking bug, but looking for official word.

 

Thanks!

Edited August 28, 2023 by asimons04

[Luke 37090]

Quote

Once playback stops or if they load and sit at the home screen for more than about 5 minutes, they are no longer available when choosing "Play on" from another device.

Hi, this has nothing to do with any Emby changes. The way that remote controls works is that the apps use a persistent web socket connect with your Emby Server. This is the communication channel that Emby Server uses to send the commands to the apps that you want to control.

The problem is that once you let those apps idle for long periods of time, the browsers are going to close those socket connections to save battery, resource consumption, etc. That's what causes it to disappear from the Play On menu. If you are actively browsing around, then it should stay there.

Five minutes is pretty short though, so one other thing to look at is that if you are using a reverse proxy, you'll want to make sure it's not auto-closing socket connections, because some do by default after one minute. 

[asimons04 0]

Ok, I think I found the problem.

When I updated, I had also dialed back the Nginx proxy config for `proxy_read_timeout` back to 360 which, coincidentally, is the amount of time it took for my persistent web clients to disappear (6 minutes).  Setting that back to a very large value, 36000 (ten hours), it seems to behave as expected.  I guess that wasn't a vim typo in the conf after all.  I guess I'll leave it idle for 9 1/2 more hours and see if it stays connected.

Weirdly, I had HomeAssistant running with an identical proxy config and read timeout (it also uses a persistent websocket), and its websocket was not timing out.

Is the WebSocket perhaps not automatically reconnecting in the cases where the reverse proxy times out?

I'll update this post (or reply to it) once the 10 hour idle mark has passed.

 

Edited August 28, 2023 by asimons04

[Luke 37090]

Quote

Is the WebSocket perhaps not automatically reconnecting in the cases where the reverse proxy times out?

As long as you are actively doing something, even just browsing around, the app will continue to try to keep the web socket open.

 

[asimons04 0]

Yeah, that's the problem; they're not always active.  And I'll admit, I'm probably an edge use-case here.

I'm using old PCs that auto-launch Chromium into Emby in Kiosk mode at startup.  They sit idle at the home screen most of the time with the screen or projector turned off. When I want to play something, I simply open Emby on my phone or my laptop, select "Play on" choose the "Living Room" device, and then use my device-on-hand as my remote.

I've got webhooks and helper agents that take care of detecting the playback events to turn the display devices on/off.

So I always assumed that if the websocket connection ever dropped due to idle, it would simply reconnect automatically (like HomeAssistant and some other apps do).

Edited August 29, 2023 by asimons04

[Luke 37090]

Quote

So I always assumed that if the websocket connection ever dropped due to idle, it would simply reconnect automatically (like HomeAssistant and some other apps do).

That's not a good practice because the app can't determine the exact reason for the connection closing. For example it's one thing to try and immediately automatically reconnect if it was just closed due to a server-enforced timeout, but if it's closed for some other reason then you could just end up trashing unnecessarily. That's a recipe for having your app labeled as a resource and battery drain. 

That's why we do automatically reconnect, but only while you're using the app.

Our android, macOS and iOS apps also have more than one communication method, the other being push notifications, so we don't really have to resort to something like that. it is also on our to do list to add push notifications to our hosted web app, https://app.emby.media, and then you could use that.

[asimons04 0]

Again, this is the webapp and not an installed app, and it's running locally.

I've already got the impression I'm an edge case here with a unique deployment,  so I'll just deal with it or come up with a workaround.

Consider the issue resolved.  Thanks.

 

[Luke 37090]

We used to try and do this but it resulted in too many web socket requests hitting Emby Server.  That becomes a resource drain on both sides. That's why it's better to just lift the server-enforced timeout.