All Activity

PillVideo is an independent third-party Emby client designed specifically for Windows. Powered by the open-source mpv playback engine, it focuses on smooth, reliable playback and a modern viewing experience. PillVideo is currently available as a public trial. Feedback and testing reports are welcome! Key features: Powered by the mpv playback engine Hardware-accelerated decoding and broad media format support Connect and manage multiple Emby servers Featured carousel, Continue Watching, and categorized media library Movie and series detail pages with season and episode browsing Embedded subtitles, external SRT subtitles, and PGS subtitle support Automatic preference for Traditional Chinese subtitles Adjustable subtitle font, size, position, timing, outline, and background Primary and secondary subtitle support Audio track, subtitle, playback speed, and display mode controls Fit, crop-to-fill, and stretch display modes Automatic intro skipping and continuous playback Preloading before the next episode Video screenshots and real-time playback information Keyboard, multimedia key, and mouse controls Traditional Chinese, Simplified Chinese, and English interfaces Automatic update checking and installation Optimized windowed and fullscreen playback for Windows System requirements: 64-bit Windows 10 or Windows 11 Your own accessible Emby server and user account A GPU or integrated graphics processor with hardware decoding support is recommended Current version: PillVideo 1.2.4 Availability: Public trial PillVideo-1.2.4.zip

I've only built and tested this against 4.10.0.20 so far, haven't had a chance to try it on 4.10.22 specifically. I don't have a reason to expect it wouldn't work - nothing in the plugin depends on anything version-specific that I'm aware of - but "should work" isn't the same as "confirmed working." Would you be up for testing it and letting us know what happens? If it doesn't load, the first thing to check is embyserver.txt right after startup for any error mentioning IntrosBackupReplacement - that'll tell us whether it's a real incompatibility or something else. Appreciate you flagging this either way - if it does turn out to need a fix for 4.10.22, better to know now than have others hit it silently.

Is nobody using any of the plugins for these?

@LukeWill this be added at some point? not seeing any traction on this change.

@vdb86 Thanks for your request. This is an interesting use case, but - to be honest - it's also pretty special. Likely too special to become a built-in feature. A GeneralCommandType which allow to remotely control the window state of an app - phhm - I'm not sure. Regarding "native shell": The web ui code that is shipped with apps is not meant to be touched or manipulated. You might have seen this in the Windows app already. And what's sttill working today, might no longer in the near future. So, what then? First of all, the way you have done it is the best you can get at the moment. I would do something similar if I had to. Future Now - there is a way how this can be achieved in a way that is crazily simple: Client Plugins (.net) The Windows app belongs to a new range of client apps which are based on .net and x-plat - named Emby.Client. There is a plugin model, and some other concepts (like JS- <> net interop, service model, x-plat feature among other things). A plugin with this code would already do what you want (roughtly): DISCLAIMER: Just for Illustratration - custom plugins are not supported atm public class AutoHidePlugin : HostPluginBase { private ICurrentPlayer currentPlayer; private IFeatureSetWindowState featureWindowSTate; public AutoHidePlugin(IServiceRoot serviceRoot) : base(serviceRoot) { } public override string Id => "autohideplugin"; public override string Name => "AutiHide Plugin"; public override PluginTypes Type => PluginTypes.Unknown; public override async Task OnAppReady() { this.currentPlayer = await this.Require<ICurrentPlayer>().ConfigureAwait(false); this.featureWindowSTate = this.GetService<IFeatureSetWindowState>(); //// TODO: Handle currentplayer/feauture unavailable this.currentPlayer.ModuleEvent += this.CurrentPlayer_OnModuleEvent; this.currentPlayer.RegisterModuleEvent(@"playbackstart"); this.currentPlayer.RegisterModuleEvent(@"playbackstop"); this.currentPlayer.RegisterModuleEvent(@"pause"); this.currentPlayer.RegisterModuleEvent(@"unpause"); this.currentPlayer.RegisterModuleEvent(@"statechange"); } private void CurrentPlayer_OnModuleEvent(object sender, JsModuleEventArgs e) { var playState = e.GetArgument<PlayStateInfo>(); if (playState != null) { if (playState.PlayState?.IsPaused != null && !playState.PlayState.IsPaused.Value) { this.featureWindowSTate.SetWindowState(WindowStates.Maximized); } else { this.featureWindowSTate.SetWindowState(WindowStates.Minimized); } } } } While that plugin model exists and is actually being used, it is not open for 3rtd party plugins at the moment. No decision has been made so far about whether we might open-up those apps to 3td party developers. There's a large amount of issues, consequences and caveats to consider and unfortunately we haven't come to the right point for this.. Clearly, it has a lot of appeal - the code above Eorks on all Emby.Client app (whch have the SetWindowState feature..

Hi @guilty57, I've got a question about plugin's compatibility. I don't have the plugin in Emby Server 4.10.22, it's not compatible with ?

Hi, there's already an open request for this or something functionally equivalent. Please join in and contribute to the existing discussion at:

Hi there, would it be possible to add the ability to search and sort by country of origin? Thanks

I'm sorry, I still don't know what your question is. There is a current release and a beta track in the store. Both have been updated recently. In exactly what context? Are you having a specific issue?

v1.9.0 is out - a full config page redesign plus a reliability fix. Config page redesign. Instead of one flat list of checkboxes, there are now two clearly separated modes: Custom: pick your own folder(s). Independent JSON and standalone-NFO toggles (the standalone NFO is the plugin's own file, just a <markers> tag - not Emby's scraper NFO), separately controllable for Backup and Restore. Automatic (Media Folder): backups live next to each video, like before. Backup now has independent JSON and NFO toggles (no more "Both" - just check one or both) plus a new "just-in-case" JSON safety copy option that writes to a folder of your choosing, completely separate from what's happening next to your videos. Restore stays NFO / JSON / "let the plugin choose" (recommended). Picking one mode now properly hides the other's section. The separate "Auto-restore" / "Auto-backup on manual edit" toggles are gone too - those background watchers are now on automatically based on whichever sources you've actually configured, instead of a switch you had to remember to flip. Reliability fix: Auto-restore occasionally missed restoring right after a Refresh Metadata, because Emby's own NFO scraper isn't always atomic about writing the file - a read could catch it mid-write. Added a short retry for that specific case; confirmed fixed across multiple shows in testing. If you're upgrading, take a look at the config page - the layout changed, worth double-checking your settings landed where you expect. Release with prebuilt DLL: https://github.com/guilty57/credits-intros-backup-restore/releases/tag/v1.9.0 Custom Selection Auto Selection

Hi, we'll take a look at this. Thanks.

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

Hi, we'll be updating the server's ffmpeg build soon so that may help with this.

Hi, the upcoming 4.10 server release has this now.

The upcoming 4.10 server release has this now.

@LukeI'd like to offer my help with this. I'm ok signing NDAs etc.

@LukeI'd like to offer my help with this. I'm ok signing NDAs etc.

Hi Emby team, First, thanks for Emby. I run it as the media hub for my living-room HTPC and it has been rock solid. ## What I am trying to solve On a dedicated HTPC, I want the Emby client to get out of the way when I am not actively watching, and come back when I am: - Start with windows minimized to tray - so that I can use my phone to select the htpc as play on target. - Pause playback -> hide the client to the system tray. - Resume -> bring it back to the foreground. - Playback starts -> show it; playback stops/ends -> hide it. This is a really nice "appliance" experience on a TV-connected PC: the client is there when you need it and invisible when you do not, without ever landing on the desktop or taskbar. ## What I built as a stopgap Because I could not do this from within Emby, I wrote a small standalone Windows tray agent, "Emby Tray": https://github.com/vdb86/Emby-Tray It polls the server's `GET /Sessions` endpoint, filters to this machine's own session (by local network address / client name / device name), reads `PlayState.IsPaused` and the now-playing item, and then uses Win32 (`EnumWindows` + `ShowWindow`) to hide/restore the client window. It runs entirely outside the client install so client updates never touch it. It works well, but it is fundamentally a workaround, and I would much rather this behavior lived in Emby itself so nobody needs a side-car process. ## Why this cannot be done as a normal plugin today I looked hard at doing this "properly" first, and hit a wall that I think only you can remove: 1. A server-side catalog plugin can subscribe to `ISessionManager` playback events and read `PlayState.IsPaused`, so it can perfectly DETECT pause/resume. But it runs on the server and has no way to touch a client's OS window or tray. 2. A client-side (Theater web/JS) plugin knows the play/pause state directly via the web `playbackManager` events, but it runs in the web sandbox and cannot reach the OS tray or minimize the native window. 3. The server-to-client `GeneralCommand` path is the natural bridge, but `GeneralCommandType` has no command for this. It has `ToggleFullscreen`, `SetVolume`, `Mute`, `GoHome`, `DisplayMessage`, `SendKey`, `SendString`, and so on, but nothing like `MinimizeToTray` / `RestoreWindow` / `Minimize`. So detection is fully supported, but the "hide/restore the native window" half is not exposed to any plugin surface. That gap is why an external agent is currently the only option. ## What would be needed from your end Any one of these would let this be done natively (roughly in order of how self-contained they are): 1. Best: build it into the desktop client directly. Add a tray icon plus a "minimize to tray on pause / restore on resume" option (and a "start minimized to tray" option) in the client's settings. Nothing external needed, and it would be a great HTPC feature out of the box. 2. Or: add `GeneralCommandType` values such as `MinimizeToTray` / `RestoreWindow` (and ideally `Minimize` / `Restore`) that the desktop client honors. Then even a small server plugin could drive the behavior on pause/resume. 3. Or: expose a minimal NativeShell API to Theater client plugins (for example `nativeShell.window.hideToTray()` / `show()`), so a client plugin reacting to `playbackManager` pause/unpause events could do the window/tray control itself. Option 1 is what I would love most, since it removes the need for any plugin at all. Options 2 or 3 would let the community build it cleanly. ## Offer The full working implementation, including the session-matching logic and the Win32 hide/restore handling, is open source at the link above under GPLv3, so please feel free to reference it for the detection/behavior model. Happy to answer questions, test builds, or help however is useful. Thanks for considering it. P.s. I'm also open to trying to help with optimizing the windows app code (start faster, etc.)

By “Downloading from their repo” I meant downloading the apk from emby's GitHub repo (https://github.com/MediaBrowser/Emby.Releases/releases) Downloading isn't the issue, I can download just fine from the website also repo too but after downloading when I try to install the apk I get that “Failed To Parse” error message.

Which Windows app version - I don't see it?

However, it says it's complete and it's not. Should say in progress as Atmos, DTSX, etc haven't been added yet.

On Emby 4.9.5.0, requesting an audio HLS stream with fMP4 segments produces a correct playlist whose segments cannot be fetched. Every segment request — and the init segment — returns: HTTP 500 "Object reference not set to an instance of an object." The same request with TranscodingContainer=ts works. Same code, same token, same track; the only thing that changes is the container. GET /Audio/{itemId}/universal ?UserId={userId}&DeviceId={deviceId} &MaxStreamingBitrate=192000 &Container=mp3,aac,m4a,flac &AudioCodec=aac &TranscodingProtocol=hls &TranscodingContainer=mp4 <-- ts works, mp4 does not &MaxSampleRate=48000 &PlaySessionId={uuid} &api_key={token} Follow the master playlist to main.m3u8, then request either the #EXT-X-MAP init segment or any hls1/main/N.mp4, carrying the auth query params through as usual. Retried over several seconds in case it was a transcoder warm-up: it is not, the 500 is immediate and consistent. Worth saying plainly: the playlist itself is authored correctly — version 7, an EXT-X-MAP pointing at init.mp4, segment durations, the lot. Whatever is missing looks like it sits between the playlist writer and the segment handler. Two small things that might narrow it down, or might be irrelevant — you'll know which: The ts and mp4 playlists are generated from the same request and differ exactly as you'd expect (version 3 vs 7, EXT-X-MAP present only on the second), so playlist generation looks complete. The 500 is identical for init.mp4 and for every media segment, which suggests it's one path rather than a per-segment condition. That's the whole report. I'm not asking for a feature here — just flagging that a route the server advertises can't be followed.

i found out that when i play the video via Emby App it's displayed correctly. but when i use the web link it rotates to the side. What do you need from me to investigate the issue?

Yes it is. However, I think that before I created a dummy playlist in Emby itself, it wasn't there. There seems to be a bug in Emby: the playlists are read and displayed within the music library (see the first image I attached), but they aren't actually added to the library until you create one within Emby.

Is it possible to add a feature to detect the EAC3+JOC (EAC3+Atmos) audio codec? Currently, they are identified simply as standard EAC3. Screenshot from Emby Screenshot from MediaInfo app