All Activity

What does your Emby dashboard say is happening during transcoding? Obvious follow up question, do you have an active Premiere subscription for the hardware transcoding?

Nothing.

You're right — I checked Emby creates one image per show and serves that same image to everybody. The plugin is never told who is looking — it only gets the show and which image type to draw on. So a badge baked into the image cannot differ per person. There isn't even a separate URL per user to hang a variant on. That's why the "ready to binge" mode asks you to type one Emby username, rather than guessing. It's also why the settings page counts your users and warns you if there's more than one. On a single-user server it's correct for everyone. On a family server everyone sees that one person's watched progress. Nothing looks broken, which is exactly why it's said plainly instead of left to be discovered. The default mode avoids the problem entirely: "season has finished airing" is a fact about the show, not about you, so it's the same for every user and needs no username. A badge drawn in the browser could be per-user, because it runs in your session. A badge baked into the image file can't be. Different delivery, different limits.

EmbyWatch — End of Life Announcement Dear EmbyWatch users, After careful consideration, we have decided to discontinue maintenance of EmbyWatch, effective September 1, 2026. We would like to thank everyone who has used EmbyWatch and supported the project. To ensure continued support and development, all Emby-related features currently available in EmbyWatch are being integrated into JellyWatch. What is changing? Starting with JellyWatch version 1720, JellyWatch supports Emby servers and includes the Emby features previously available in EmbyWatch. The minimum required version for Emby support is: JellyWatch 1720 or later EmbyWatch will no longer receive new features, bug fixes, or maintenance after September 1, 2026. What happens to my purchase? If you previously purchased EmbyWatch, you can migrate your purchase depending on the type of purchase you made. EmbyWatch Premium If you purchased EmbyWatch Premium, please provide your complete Google Play purchase receipt, including your GPA transaction ID. Once your purchase has been verified, you will receive a 100% discount code for JellyWatch Premium. EmbyWatch Watch Pass If you purchased an EmbyWatch Watch Pass, please provide your Google Play purchase receipt, including your GPA transaction ID. Once your purchase has been verified, your Watch Pass purchase will be refunded. Please make sure to keep your Google Play receipt and GPA transaction ID, as they are required to process your request. Migration Requests Premium and Watch Pass migration requests can be submitted through the following page: https://jellywatch.app/migration Please follow the instructions provided on the page and submit the required purchase information. Emby Support in JellyWatch For questions, issues, or bug reports specifically related to Emby support in JellyWatch, please use the dedicated Emby support area. This will allow us to properly track and address issues related to the migration from EmbyWatch to JellyWatch. Timeline Date Event Now EmbyWatch will receive no new features Now Emby support is available in JellyWatch from version 1720 September 1, 2026 EmbyWatch officially enters end-of-life FAQ Will EmbyWatch stop working on September 1, 2026? No. The application will continue to work after September 1, 2026. However, EmbyWatch will no longer receive updates, bug fixes, or new features. Will JellyWatch support Emby servers? Yes. Emby support is available in JellyWatch version 1720 and later. I'm an EmbyWatch Premium user. What do I receive? After your Google Play purchase has been verified, you will receive a 100% discount code for JellyWatch Premium. I purchased an EmbyWatch Watch Pass. What happens to it? After your Google Play purchase has been verified, your EmbyWatch Watch Pass purchase will be refunded. Do I need to migrate immediately? EmbyWatch will continue to work after September 1, 2026, but it will no longer be maintained. We therefore recommend migrating to JellyWatch to continue receiving updates, improvements, and support. Thank you for your support and for being part of the EmbyWatch community. The JellyWatch Team

Let me add some things ... OS running: Debian 13, completely patched as virtual client under Proxmox Emby-Version: 4.10.0.27 Saw now a different behavior, potentially we have a second porblem Using the App under Windows 11: search process to create the file list is running, host = 100% load. After a while CPU load is decreasing to 4% -> Windows App is not playing (circle is turning, Mous operations are possibl, no sound) Using the Web-App with Firefox under Windows 11: search process to create the file list is running, host = 100% load. After a while CPU load is decreasing to 4% -> Sound is playing So it seems, there is a communication problem to the app, to. And ... yes, there is an option to enable "vacuumisation" on the DB, but only on next start of server, which can take months. Possibly we need this to do more often as a subtak - possibly at night. A bit strange.... my library.db is 939474944 Bytes, after restart with vacuumisation it stay the same, but library.db-wal has the same size. I did not expect this .. regards, Rüdiger

Have the same issue here since a while - it is not only on searching with explicit names. Just have yout CD collection and try from master directory a random play. Causes my PC the wait a long time - sometimes it will playx, sometimes not. Database needs a speed up - on bigger amount of entries it will downgrade in speed now. A suggestion would be a kind of vaccumisation (as with postgres) or switching to mariaDB - both can handle a bigger amount of data. But this is a design decision .... regards, Rüdiger

"Once all episodes have been watched", 'watched' that sounds like a 'per user thing', i dont think image overalys are per user (but i havent checked), i mention in case it matters. .

3.5.48 Improve syncing of watch data for downloaded content Core UI Changes from 26.0.13 to 26.0.14 Improve loading dialog Improve detail screen transitions Add context menu button for collections to view missing items (requires Emby Server 4.10.0.24+)

Emby for Android 3.5.48 Released Changes 3.5.48 Improve syncing of watch data for downloaded content Core UI Changes from 26.0.13 to 26.0.14 Improve loading dialog Improve detail screen transitions Add context menu button for collections to view missing items (requires Emby Server 4.10.0.24+)

26.0.14 Improve loading dialog Improve detail screen transitions Add context menu button for collections to view missing items (requires Emby Server 4.10.0.24+)

Emby Web App Update: Version 26.0.14 The Emby Web app has been updated to version 26.0.14 Go and try out: https://app.emby.media/ Changes 26.0.14 Improve loading dialog Improve detail screen transitions Add context menu button for collections to view missing items (requires Emby Server 4.10.0.24+)

Here I don't understand what you mean. MediaInfo and Emby shows it as 4K, if you see the first picture it shows as 4K, but streams at 1080p. So all units in the chain streams it at 1080p. Log is attached. Did not see any difference. emby_android_1787463722072.txt

I’ve been building a pretty ambitious home media/server monitoring and recovery system around Emby, Plex, Cloudflare, and the rest of my home infrastructure. The goal is simple: if something important goes down while I’m away, the system should be able to recognize what actually failed, avoid making the problem worse, recover the right thing automatically when it’s safe to do so, and leave a clear record of what happened. Cloudflare is also a significant part of the design. I know there has been a lot of discussion lately about whether Cloudflare is still a practical option for home media environments. Without getting into the nuts and bolts of my implementation, I can say that I’m actively using it as part of a secure remote-access architecture and have been deliberately testing not only normal operation, but failure and recovery behavior as well. It’s grown into a lot more than a dashboard. I now have health monitoring, service checks, dependency awareness, controlled automatic recovery, startup protection, failure history, and safeguards to keep one bad recovery attempt from taking down everything else. One of the more interesting recent tests started with Plex acting strangely after a reboot. Plex eventually recovered on its own, but the recovery system exposed a completely different hidden problem: one stuck recovery attempt could block recovery for another service. That led to redesigning the recovery layer so each service is handled independently, with its own limits and safety rules. I’m also documenting the whole thing as I go so it can be rebuilt from scratch years from now instead of becoming one of those “only the guy who built it understands it” projects. It’s still very much unfinished, but it’s now at the point where I can deliberately break parts of the system, watch it determine what actually failed, recover what it should, refuse what it shouldn’t, and prove afterward what happened. I am also in the middle of building the API that will work hand and hand with my control panel to visually inspect and repair IF the automation should fail its checks and balances. For a home media setup, it has gotten a little ridiculous. And I’m having way too much fun with it. There are a few control panel elements, not the entire panel, that i am willing to share for now. I now completely understand what the developers go thru to deliver an application with little to no bugs every update that is released. Months and more months have been put into this and probably many more before everything i Invision is implemented. See guys i didn't go away, i took a break and have come back with a little project i've been working on.

What was on the gray screen?

Hi there, please attach the Emby server log from when the problem occurred: How to Report a Problem Thanks!

Just started today, Emby works fine on Fire TV, but Roku Emby crashes aftercwrlcome screen. Similar problem was mentioned in the forum in Oct, any ideas?

Hi All I have been using unraid and emby now for about 20 days now. I had only just released I have been software transcoding. I had installed the Intel app however I hadn't set this in the docker. Once I set this to hardware my 4k movie doesn't start or takes forever. I know it's an old pc but it works fine for my 6 uses. I thought switching to hardware would be better but it is not.

Thanks for the interest — genuinely glad to hear it. Where things stand, honestly: Atrium is on the App Store today and it's free, but right now it speaks Jellyfin only. Version 1.1 is with Apple for review as I write this, and Emby support is planned for 1.2, which I've already started work on. I can't give you a date, and I'd rather not invent one. 1.2 doesn't have a frozen scope yet, and on top of that every release goes through Apple's review queue, which isn't mine to control. One thing I'd rather say up front than have you discover it: in the first Emby release, HDR content will be tone-mapped by the server instead of played as HDR. That isn't the app being lazy — Emby's HLS manifest doesn't carry the VIDEO-RANGE and CODECS attributes that Apple's player reads to switch the TV into HDR mode, so letting the server map it down is the option that actually looks correct on screen. Everything else is meant to behave as it does on Jellyfin. If that changes on Emby's side, the app is built to take advantage of it the same day. https://apps.apple.com/app/id6777638751

Qll All local. I lock the connection on each individual read and write. It's all created inside emby, no copying. I'll run that check. Thanks.

It sat with a grey screen for 5 minutes until I force closed it, then I saw the java io error in the app log. Tried it again later and it did load to the hone screen, but it was very slow. This is one of the main reasons I can't use the app, as it is too slow to load and unreliable. Does the app not use the same connection methodology as the ATV app? If not, why not?

is there a testflight for this new app?

It's not a player problem, it's a server problem.

FWIW, I requested something similar years ago: It's one of the main things I miss about Subsonic, so I've not really rebuilt my playlists so much as I keep the originals around until this behavior—simply removing the files—changes.

Seems to work now. But isnt this still a bug? It shouldn't crash. This is a windows box to answer the other comment. Im not sure I love the text "this can take a long time and cause video playback to stall...." whats dumber? IS that is what was happening... WITH this OFF.

Update: I've done most of the core work, and it's looking promising so far. I'm trying to implement the logic for when all TV show episodes have aired: it will automatically change from Next Airing to Complete. Once all episodes have been watched, it defaults back to Returning - Last Aired, or Cancelled / Ended. This is going to be a tough one to crack.