Websocket Keepalive

[Luke 42077]

There actually is one already, but it's just very high (30 minutes). We can lower it a little.

[adminExitium 355]

That shouldn't even be considered a keepalive . I don't think I have ever seen an idle connection stick around for more than a few minutes. Keepalives should generally be measured in the 10s of seconds, even a minute is quite long for mobile networks.

[Cr8iveLosr 97]

I can’t lie, that’s probably the most ridiculous (and funniest) thing I’ve ever read from Luke in all my years here.

Anyway, back on topic.
This is exactly why a proper keepalive is needed. It may not matter in many cases, but it definitely affects browsers more than other devices like TV apps. Even then, it’s still not a true keepalive.

I’ve seen legitimate TV devices connect, then drop remote access after a hardcoded 60 seconds — literally 61 seconds and it’s dead. Even when SupportsRemoteControl is set to true for the client, if the websocket closes, notification messages won’t display on the device. This behavior has been demonstrated in numerous threads over the years.

Something in the Emby core is chasing its own tail. There’s duplicate logic somewhere that’s causing absolute chaos.

[adminExitium 355]

If the only change is modifying the keepalive interval and the actual keepalive mechanism already exists, it seems like a simple enough change.

Should we expect it to roll out in the apps anytime soon?

[Luke 42077]

41 minutes ago, adminExitium said:

If the only change is modifying the keepalive interval and the actual keepalive mechanism already exists, it seems like a simple enough change.

Should we expect it to roll out in the apps anytime soon?

It is in the server, not in the apps.

[darkassassin07 652]

53 minutes ago, adminExitium said:

Should we expect it to roll out in the apps anytime soon?

@Luke

[Luke 42077]

8 minutes ago, darkassassin07 said:

@Luke

Did you read my response?

[adminExitium 355]

That's backwards for websockets... generally the clients do the keepalive to keep the NAT etc. alive from their routers or ISPs.

Anyways, if it's on the server, it should be even simpler hopefully?

So possible anytime soon?

[Luke 42077]

There actually is one already, but it's just a little high (10 minutes). We can lower it a little.

[SShzin 32]

2 hours ago, Luke said:

There actually is one already, but it's just a little high (10 minutes). We can lower it a little.

Sounds good, thank you. Any way this can be a advanced option to configure?

[Cr8iveLosr 97]

FFS

The posts are all describing the same thing: the WebSocket drops during playback, even when the user is still watching. Controls disappear after ~60 seconds because the socket hit a hard network timeout, not because the user is inactive.

Your repeated claim of "lowering a little" isn't helping anyone resolve the bigger issue.

Playback itself doesn’t generate WebSocket activity, so the connection dies no matter what. That’s why people are asking for keepalives or auto-reconnect.

The reports they’re showing a real 60-second forced timeout that Emby currently enforces is the problem.

Wanna fix it? Set keepalive to 30-45 seconds.

Edited December 6, 2025 by Cr8iveLosr

[Cr8iveLosr 97]

3 hours ago, SShzin said:

Any way this can be a advanced option to configure?

This

[Luke 42077]

3 hours ago, SShzin said:

Sounds good, thank you. Any way this can be a advanced option to configure?

Yes certainly.

[Cr8iveLosr 97]

4.9.4.1-beta would have been the perfect time to show users a commitment to fixing this. Just saying...

[Luke 42077]

5 minutes ago, Cr8iveLosr said:

4.9.4.1-beta would have been the perfect time to show users a commitment to fixing this. Just saying...

Yes I guess it would have, but in the meantime, there are some other nice new settings for you to enjoy.

[Cr8iveLosr 97]

Cool story bro. None of which has anything to do with this thread, but I’m sure it’ll definitely help someone… somewhere.

Back on topic,

This FR is about WebSocket keepalive, not new settings or features unrelated to session stability. The issue remains unchanged: sockets drop while users are actively watching, breaking admin control and remote commands.

A proper keepalive interval (e.g. 30–45 seconds) would actually address the problem being discussed.

Or implementing the “yes certainly” configurable setting that was mentioned.

[SShzin 32]

Any chance this will be added to the next release? Thanks.

[Luke 42077]

1 hour ago, SShzin said:

Any chance this will be added to the next release? Thanks.

HI, it's on our to do list. Thanks.

[Cr8iveLosr 97]

Update on this?