All Activity

Came here to ask the exact same question. Upgraded over the weekend, and noticed thay Next Up was behaving oddly. @Luke, legacy Next Up had quite a bit of logic sitting behind it, from I can surmise. Only shows: - TV Show episodes - Only episodes of shows that have had at least one episode watched - Only the next (single) episode in chronological order.

Wow, they are awesome!!!

Hi there, please attach the Emby server log from when the problem occurred: How to Report a Problem Thanks!

Hi, that's strange. Are you still having an issue with this? Can you give it another try?

Hi, this is resolved in the next update to Emby for Android. Thanks.

Oh do I need to download it fresh? I forgot the link to the download page. Sorry, its been a while lol Never mind I found it

I have an active subscription to Emby Premiere, MBSupporter and livetv-plugin register fine, but IsSupporter/SupporterKeyInfo return "not registered" even right after a fresh key activation, and so unable to use Hardware Transcoding

Latest version was working the last time I checked.

Could be that you've just got all thats available right now pal. The themes get sporadically uploaded so may find times where you will and others not. To confirm you're not having functional issues, run them up with debug logs enabled and check if you're getting something fail. For my they're working fine.

Does anyone know if the trailer plugin is working again? @radeon

Not seeing any issues with my httpd reverse proxy with a stream playing on my phone (pixel 7 pro) and shield at the same time. Both are 3.5.55 and server 4.10.0.40. I generally don't see playback controls for Firesticks for whatever reason - that's not new with 4.10, even on 4.9 I saw that - but everything else seems normal.

Hallo und schönen Abend. Ich weis es ist nicht gerne gesehen wenn man pusht , aber wenn ich nicht irre ist @radeonder DEV der beiden von mir genannten Plugins welche ich käuflich erwerbt hatte. Wird denn an dem Problem gearbeitet bzw ist es überhaupt war genommen ? MfG ########################################################################################### Hello and good evening. I know that "bumping" threads is generally frowned upon, but if I’m not mistaken, @radeon is the developer of the two plugins I purchased. Is work being done on the problem, or has it even been acknowledged? Best regards, Sorry for Google Translator

@ebr When I start playing a video and try to set the speed to x2, nothing happens on some of them. I’ve sent you the log from the app after trying on 2 videos. I also tried a third one that works, and I’ve sent you the log from the app for that one as well. Is it clear for you ? For information : I test for the same video witch works on 2.0.70g on Emby for Android 3.5.57, no acceleration

Curious if I'm doing something wrong or I have misunderstood how to sort channels. I have them in the order I'd like from the Dashboard, Live TV, Channels. But when I go to the guide, with sort order selected to Default Channel Order, the one NFL Redzone channel isn't at the top like it is in the Channels. Any idea how to get this sorted?

Hi, yes that is the goal. Thanks.

I checked the nginx side directly. The Emby vhost is a standard WebSocket reverse proxy using HTTP/1.1 with the Upgrade and Connection headers set, buffering disabled, and long read/send timeouts. There is no sub_filter, body rewriting, or other directive modifying WebSocket payloads. During the exact window where these sessions lose remote control, the nginx error log has no entries. More importantly, I pulled /Sessions live while the problem was occurring. This was one response from the same server: Emby for Android SupportsRemoteControl: false Emby for Samsung SupportsRemoteControl: false Emby for iOS SupportsRemoteControl: true Emby Web SupportsRemoteControl: true All four sessions advertise the same 39-entry SupportedCommands array. Android and Samsung are actively playing, yet the server reports them as non-controllable while iOS and Web remain controllable at the same time. That is also exactly what the Dashboard shows. Android and Samsung are actively streaming but have no pause or stop controls. The iOS session on the same server has the normal remote-control buttons. At the same time, the Emby server is logging: SessionInfosWebSocketListener failed processing WebSocket message SessionsStart System.IndexOutOfRangeException at MediaBrowser.Controller.Net.BasePeriodicWebSocketListener.Start(...) along with the corresponding FormatException in the activity log listener. The WebSocket message is reaching Emby, being identified and dispatched, and the failure is occurring inside Emby's listener code. So at this point the important distinction is not simply whether WebSockets can traverse the proxy. They clearly can. The server is making different SupportsRemoteControl decisions for different client platforms in the same /Sessions response. So I ask once again. Does 4.10.0.40 require any reverse-proxy configuration changes compared with the previous stable release? I have not found anything in the release notes or documentation saying that it does. If 4.10 changed the WebSocket, routing, header, or proxy requirements, identify what changed. The Network tab is a standard remote-access setup. Nothing there was changed with the 4.10 upgrade.

Trakt changed alot of things. Trakt Now Limits Free Users to One Connected Streaming App

Hi, please contact your server admin with this query. This Emby Community is here to discuss the software application. Emby itself does not provide any media and is not a streaming service.

To clarify, I only need to restore the programdata folder and not the system folder? My programdata folder shows an older modified date than system, so I was curious.

When I tried to look for it on a Vega OS device, it does not come up.

Please explain exactly what you are doing and what happens and also follow the instructions to send a log from the app. Thanks.

As a side note, a reverse proxy issue still would not explain why iOS, Apple TV, and the Web client continue to retain remote-control capability while Android, Samsung, and LG lose it on the same server and through the same proxy path.

The reverse proxy configuration has not changed. The same proxy, clients, user permissions, and Emby network settings work normally when the server is rolled back to the previous stable release. Updating the server back to 4.10.0.40 immediately reproduces the issue. Does 4.10.0.40 require any reverse proxy configuration changes compared with the previous stable release? I have not been able to find any documentation indicating that it does. If something changed in the WebSocket handling, upgrade requirements, routing, headers, or proxy expectations in 4.10.0.40, point me to the relevant documentation or release note. I can certainly inspect the proxy side, but that still does not explain why changing only the Emby Server version consistently enables or disables remote control. The proxy is not configured to inspect or modify WebSocket frame payloads. It is only terminating and proxying the connection. The server-side FormatException and IndexOutOfRangeException therefore still seem significant. If you believe the 404 responses are the primary issue, can you clarify what changed in 4.10.0.40 that would cause /embywebsocket to be handled differently than in the previous stable release?

Luke, I have another issue with an 1080p video on a new buyed TV, the file cannot be launched, can u diagnose the problem? regards, see attached file report. ffmpeg-transcode-24f82684-2814-48e2-9c73-7e532d048f38_1.txt

Navigate to Manage Emby Server -> User Sessions