All Activity

Did you ever wonder how Emby and Emby Theater did it? Best bet is to use an Android player with true AC-4 Martin

Hi, yes it certainly does, via server transcoding.

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

Hi @sa2000thanks for the update on this. I've refreshed and checked and for the channels in the 400s where there were duplicates from my previous screenshot these all seem to be cleared. New screenshot below. In relation to 323. I have 322 as "GREATRO" so this looks right. And also the EPG seems to match the channel schedule I find online for this. However 323 shows as "GRROMIX". The odd thing is if I set a channel to 323 for the guide data I get the "Great! Romance +1" channel logo, but the EPG guide data just shows "GREAT! Romance mix (Repeat)" for as far forward as I have checked. Ignore the Wrexham logo on the image below, I just picked 2 existing channels I had to tested channel 322 and 323.

While a pligin could fill the bill having the feature as part of Emby does make sense since most do have custom Collections / Playlist.

Some Japanese anime uses SUP/PGS subtitles with positioning so that they can display dialog, sign translations, and background music all at the same time. The Samsung TV app doesn't seem to support this format at all, while the Xbox One app displays the subtitles in a box in the lower part of the screen, so cuts out subtitles that are positioned outside that area. I've tried converting to SRT. However, even if I add positioning instructions (which are not officially part of the SRT format but often supported) that just displays the multiple lines as a single line making it unintelligible. Any advice appreciated, P.

Thank you TMCsw it helps alot. the argument it is expecting is a straight digits or number in other words. channel.exe is in the path and in a dos prompt channel.exe 131 or channel 3229 thats why i chose the recording channel number. i assumed it just passes the number? Ill give the full path a shot and this gives me a good start to getting it running as i was totaly lost as far as the cmd went and or the where. Ill get bak to it in a few days and see what i can do and leave a result here. thanks again.

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.