All Activity

well of course this was assuming emby built it in..

Great question. The short answer is — partially. The coordinator's results don't feed back into the standard Emby apps automatically. Those apps only talk to Emby's own API and have no awareness of the coordinator, so the live sonic features (Track Radio, Similar tracks, Sonic Adventure, Guest DJ) need liquidWave on the other end to query it and drive playback. What does cross over: any mix you generate in liquidWave can be saved as a real Emby playlist with one tap — it then shows up in every Emby app straight away. So you could use liquidWave purely as a playlist-generation tool if you wanted; build your sonic mixes there, save them, and play them wherever you like. The coordinator also exposes interactive API docs at /docs (it's a FastAPI service), so if you're comfortable with a bit of DIY you could query it directly and do whatever you want with the results — but that's not a supported path, just an open door. The natural integration point, and I say this knowing you're part of the Emby team — if Emby were to expose a "similar tracks" or "instant mix" provider interface at the server level, the plugin could proxy those requests straight through to the coordinator and every Emby app would get the sonic features for free. That would be the clean version of what I've had to build a separate app to do. For now liquidWave is the intended front end, but it's a good point about the separation — and an interesting conversation if there's ever appetite on the Emby side for something like that.

Shareable links do not work with Emby Client apps. The route No-IP is going down is an exact replicate of the feature Pangolin for selfhosted is offering. For this to work the Apps need custom header feature, hence this FR: Without it, just the Web access works.

The gratitude is all mine! This does a seriously great job at covering a gap in my household's use of Emby!

Never thought about that, guess i shouldn't be surprised by now of how many different kinds scenarios there are. I will look into it asap. Many thanks!

Spotlight was introduced int a half-assed way months ago, there are very obvious fixes to make (essentially, porting your version to the other apps), but nothing further has been done. This is exactly the sort of thing people are talking about: the first step gets done, y'all tick the box to say you implemented the feature, and it gets ignored thereafter. Porting the ATV Spotlight layout is a particularly egregious example given you've shown it can be easily done, but this is a pattern. The fantastic community IntroSkip plugin got pushed out in favor of an internal feature, but that hasn't been worked on at all since it was introduced and is nowhere near feature parity with that plugin. And indeed several other community plugins have since emerged to fill that gap.

I can confirm that updating to Emby for Apple TV 2.0.7 fixed the issue and the images are now scaling correctly on my device. @SamES@Luke Thank you both for your help!

Baseless? My observations were 100% accurate. Unless you have access to the Emby source code, you were speculating, end of story.

@yockerI noticed some behavior in this that you might want to put some guard rails on. Specifically, I had an episode of a show whose credit detected before the intro. Since I can't imagine a circumstance when this is ever a legitimate issue (I don't think old TV shows worked like old movies where the credit reel ran first), you might want to prevent the credit segment from being written if the IntroStart/IntroEnd tag timestamp comes after. Perhaps it could even be used to weigh confidence score checks?

I literally posted up above what the exploit covers..Jellyfin was the only one that had full RCE and that is why they were contacted..Please read the entire thread before making such baseless remarks. But I'll post it again..

We do not have thje capacity to re-program a complex portal like this - and I don't mean whole GitHub - I mean the vulnerability reporting alone. They have proper separation of private and public information exchange and reporters of vulnerabilities like it, because they are getting proper credits for their findings through GitHub. The ability to acquire CVE numbers has its own hurdles and is not something we can deal with - GitHub handles all of this very well. Apart from that, the way for reporting that we provide is not even up for debate.

Upgraded to 2.0.7 Been running through several videos across tv shows this morning that would previously crash about halfway through while subtitles were on. Everything seems to be stable so far! Even made it through multiple episodes of a single show auto playing without any crashes Thank you @Lukeand team for all your work on finding a fix

Yes, like it has been said before, if you get to acquire such video from a malicious source, then ffprobe (not ffmpeg) might crash. But not Emby Server. It would continue to be working.

Because not all us use GitHub? I freaking hate that site. This kind of info HAS to posted here, on the forum.

Yeah but it doesn't really matter what that video codec is used for. What matters is if ffmpeg detects it, no? In other words if the content, regardless of size, happens to be identified by ffmpeg as MagicYUV then that opens the door to the exploit.

It is specific to that single video codec, prmiarily used in professional post-production (lossless compression, fast and multithreaded decoding, huge video files but still much smaller than individual images).

We DO have a process in place and a way for confidential disclosure of security issues: https://github.com/EmbySupport/Emby.Security/security/advisories Three cases have been processed (analyzed, fixed, validated, released, advisory published) already, two others are in progress. Once confirmed and the patched versions are available, these will be published as well.

I have been seeing s6 errors on 4.9.5.0, as well. After a few hours of troubleshooting, found this thread. For me, the problem manifests as: Running the container with podman, it does not ever stop when given `SIGTERM`, requiring podman to `SIGKILL` the container. I backtracked to 4.9.3.0 and my setup works fine again. # Running 4.9.3.0 [cont-finish.d] executing container finish scripts... [cont-finish.d] done. [s6-finish] waiting for services. [s6-finish] sending all processes the TERM signal. [s6-finish] sending all processes the KILL signal and exiting. From Github copilot:

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: I've been told that ffmpeg is not in the workstream for downloaded metadata images.

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. This part is not a concern as I've been told that ffmpeg is not involved in processing downloaded metadata images. 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.