All Activity

So far it seems significantly better, Virtual TV seems to work now when the playlist delay is set to 0. I am able to skip to up next episodes properly also. I will continue to use it and report any issues I face. Thanks for the all the help, I really appreciate it.

Is ffmpeg used to process metadata images in any way? Is it used to render, resize, scan or modify banners, actors, directors, thumbs, station logos, etc? Edit to add: If this CVE is specific to video codecs and not in any way affected by images then I retract what I posted. But if a file delivered as an image can contain a malicious payload and still be consumed by ffmpeg as if it were a video there could be other vectors to exploit this.

Since the vulnerability is in ffmpeg, how would an image provide an exploit surface in Emby? We are addressing the issue but RBJ is correct, the actual risk here is very low and should be pretty easy to identify (due to the huge size of a bad video). Beta is already handled and stable is in-process.

There isn't anything in the current beta related to this FR but the discussion went away from that and to "features" in general. I would say we have some major new features in the beta.

Is it time to rethink strm files? Maybe we should be able to indicate the media type in the file name? movie_soundtrack.mka.strm? movie_soundtrack.audio.strm? Does Emby assume a movie because of the extension?

Greetings I've been using Emby for well over a year now and have experienced 'Drop OFF' so much so that the wife refuses to use Emby for any serious TV viewing. My AI pal says that this is a common occurrence reported by many. The symptom: some channels like CNN play and then all of a sudden drop - Emby just returns to the main screen with no warning and nothing in the logs. Personally I think this is an ffmpeg failure - Emby seems reluctant to re-try playing for a blip or major vid change - it just exits where other players like VLC will keep playing. To that end I found Emby Theater - portable - this allows for a third party video player but unfortunately Emby does not seem to pass the necessary information for VLC to launch. If Emby theater offers an external player option, it should reliably pass the stream URL to that player. VLC is the most common external player, yet Emby Theater does not pass the correct arguments to it, especially in portable mode. I'm a retired software engineer and don't mind fixing things my proposed solution : Emby Shim: We need to know: Where system.xml lives Where externalplayers.json lives Whether portable mode overrides the standard %APPDATA% path Whether portable mode uses a relative config folder Whether portable mode ignores external player settings unless a specific flag is set Once we know the correct path, we can: code a shim ( I will most likely use a python script ) that will launch VLC for the chosen stream. I can guarantee it will not drop-out the way Emby does, and VLC 'will' retry automagically for minor stream blips. Other Info: This happens on Emby Windows and also Emby Linux - Linux seems a tad more stable but not much - it still happens. You say lets re-create ok - I have a way to do that: I have also made my HDHR channels play in .m3u format example: #EXTINF:-1 tvg-id="4.1" tvg-name="WBZ 4.1 CBS" group-title="OTA,Local",WBZ 4.1 CBS http://192.168.1.255:5004/auto/v4.1 (I bet you didn't know that HDHR comes with a built in streaming server... that works perfectly - uses port 5004) Anyway if I point Emby to a stream with a very week channel with lots of pixilation in normal tuning when tuning via Emby it will drop at the 1st failure and return to the menu VLC will keep playing and just wait for the stream to clear. I need this feature in Emby to avoid Drop-Off - this will be a huge fix for my IPTV playing in Emby. Once resolved I'll gladly share the 'shim' with the community. -or- perhaps I'm the one missing something if Emby has a way to let Emby Theater play VLC via the external player. Does anyone see any issues with creating the Shim ? Thanks Jan

There is no real world RCE with this CVE for Emby or Jellyfin. Read the CVE info and the investigative report. In order for them to exploit with RCE they had to explicitly disable a long standing and enabled by default kernel security feature, ASLR. It was the only way they were able to craft a payload that could result in RCE. The investigators are very clear about this in their post. DoS, silent process/thread failures and possibly server process crash are the realistic scenarios AFTER a malicious payload gets on the server for ffmpeg to process. It is still entirely possible for this type of payload (image) to get on anyone's server because almost every Emby user relies on 3rd parties to provide metadata (images) for our content. Those images we all get from any number of sources could possibly be used exploit this CVE.

Hi SamE, Thank you so much. The update to 2.0.7 fixed the issues.

Hi Luke, The issue was resolved in AppleTV version 2.0.7. Thank you very much for your support.

I would echo what others have said earlier. I love Emby, I really do, but, and I say this with genuine "love" sometimes it's not so much what you do, but how this is communicated. You had no advance heads up about this vulnerability, which is of no fault of your own, but despite the message being read, it took a long time to acknowledge with no further information until a fix to the beta branch was announced. Commiting the fix to beta in a timely manner is commendable, but for people to patch their server they need to be 1. Aware of the problem 2. Willing to run beta software. There will inevitably be large number of Emby admins who are completely unaware but would blindly update to a new stable point release and be blissfully ignorant to any CVE. I accept that this may not be the most severe CVE in existence and from my understanding no RCE is possible on Emby, however as a standard operating procedure on how to react to these I'd suggest 1. Acknowledge the issue 2. Provide a brief assessment of the risk of the CVE and am ETA on a time to fix and any suggested mitigations in the meantime, such as stop ingesting media from any questionable sources, take server offline, sprinkle holy water on the server whilst muttering an incantation. 3. Push a fix both to beta and backport to a stable release. From all the evidence it looks like Emby as a project has escaped serious issue thus far, but having a process in place for the next CVE would be very sensible. Whilst a lot of what I've said might seem superfluous, there are some situations where the optics of the situation matters a lot. We all want Emby as a project to have continued success, if prospective users come to the forum to look around, evidence of a robust security posture and professional approach makes a lot of difference. Just my opinion, and genuinely meant as constructive criticism.

Emby have patched the ffmpeg - or more specifically, they have simply disabled the magicyuv decoder in their custom ffmpeg. To note, the magicyuv codec is an uncompressed codec used for professional pre-processing, thus is extremly unlikely to be in 'common' use - if it was, the file sizes would be huge. If you source unsolicited files from the internet - then I guess there is a slim chance it may become an issue for you, but it will only cause a DoS as Emby does not allow any remote code execution in Emby anyway. I'm not speaking on behalf of Emby, but the risk of this CVE to Emby is 'low' thus they have taken the steps to remove the risk (by patching ffmpeg in beta) but have, thus far, decided not to panic the community by releasing a 'hotfix' - as this does not warranty this. I agree with this approach but perhaps a brief paragraph from them explaining the 'why' would be useful.

Greetings I have done some research on this topic, not specifically for Emby but for VLC and other players, the issue is the AC-4 Dolby Support - apparently the greedy corporate folks at Dolby refuse to release this to the public domain so if you do not pay for the rights to publish AC-4 you do not get to play it. A few other platforms like QEMPlay2 figured it out and were told to shut down, I confirmed this with the folks at HDHR some time back. It is a true shame that Next Gen chose an audio stream that the mass public will never get easily. I'm sure in time other players will pay Dolby's ransome to get service but frankly I don't expect Emby to be one of them - hope I'm wrong but so far Next Gen will just be for a chosen few, and then to make matters worse normal broadcast channels when moving to Next Gen add on DRM encryption blocking the broadcast for 90+% of normal viewers - personally I think this is a move to make cable companies richer. Bottom line: Forget ATSC3 until there is a major landscape shift. On the plus side HDHR software play it just fine as long as the channel you are attempting to tune is not DRM encrypted. Oh yeah and the feds plan to make ATSC3 the norm and eventually do away with ATSC - cable companies will love this. Jan

thanks! didn't know that in a change the layout. I still find the menu in that addon a bit confusing.. will try later. thanks!!

Hey, do you have a roadmap? ive been in beta for a long time and havent seen anything related to this. Thanks

@ebr Might you point to where we can follow the Beta at?

How do you know this? As far as I know, Emby has not said that they even know if they have a problem or the scope of their vulnerability. In any case, if your speculation is accurate, then everyone who is ripping their own media is safe. The other 99.999999% of users should probably shut down their instance and use something else while waiting for a production fix or at least some indication from Emby as to the level of risk.

Have you explored the home screen options for that user?

The transcoding of subtitles is working! Emby Server: 4.9.5.0 Emby for AppleTV 2.0.7 (1) Can you confirm if the current behavior is expected? Directplay, subtitles appear I assume in plain text, no processing Transcoded (1080p 5mbps), subtitles adhere to Emby subtitle options, but there is no option to remove background. "Transparent" still shows a background behind subtitle text.

Will the opposite work? Can you just have the sonic analysis and then have the standard Emby apps use the results?

Hi Luke, the relevant Emby Apple TV playback example for “The Rookie - S8, Ep12 - Spionagespiele” should be around: 2026-06-25 20:49:45 UTC in the server log which is 22:49:45 Switzerland local time / CEST. That session ran until around 20:52:39 UTC. There were also shorter Emby Apple TV test starts around 20:37:12 UTC and 20:52:45 UTC for the same episode. Thanks.

Hi. The issue is that the app is showing a background for the items and that particular treatment is designed with a transparent border (because it has rounded edges). A different treatment style, like one of the "metro" ones will fit better in that display.

Hi. Have either of you been following the beta? I'd say there are some major feature updates in the immediate pipeline.

Hi, please try Emby for Apple TV 2.0.7 and let us know how that compares. Thanks.

Hi, please try Emby for Apple TV 2.0.7 and let us know how that compares. Thanks.

Hi, please try Emby for Apple TV 2.0.7 and let us know how that compares. Thanks.