All Activity

Hi Luke, following the only log file generated for this specific issue. Take a look that only embyserver.txt is generated and not ffmpeg* at all. The emby macos client is not connecting from internet but is pointed inside the network through an internal router (NAT). After very few seconds (about 2) emby client for mac cresh. Thank you in advance. embyserver.txt

OK, an update. I've been using another box in the last maybe 2 months or so (Mi Box 3s 3rd gen), and this resume issue NEVER happened, not once! So, I guess this is the FireOS issue. To mention that I have the same .apk installed on both boxes, so the app is identical. Maybe this could be helpful.

To avoid conflation i believe "the backdrop" in your statement is both a source (eg jpg) image and 'a backdrop', i assume Emby's cache for "show thumbnail", is an abstraction over the top - I assume the source backdrop image is taken and 'made into/cached as;' the show thumbnail (by way of the rules of inheritence); i assert when looking at 'a backdrop', no overlay would be requested, and when looking at a show thumbnail, a 'show thumbnail overlay' would be requested. I dont think it would be a [good] solution if an image presented as 'a backdrop' in the ui received the "show thumbnail overlay". I am at a disadvtage in explaining as i dont know whats possible (or the inner workings of overlays) but hopefully that explain the intention of the feature request.... if the following quote doesnt do it better. This seems to be already working on inherited epiosde images. when looking at the inherited epiosde image (whoose source is the show poster by the rules of inheritence), the "episode overlay" is displayed and when looking at the show poster (whoose souce is the show poster) the "show overlay" is displayed. Sane source image, different overlay in different circumstances, successful granular presentation in the ui...so Emby already seems to be working for [inherited] episode images; But not working for [inherited] show thumbnails.

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.