All Activity

Emby Web App Update: Version 26.0.25 The Emby Web app has been updated to version 26.0.25 Go and try out: https://app.emby.media/ Changes 26.0.25 Various spotlight fixes for older devices General slideshow fixes Support mousewheel for horizontal sections in TV display mode

@nospotifyhas this helped?

Hi, this is on our to do list. Thanks.

Yikes released this to main branch? Man

That's not a Vega device... But we are definitely in the normal Fire OS app store - twice, in fact. What part of the world?

Thought it might be useful (or not) to be able to add some form of note to the above, so if there's an address or three I can say somehow which address belongs to which user. Maybe a separate row of ID's per address, or a way to have in the filter stuff in quotes, as in "Colin='131.294.265.265, or something.

OK, are you trying to connect to your own Emby Server, or someone else's server?

If you can get it to happen again with debug logging enabled then that may tell us more.

Sorry - I misread that. Your solution is good. Paul

The log I imagine shows my plugins. Could it be conversant or something that is incomparable with the later release?

I have not changed anything for a long while. Except emby upgrade. By all means I can shutdown jellyseer, which if the only external thing. But it has its own request thing, it does not request emby do this.

Also maybe this is helpful: Because your reverse proxy is NGINX, the interaction between recent .NET 8 servicing updates and NGINX's strict handling of HTTP headers is exactly where this WebSocket rejection usually triggers. When Microsoft rolls out security patches in .NET 8 maintenance releases (specifically targeting HTTP Request Smuggling vulnerabilities), Kestrel becomes exceptionally strict about evaluating request headers. If NGINX modifies or strips specific upgrade headers during the handshake proxying, Kestrel will instantly reject the socket. To restore functionality, your NGINX location configuration must explicitly preserve the WebSocket handshake headers: The Required NGINX Configuration Fix In your NGINX site configuration file (e.g., /etc/nginx/sites-available/default), update your location block for the ASP.NET Core application to explicitly map the Upgrade and Connection parameters: nginx location / { proxy_pass http://127.0.0.1:5000; # Address to your Kestrel instance # Force HTTP/1.1 for the WebSocket handshake proxy_http_version 1.1; # Explicitly map the upgrade headers required by Kestrel proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; # Forward original client routing details to ForwardedHeaders proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # Optional: Prevent NGINX from prematurely killing long-lived connections proxy_read_timeout 86400; } Use code with caution. Why This Fails After Recent Updates Stricter Connection Headers: By default, NGINX strips the Upgrade header entirely when proxying requests unless instructed otherwise. Prior to the .NET 8 patches, Kestrel was sometimes lenient if it could still parse the raw payload, but recent maintenance releases immediately abort the request if the explicit Connection: upgrade handshake is absent. [1, 2, 3] The map Directive Variant: If your application serves both normal HTTP traffic and WebSockets over the exact same URL path, hardcoding proxy_set_header Connection "upgrade" can cause standard HTTP requests to behave unexpectedly. If you run into this, declare a dynamic header map at the top of your nginx.conf (in the http block): nginx http { map $http_upgrade $connection_upgrade { default upgrade; '' close; } } Use code with caution. Then inside your app's location block, use: nginx proxy_set_header Connection $connection_upgrade; Use code with caution. [1, 2] After applying the proxy_set_header additions and running sudo nginx -s reload, check if the error persists. If it does, are you seeing a 400 Bad Request or a 404/502 error

Log file is attached. I attempted a Metadata refresh at 23.19. J. embyserver.txt

Have you compared your nginx options to this? What are the differences?

What I can see is that something external is hammering your server with requests for episode listings and this is causing huge numbers of requests to go out to tvdb.

A WebSocket/WSS connection starts as an HTTP GET upgrade request, so seeing GET /embywebsocket in the server log is expected. The relevant question is whether that request reached Emby with Upgrade: websocket and Connection: Upgrade, and whether Emby responded with 101 Switching Protocols or the logged 404. nginx is explicitly configured with HTTP/1.1 and to forward both the Upgrade and Connection headers. If you think those headers are not reaching Emby, identify what you want captured and I’ll verify the actual handshake. The fact that the request method is GET by itself is not evidence of a problem. RFC 6455 requires the WebSocket opening handshake to use an HTTP GET request. https://www.rfc-editor.org/info/rfc6455/

hi there, what makes you think Emby stops working?

OK Thanks. Let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

"Emby" "Emby for firetv"

Hi, For various reasons, I had to change routers and my 'new' router only allows for 192.168 subnets (I had been using 10.0.0). So, I reconfigured the NAS with a new static 192.168.0 address and reserved it on the router, restarted everything and all seemed to be fine. I can access the server from my Mac, plus all other clients, and playback is working correctly. But...since I made the change I am unable to search for new artwork and any newly added files fail to pick up metadata. I assume that the new address is being blocked somewhere along the path but I don't know how to diagnose it, and I don't recall making any configuration changes to enable the old 10.0.0 address on the other router. Can anyone please point me in the right direction. Thank you, John

I don't know. /embywebsocket is a wss url, but in your log file, it's being sent to the server as an http get request. So that is a big problem and it would be helpful to learn the reason for that.

There were some classes of 2021 models that the update did not get submitted for. I don't recall the reason but I think they had something in progress in their review process that prevented them from being selected. We'd like to submit a new version to Samsung within the next week or so. Given the long turnaround time that Samsung has, I would rather just wait and submit the newer build for all models together, rather than just submitting 2.3.6 for 2021 right now.

Just bumping this topic as this most definitely is happening on the most recent stable. Search of one word is ok, more than that it stalls the server out.

Did you try running hard disk scans?

Hi there, what did you search for?