All Activity

Hi everyone, This issue has happened seems to happen to me every few times there's been an ios update but this time nothing seems to be working for me. Using the most up to date emby app and can't sign in with my username or email address. My account is the admin account and while I can sign in on PC (remote) and the server PC I can't get in on my iphone. When I checked the policy.xml I see a <LockedOutDate>1782782859519</LockedOutDate> but not sure if this is pertinent or not? I was just using emby on my phone up to last night (June 28( so not sure what's happened today (June 29). When I open the app on local wifi I can try to log in but then I'm met with the invalid username/password error. When I try to connect remotely in the app I just get the logo and spinning circle. Log attached. No changes to my port/network etc. None of the iphone users on my server reported issues. Thoughts? embyserver (1).txt

@vdatanetCould not wait any longer, fix it myself. Here's the updated cohesive summary: Auto-next episode freeze fixed — HLS subtitle manifest fix. Now working natively without diagnostic plug in. Auto-next episode now instant — after fixing the freeze, discovered another bug where the next episode had a 4 second delay caused by an MKV end-of-file error cascade, next episode now plays instantly Auto-next episode countdown — GUI progress bar now animates smoothly, matching the web version.

How's about you read what softworkz posted, and then apologize?

The audio stops playing after a few minutes, only the video continues playing. Has anyone else experienced this? My media files are in MKV and AAC audio format. It also happens on Roku. I've been having these problems for the past few days.

Myself included. I already posted about what was needed to make that display useful and interactive: But alas...

Thanks for clarifying. For the record, some other people found the inclusion of the text useful.

Yes! it’s frustrating that the user would be dependent on the admin to limit access in order to remove that one device because even if you change password or email still that device would be able to login because there is no option to logout of all connected devices I honestly don’t understand why this isn’t available especially for emby connect, I hope the devs can enlighten me

Now that Android TV client is no longer in active development, can the source code be provided to users so that we can continue tweaking for our own benefit? There are a few things with functionality and UI that were personally requested many years ago that never got implemented. If possible I'd like to take a crack at implementing for myself and for my own personal use. Can you release the code on all the previous versions so that I can go back and find the places where it worked best and reimplement to the current latest?

Yes, and what you're describing was removed as some people did not like it So what we were left with is just a random backdrop from the library that is in focus. This is currently the expected behavior.

Sorry, I don't think my question was clear. I've attached an image to help. As you can see, my "Movies" library is selected and Emby has chosen "The Life of Chuck" randomly from that library. In previous versions, the title and overview from the movie's metadata would also be displayed in the black area on the left.

Awesome!

Thanks. I was able to install version 1.0.7.1 and test it. It is working correctly now, and Emby no longer shuts down when adding new content. Thank you very much for the quick fix.

@AngelSingoop my fault, forgot to push it from GitHub to the Emby library. V1.0.7.1 should be available now. Lmk if it works now!

Thanks for the advice, you are right. In this case, at first I did not know what was causing the issue and I also could not reproduce it. The failure happened unexpectedly, so the only log I had available was that large one. That is why I attached it, because if I restarted or cleared the logs, I could have lost the only evidence where the cause of the problem might appear. Later, almost by coincidence, I found a way to reproduce it: it happened when adding new content to a TV library while TheIntroDB was installed. For future testing, now that I know how to reproduce it, I will do exactly that: restart Emby, generate a clean log, reproduce the problem, and send the log right away.

Thanks. I’ll test it as soon as it becomes available. I just checked the plugin from Emby, but right now the latest version available to install is still 1.0.7.0, and 1.0.7.1 is not showing up yet.

Just a heads up. To help the developer in the best way possible it's usually a good thing to shut down Emby, start it back up (to reset logs and start a new one), reproduce the problem and then send the log right away. This lessens the amount of irrelevant stuff in the logs that the dev has to look through. 10MB of logs is A LOT to go through!

Thanks @AngelSingfor reporting this! Can you try v1.0.7.1 and see if it’s been fixed?

I agree that this should be a fairly basic/standard function in this day in age. It should be brought down to the Emby Connect account level for that user to manage the sign-ins and not dependent upon the server owner having to remove devices from the server side.

HI, are you trying to connect to your own Emby Server, or someone else's server?

And this is why I said that people here were making a mountain out of a molehill, and yet they still thought they knew better..

Update — progress since the original post Quick update for anyone following along (and the folks who've already put their hand up — thanks!). Things have moved on a fair bit since I first posted: A web app is coming — so it won't be Android-only. This is the big one. The original post said Android-only with iOS "a much later maybe." That's changed: I'm building a browser-based web app (PWA) that'll run on iPhone, iPad, and desktop — anything with a browser. It works because the heavy lifting already lives in the backend; the app just asks it for playlists and streams audio straight from your Emby server. A couple of people mentioned they don't run Android phones, so this opens it up to everyone. It's early days, but it's actively in progress. Volume normalisation. One I didn't mention first time round: the app levels playback so a quiet track and a slammed modern master sit at a similar loudness (like Spotify/Tidal do), using loudness the backend measures during analysis. On by default, one toggle to turn off. On-device token encryption — done. I flagged this as a known rough edge last time. Your Emby session token on the phone is now encrypted at rest (Android Keystore), with a seamless migration so you stay logged in. Rolling into the next build. GPU acceleration for the analysis worker. If you've got an NVIDIA card, the worker can now use it (it logs device=cuda on startup) — a big help on a large library. How you enable it depends on the worker's OS: on Linux, the Docker CUDA worker (TORCH_VARIANT=cuda + --gpus all); on Windows, just run the worker natively with the CUDA PyTorch wheel (no Docker faff). Either way it auto-detects the card. CPU still works everywhere — it's just slower. Snappier + more polished. Faster library browsing (cached so reopening is instant and lighter on your server), the Sonic Adventure screen now scrolls as one smooth list, and various smaller fixes from real tester feedback. Marching toward a cleaner public release. Release-build hardening (smaller, optimised, properly signed APK) is now in place behind the scenes — groundwork for when this eventually goes public. Still looking for a few more testers — especially anyone with a GPU (I'd love more confirmation of the CUDA path on different cards) or a big library. Same deal as before: reply or DM with a rough picture of your setup (Emby host OS, GPU or not, library size) and I'll send you the files + repo access. Cheers — still very much a labour of love. It's a private GitHub project, so if you send me your GitHub username I can add you and send further info

The relevant difference is that for JF, an actual exploit existed for RCE, while for all others the severity level was evaluated as disruption of service at max and even that wasn't quite accurate - at least for Emby, because FFmpeg is always run out-of-process and when it would crash, it still doesn't tear down Emby Server.

Nice! Thank You.