All Activity

Thanks, it seems to be working now. Thanks for the quick response!

that's a great point and something I already did, but emby decided to delete info and try to re-scrape everything. It also decided to delete a bunch of images I already had saved.

Probably not relevant: Apparently Apple OS can throttle back activity, based on battery levels that go below 80%. https://www.gadgetreview.com/the-real-battery-gate-how-to-check-if-apple-is-still-throttling-your-iphone-and-stop-it#google_vignette Also, your test media is pushing the limits of playback. I wonder if even a change in Wifi activity might trigger an transcoding for the audio. Or does the update have any default playback settings that changed, instead of keeping the previous settings? Yes, of course, there can be a code issue that needs to be corrected. It might be helpful to test less demandng fps and media bitrates to see where playback starts to work.

Scratch that, user error.

Ok Fair. Now go apologies to the poster, which post you dismantled.

Just wanted to ask about 2 part movies and how they are handled. I have a folder for Kill Bill. In the folder I have kill bill - part 1.mkv and kill bill - part 2.mkv. Only part 1 is recognized whereas on my nvidia shield shows both parts as well as my emby server does. Not sure what I’m missing

Hi Luke, It works perfectly! Thank you!

Thanks, I think this discussion has actually cleared up several things for me. First, @vdatanet was right about the terminology. I was mixing up Direct Play and Direct File Access. If Emby delivers the original media byte-for-byte unchanged over HTTP, then it is Direct Play. What I was actually referring to was Direct File Access, where the player opens the original file directly from the network share and handles its own I/O, buffering and seeking. I still prefer Direct File Access for my local Kodi/CoreELEC setup, but I understand why HTTP is the practical solution for most Emby clients. @FrostByte's information about the Shield is also interesting. So Direct File Access wasn't fundamentally impossible there — it actually existed, but changes to Shield OS made it unreliable enough that the option was eventually disabled. That answers part of my original question. @Luke, your explanation about Emby's player also corrects an assumption I had made. I wasn't aware that Emby has heavily customized ExoPlayer/Media3 and also integrated client-side FFmpeg software decoding. Since Just Player is itself based on ExoPlayer/Media3, I agree that simply blaming ExoPlayer is too simplistic. Clearly, different implementations of the same underlying framework can behave differently. However, I don't want to turn this into another round of reproducing old playback problems on my Shield. I've done that kind of testing in the past, and my current setup is deliberately configured around the solutions that work reliably for me. I'm not going to dismantle or reconfigure my working setup just to reproduce issues I've already worked around. On the Shield in the bedroom I use Emby with Just Player because that combination works for what I need there. On my main system I use Kodi/CoreELEC with Direct File Access because that gives me the playback path I want. So I'm not asking you to debug my Shield setup here. My broader point was to understand why these different playback paths behave differently and why Direct File Access disappeared from the Android TV client. I think the answers from all three of you have clarified that considerably. I may not agree with every design decision, but I understand the technical reasoning behind them much better now. Thanks for the explanations. So I think we've actually made some progress here.

I know this has been requested in the past, but it's been years (almost 7) since then, and it's not live in a usable form on Emby for Android. There's a fundamental misunderstanding on how codecs are handled and what can and can't be passed via TOSLINK, Arc or eArc. With an Emby for Android install on a TV - in this case, a Bravia x95j, Emby (correctly) sees that the TV can decode AAC audio in 2.0, 5.1, etc. What it does not see is that if the TV is set for passthrough to an audio receiver or soundbar, it CANNOT PASS AAC OVER HDMI - because AAC and HDMI do not ever work together. Then, by default, TVs will downmix this to PCM 2.0 because again - HDMI hates AAC, and Arc does not support PCM 5.1/7.1 - there just isn't enough bandwidth in TOSLINK or Arc to make it work. While eArc CAN carry pcm bitstream 5.1/7.1 - TV's will always force AAC down to PCM 2.0 to send it via passthrough on any HDMI link. There is no TV on the market that natively remixes AAC 5.1/7.1 to any type of multichannel format in order to pass it to another device. It's always remixed to PCM 2.0. Kodi has the ability to force-flag a conversion of any AAC audio to AC3 in the options - Emby's built-in option relies on a hardware detection algo that doesn't see if the codec is being sent anywhere other than the TV it's installed on. Here's the TL;DR Problem - no option to force AAC to AC3 conversion on a device with native AAC decode, but AAC can't be sent over HDMI if a receiver or soundbar is involved for the audio playback. PCM 2.0 is the result, 100% of the time. Cause - AAC doesn't play nice with HDMI, and TOSLINK/Arc don't have the bandwidth to support it in multichannel, even if they did. Emby does not consider devices down the chain that might be handling audio from the TV via Arc, eArc or Toslink - only the base hardware capabilities of the device it's installed on. Solution - instead of an "if a video uses a codec but the system Emby is installed on has incompatible hardware, force conversion to AC3" option, add an "always convert to AC3 for these codecs" option, similar to Kodi's.

Ok let me spell it out. Did you read the link to the post? Read what I have marked with red Posted July 9 New patch release - Version 4.1.4.0 Download .dll and full release notes: https://github.com/soderlund91/HomeScreenCompanion/releases/tag/v4.1.4.0 Bugfix release IMPORTANT! Minimum required Emby server v4.10.0.17 Release notes Fixes: Tagging collection: Fix issue where tagging a collection name containing a comma isn't working (Eg. "1,001 Movies to watch") Playlist: Fixed a bug where new items where added to the end of the list, now it correspond with the order of the source. Top-list: Fixed an bug with "resume playing" when switching between different versions of the movie (added ffprobe to the .strm files on creation to get playtime etc.) HomeScreenCompanion.dll 1.03 MB · 18 downloads

Thank you for making this. This is an excellent addition!

Hi, the issue is fixed with v1.1.3 https://github.com/MDBList/emby-plugin-mdblist/releases Please update and sync again. Emby.Plugin.MDBList.dll

Checked 4.10.0.31 today, same setup as before: fresh container, same synthetic sample, same probes. Nothing has moved on the tail. Every row below is 4.10.0.30 -> 4.10.0.31: - identical final segments, 6-second segments: 2 -> 2 - identical final segments, 3-second segments: 3 -> 3 - md5 of those segments: f40fe109... -> the same - last fMP4 segment, fresh sessions: no response -> no response - "FfRunException" in the server log: 0 -> 0 - ts matrix: all 200 -> all 200 - mp4 matrix, segment 221: 45-second hang -> 45-second hang The image id is different from .30, so something was built — just not this. And the .30 fix holds: FfRunException is still zero, so nothing has regressed either. The mechanism is the one from my last post: you restart ffmpeg per segment and seek to the nominal boundary with the video copied, so when the file's last keyframe falls before the penultimate segment boundary with none after it, every later run rewinds to that same keyframe and emits the same frames. The recipe for a file that reproduces it is in that post, and it takes about two minutes to build. Posting this mainly so the thread has the number for .31. Happy to test any build, and to run anything else you want against this setup.

Thanks! v2.7.1.8 installed - just restarting the server now and will report back!

No, which part do I need to read?

Ok then you need to wait to use that plugin, till beta becomes Release. Emby Server Beta - Emby Community

Did you read the post

@ebrSorry about that. @LukeThank you, the standard app works! The only thing missing is a smart playlist function. I could not find any playlists, and likely because I didn't make any in the server. Thanks again!

I don't know what Emby beta is, so I'll assume that I'm not using it

@sobeitjediAre you using Emby beta? That plugin only works on 4.10 Beta

@Grumpy1 Both halves of your message turned into something, so here's the report. The random pick is built. It's a switch in Settings ▸ Home, next to What's In It and Rotation, and it behaves the way I said it would: the draw happens once, when the app opens. A new five every launch, and it holds still while you're in there — back out of a title and the header is where you left it. Flipping the switch re-draws as well, so if you don't like the five you got, off and on hands you another set. What it deliberately doesn't change: the first slot is still whatever you're part-way through, it still skips what you've already watched, and it still only draws titles that have a proper wide backdrop. And it draws from the whole row, not the first handful of it. Your message also found a second thing, which you never reported. Going through that screen to answer you, I noticed my rows were in a fixed order — continue, libraries, recently added — no matter what the account was set to. Your server stores that order per user, and the app had simply never asked for it. It does now: put your libraries above continue watching and that's what you get, on the old home and the enhanced one alike. Two limits on that, both on purpose. It's the order only — which rows exist is still the app's call, so an account with every section set to "none" doesn't open into a blank screen. And Live TV and recordings aren't rows here, they're tiles inside My Libraries, so those two can't be moved on their own. One measured note for anyone else building against this, since it cost me a probe to find: that section list only comes back if you ask for it under the client name "emby". Ask under any other name and you get a 200 with an empty payload — which is a memorable way to conclude that a user has configured nothing. No date and no version number from me. I'll say here when it's out.

Has the new Home Screen Collection plugin been any better for you? Have just tried to install it, but must be doing something wrong. Put the dll in the Emby plugins folder, started Emby, but no difference - can't see how to access the plugin?

I was looking into this plugin as well and was also unable to get it to work.

In the collection I made "0.1 Next up Movies" another movie was missing this morning. When I first put this post here I was down to 11 movies from probably around 75 or so movies. On 9/4/26, I still had 11 movies and this morning (9/5) I only have 10 movies. Most of my collections I created last September and I add to the "0.1 Next up Moves and "0.2 TV Series" weekly. I put 0.1, 0.2, 0.3 etc in front of all the collection names I made to keep them in front of all the other collections the I didn't make, like A& E, ABC, Adult Swim etc. I have 11 collections that I have made and added movies or shows to and all of are missing movies. I made a new collection "0.12 Rocky" and it still has the 8 movies I put in it on 8/31/26. How can I tell if I have nfo files in my movie directories next to the movie files? When I added movies to the collection "0.12 Rocky" for example, I created a Rocky collection and added a Rocky movie to it and then changed the collection name to "0.12 Rocky"and then added the rest of the movies to 0.12 Rocky.

Yes — and it's worth saying why it's the same five, because what's missing isn't really the shuffle, it's that the rule picking them never varies. Those five slots are chosen once, when the app opens, and always the same way: first whatever you're part-way through, then the newest unwatched item from each of your libraries, one each, then an unwatched favourite. Nothing in that changes until you either watch something or add something to the server. So your case — not getting to the movies right away — is exactly the one where it can sit on the same five for days. That's a fair thing to complain about. The good news is the pot is already on the device. Since 1.8 each library's row is loaded 128 items deep instead of 16, so taking one of those at random rather than the newest costs nothing extra: no new request, same data already in memory, just a different item off the same list. If you're curious how big that pot is on your server, Settings ▸ Home ▸ What's In It already shows an "eligible" count next to each source — that's the number a random pick would be drawing from. Two rules I'd keep. Only items with a proper wide backdrop can go up there: a poster stretched across 1920 looks bad enough that I'd rather show one slot fewer, so "random" means random among those, not random across the whole library. And it should keep skipping what you've already watched, same as it does now. One thing I'd not do is reshuffle while you're looking at it. That header is rebuilt every time you come back to Home from a title, so a naive random pick would put a different film at the top every single time you back out of something — and there's already been a bug reported on this thread about that screen not sitting still. The draw wants to happen once per launch: different every time you open the app, steady while you're inside it. That's the version I'd build. It fits in the section that's already there, next to What's In It and Rotation. No date and no version number from me, as usual — but this one is cheap and I know exactly where it goes. And thanks for the other half of your message. You're the first person to tell me they left the new home switched on, and that's the one question I genuinely can't answer from here.