All Activity

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.

There's a preview version on the App Store with Jellyfin support only. I'm still working on the app, but for now I've disabled Emby support until this bug is fixed. 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.

Try turning off match resolution. Some movies are in resolutions like for example 3840x1600 (amongst others) some TVs and AVRs don't recognize those resolutions and scale down to 1080p to be able to view them. Turning off match resolution will keep the TV in 4K and show the movies in that instead. Turning off the option can introduce a slight judder when watching 1080p and below videos though. @LukeMaybe an option to automatically turn it on at specific video resolutions could be made?

2.0.8.0 Update app icon Add group by to collection screen Show resume button if next up episode is resumable Improve video playback error handling Support A-Z picker on list screens Fix remove from resume context menu option Various subtitle rendering fixes Subtitle font fixes Improve logo display on detail screen Fix various mpv crashes

Emby for Apple TV Released Changes 2.0.8.0 Update app icon Add group by to collection screen Show resume button if next up episode is resumable Improve video playback error handling Support A-Z picker on list screens Fix remove from resume context menu option