Emby Webapp Dashboard not automatically updating data (play time and who's playing what)

[brothom 177]

I'm probably not the first to mention this, but I couldn't find any other thread.

Since 4.9 the Dashboard on the web app (app.emby.media) doesn't seem to automatically update who's playing what or what current time the media is being played.

The Android App still automatically updates the playback data when viewing Manage Emby Server -> Now Playing but the web app does not.

[Luke 42077]

HI there, can you please provide a specific example?

How to Report a Problem

Thanks !

 

[brothom 177]

1 hour ago, Luke said:

HI there, can you please provide a specific example?

How to Report a Problem

Thanks !

 

Whenever i visit https://app.emby.media/#!/dashboard I can see what my users are watching at the time. If I keep the dashboard open, it doesn't update automatically to show if they're still watching or if other people started watching something else. 

The web app used to have an interval setup that would refresh the "Now Playing" section every X-seconds, but that doesn't seem to happen anymore.

The Android app does however still update the "Now playing"-part automatically.

I'm referring to the section "Now Playing" under Emby -> Emby Server -> Dashboard -> Now Playing.

Edited November 11, 2025 by brothom

[adminExitium 355]

It does seem to be updating fine for me. Any chance you are using using a reverse proxy where the websocket configuration is broken so Emby is not able to establish it for updates?

[brothom 177]

11 hours ago, adminExitium said:

It does seem to be updating fine for me. Any chance you are using using a reverse proxy where the websocket configuration is broken so Emby is not able to establish it for updates?

Strange. I tried reproducing this issue from a completely remote device but the dashboard seems to be working fine there.

I am however receiving a javascript Mixed Content error due to app.emby.media wanting to connect via the local network IP which obviously isn't possible:

Regardless, being completely remote seems to work fine.

I'll check my local device again tonight to see if the issue still occurs. Perhaps it only happens when local devices connect via WAN.

Reference
The following websocket seems to control session data: wss://example.domain/embywebsocket?api_key=API_KEY
Check again later locally if this socket can be established and what data is sent.
 

Edited November 12, 2025 by brothom

[brothom 177]

@LukeI wasn't able to check the browser logs but I did perform a small test when I was at the server's address:

1. Enable WiFi
2. Visit app.emby.media
3. Go to Manage Server -> Dashboard
4. Now Playing is NOT automatically updating
5. Disable WiFi
6. Visit app.emby.meda
7. Go to Manage Server -> Dashboard
8. Now Playing IS automatically updating

There's seem to be something funky with the dashboard, but only when connected via the local network. I'll try and check the browser logs when I get a PC to that location.

[adminExitium 355]

Do you have Local using HTTP & Remote using HTTPS? If so, I think the mix of HTTPS on app.emby.media with HTTP on Local URL may be causing issues. Browsers generally frown upon such mixed protocol requests.

[brothom 177]

2 hours ago, adminExitium said:

Do you have Local using HTTP & Remote using HTTPS? If so, I think the mix of HTTPS on app.emby.media with HTTP on Local URL may be causing issues. Browsers generally frown upon such mixed protocol requests.

From what I could tell, connecting via app.emby.media would also reroute to the (secure) https variant for my domain. 

I would have to inspect the local traffic from the network tab on that local network though, so I'll try to provide that and compare it to the WAN traffic.

[brothom 177]

@Luke@adminExitiumI've hook up a laptop to debug and seeing this is quite obvious:

apiclient.js:1 Mixed Content: The page at 'https://app.emby.media/#!/dashboard' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://192.168.2.200/embywebsocket?api_key=f095aee7856248958cb884882d721b46&deviceId=52931313-5600-4af5-bf73-f64589075fe8'. This request has been blocked; this endpoint must be available over WSS.

app.emby.media is trying to open a socket to a local IP-address, whilst coming from a public domain. That doesn't fly with CORS policies obviously.

The question is though; why is the local access being used here, in stead of the WAN access.

[Luke 42077]

OK so it’s allowing the http protocol in this case but not ws. That discrepancy is new.

[brothom 177]

6 hours ago, Luke said:

OK so it’s allowing the http protocol in this case but not ws. That discrepancy is new.

Well it wouldn't happen if the requested path is not an IP address, but an SSL-secured domain name. Those two are handled seperately by CORS.

Regardless, I can't imagine I'm the only user that has this issue though. Has any one of you been able to reproduce this issue by connecting to app.emby.media (via the same network the Emby Server is on) and check out the websocket on the dashboard?

Additionally: shouldn't the protocol be wss:// (secure) instead of ws:// considering we're trying to connect from a secure domain
https://app.emby.media (secure) -> ws:// (unsecure)?

Additionally (2): to confirm, connecting from outside of the Emby Server's network does cause the protocol to switch to wss:// rather than ws:// which seems correct. Perhaps the JS implementation should check if the current domain is secure (SSL/HTTPS) before deciding to use wss:// or ws://, since the http protocol dictates the socket protocol as well.

Edited November 15, 2025 by brothom

[brothom 177]

Diving slightly deeper into this issue, there seems to be a bug within `connectionmanager.js`:

Within `apiclient.js` the serverurl is already wrong

// server = { LocalAddress: "http://192.168.0.1", Name: "Some Name", RemoteAddress: "https://domain.com"  }
// serverUrl = "http://192.168.0.1:80"

ApiClient.prototype.updateServerInfo = function(server, serverUrl) {
      if (null == server)
          throw new Error("server cannot be null");
      if (this.serverInfo(server),
      !serverUrl)
          throw new Error("serverUrl cannot be null. serverInfo: " + JSON.stringify(server));
      console.log("Setting server address to " + serverUrl),
      this.serverAddress(serverUrl)
  }

Tracing this way back to `connectionmanager.js`

            var addresses = []
              , addressesStrings = [];
            if (serverInfo.ManualAddress && ((address = serverInfo.ManualAddress).includes("://127.0.0.1") || !!address.toLowerCase().includes("://localhost")) && !addressesStrings.includes(serverInfo.ManualAddress.toLowerCase()) && (addresses.push({
                url: serverInfo.ManualAddress, // this URL is undefined
                mode: ConnectionMode_Manual
            }),
            addressesStrings.push(addresses[addresses.length - 1].url.toLowerCase())),
            serverInfo.ManualAddressOnly || !serverInfo.LocalAddress || addressesStrings.includes(serverInfo.LocalAddress.toLowerCase()) || (addresses.push({
                url: serverInfo.LocalAddress, // this URL is used and contains the local IP-address "http://192.168.0.1:80"
                mode: ConnectionMode_Local
            }),
            addressesStrings.push(addresses[addresses.length - 1].url.toLowerCase())),
            serverInfo.ManualAddress && !addressesStrings.includes(serverInfo.ManualAddress.toLowerCase()) && (addresses.push({
                url: serverInfo.ManualAddress, // this URL is undefined
                mode: ConnectionMode_Manual
            }),
            addressesStrings.push(addresses[addresses.length - 1].url.toLowerCase())),
            serverInfo.ManualAddressOnly || !serverInfo.RemoteAddress || addressesStrings.includes(serverInfo.RemoteAddress.toLowerCase()) || (addresses.push({
                url: serverInfo.RemoteAddress, // this URL contains the actual remote address / IP / https
                mode: ConnectionMode_Remote
            }),
            addressesStrings.push(addresses[addresses.length - 1].url.toLowerCase())),
            console.log("tryReconnect: " + addressesStrings.join("|")),

Apparently these conditions somehow resolve to using the local IP-address when connecting from within the same network as the server. Considering we're coming from app.emby.media we're not allowed to connect to local IP-addresses in accordance to the CORS scheme.

[Luke 42077]

Quote

Considering we're coming from app.emby.media we're not allowed to connect to local IP-addresses in accordance to the CORS scheme.

It does allow it, otherwise you wouldn't be able to connect at all. In fact, the first time you attempt this, Chrome will even give you a permission prompt to allow it.

So the server connection succeeds, but then at a later stage we run into the surprise of it not allowing it on the web socket url.

[brothom 177]

53 minutes ago, Luke said:

It does allow it, otherwise you wouldn't be able to connect at all. In fact, the first time you attempt this, Chrome will even give you a permission prompt to allow it.

So the server connection succeeds, but then at a later stage we run into the surprise of it not allowing it on the web socket url.

Sorry, I meant for a websocket that isn't allowed and this issue seems reproducible on any modern browser. I'll see if I'm somehow missing something.

[adminExitium 355]

I don't think this restriction is anything new. If you search for message online, you will see mentions of it going back more than a decade about such browser restrictions.

2 examples of such earlier questions:

https://stackoverflow.com/questions/43768161/using-ws-while-on-https-mixed-content (8 years old)

https://stackoverflow.com/a/9752145/3476387 (13 years old)

I guess it's possible browsers started enforcing it recently, but I don't think so. It seems like something else in the connection logic for the Emby App changed, perhaps it used the remote URL earlier?

[Luke 42077]

It's not new, but what is new is that the http traffic now succeeds over the LAN thanks to the permission prompt. This causes the initial connection attempts to succeed.

[adminExitium 355]

I don't think so, the mixed content error seems to be returned even for plain HTTP requests, not just Websocket. From earlier in the thread:

[Luke 42077]

Not in my testing with Chrome.

[Luke 42077]

In both Edge and Firefox, the initial connection attempt over the lan fails outright, so this situation isn't possible to fall into.

It's just that Chrome now has a way to allow the LAN traffic, but currently it is allowing it over http but blocking it over ws.

[adminExitium 355]

Yeah, looks like its a new Chrome-specific feature and has a few noted limitations (Websocket being one of them):

https://developer.chrome.com/blog/local-network-access#known_issues_and_limitations

https://issues.chromium.org/issues/421156866

[Luke 42077]

Quote

We plan to continue integrating the Local Network Access permission with different features that can send requests to the local network. For example, we plan to ship Local Network Access for WebSockets, WebTransport, and WebRTC connections soon.

 

[brothom 177]

@Lukei believe the error logging in Chrome has been slightly changed to reflect a better suggestion: 

Moving forward it would be a better suggestion to switch from ws:// (WebScket) to wss:// (WebSocket Secure). This is probably a much simpler fix also.

 

Edited January 21 by brothom

[Luke 42077]

We are still waiting for them to implement the permission dialog that I mentioned earlier.

[privaty 4]

delete wrong 

Edited January 27 by privaty
delete