Websocket Keepalive

[SShzin 37]

32 minutes ago, Cr8iveLosr said:

Here’s a simple thought: instead of bombarding him with unnecessary responses, just answer the question.

As of right now, there is nothing in the changelogs indicating that this long-standing feature request has been added.

The more you know....

My best guess is there's not a real response to the question. Latest has been the same release number for a while now. 

[Cr8iveLosr 102]

3 hours ago, SShzin said:

My best guess is there's not a real response to the question. Latest has been the same release number for a while now. 

Yeah, deflect and delay seems to be the default approach about 90% of the time.

[ebr 16682]

We are working completely blind.  We cannot see or touch your installation.  So, the most specific information we can have is always helpful.  You can make it easier for us to help you or more difficult.

[Cr8iveLosr 102]

This isn’t an installation troubleshooting issue, and asking for a version number doesn’t answer the question.

The question is simple:

Has WebSocket keepalive been lowered to a real world websocket timeout or made configurable in a released server version? If yes, which version and where is the setting? If no, is it still planned?

There are already multiple pages explaining the issue. Deflecting back to “what version are you on?” just avoids answering whether the feature exists.

[SShzin 37]

It'll be a week tomorrow so I'll rephrase, using the above question;

 

Has WebSocket keepalive been lowered to a real world websocket timeout or made configurable in a released server version? If yes, which version and where is the setting? If no, is it still planned?

 

 

[SShzin 37]

Bump

[jcbhltz 4]

Crazy this is left unresolved. 

[Cr8iveLosr 102]

It honestly feels like squirrels are being thrown out as distractions at this point.

Months ago this was described as an existing keepalive that just needs its interval adjusted, possibly even exposed as a setting. That was framed as a relatively easy change. Yet releases keep coming and this never gets addressed.

At this point this isn’t even a feature request anymore. It’s a glitch in the matrix that’s already been identified and can be resolved.

A proper keepalive interval of 30–45 seconds, or the previously confirmed configurable option, would directly address the problem being discussed here.

[SShzin 37]

bump

[Cr8iveLosr 102]

Just a courtesy reminder: as of June 30, 2026, the current beta version is 4.10.0.17-beta, and the latest stable version is 4.9.5.0.

Sharing this in case anyone is confused or asks.

Thanks!

[SShzin 37]

2 hours ago, Cr8iveLosr said:

Just a courtesy reminder: as of June 30, 2026, the current beta version is 4.10.0.17-beta, and the latest stable version is 4.9.5.0.

Sharing this in case anyone is confused or asks.

Thanks!

I'm pretty sure this is unplanned at this point.

[jcbhltz 4]

Insane this has not been addressed yet

[Cr8iveLosr 102]

Another courtesy reminder: As of September 8, 2026, the current Stable version is 4.10.0.40, and there is still no sign of a keepalive interval setting.

Sharing this in case anyone is confused about which version we’re currently on.

Thanks!

 

[Luke 43049]

14 hours ago, Cr8iveLosr said:

Another courtesy reminder: As of September 8, 2026, the current Stable version is 4.10.0.40, and there is still no sign of a keepalive interval setting.

Sharing this in case anyone is confused about which version we’re currently on.

Thanks!

 

Hi, have you tested the original issue of this topic to see if there's still a problem?

[Cr8iveLosr 102]

32 minutes ago, Luke said:

Hi, have you tested the original issue of this topic to see if there's still a problem?

Why do you think the issue would have magically disappeared?

Is your goal here simply to ask whether an issue that has been documented and discussed for years still exists?

This topic is nearly three years old, and the underlying problem existed well before this feature request was opened. There has been no verifiable documentation, release note, or other indication that the WebSocket keepalive behavior was changed or that a configurable interval was implemented.

And yes, as of this second, the original issue still exists.

If something has been changed internally, then please tell us what changed and in which version. Otherwise, asking whether we've tested it again doesn't really answer the status of the request.

[Cr8iveLosr 102]

Since this feature request is nearly three years old, here’s a quick recap of what it is actually asking for:

The problem is that reverse proxies such as nginx and HAProxy can close an idle WebSocket connection after their timeout period. If Emby leaves that WebSocket idle for too long, for example while playback is paused, the connection can die before playback resumes. The requested fix was for Emby Server to send periodic WebSocket traffic, such as a ping/pong or other keepalive message, at a practical interval so the connection does not get dropped. A roughly 30 to 45 second interval was discussed as the kind of timing that would avoid common proxy idle timeouts.

Luke confirmed that the keepalive behavior is in the server. He also said making the interval configurable as an advanced option was something Emby could do, and in January 2026 said it was "on our to do list."

So the feature request is not simply "does the client reconnect?" It is specifically about having a server-side keepalive interval that is short enough to survive normal reverse-proxy idle timeouts, ideally with that interval configurable. As of 4.10.0.40, there is still no documented release note showing that a configurable keepalive interval was implemented.