All Activity

As promised: 1.4 is out. Approved overnight, on the App Store now, so it should reach your Apple TV shortly if it hasn't already. @Grumpy1 — and anyone else here with a Dolby Vision TV — this is where I ask for the favour. The DV signalling described a few posts up is in this version, and it's the one thing in 1.4 I could not verify before shipping, because there's no DV set here. The test is two minutes: Play one of your Dolby Vision files. Open Settings > Playback Information and read the Dolby Vision line. If it says "in the file and signalled to the TV": did the TV actually switch — its own Dolby Vision indicator lit, not the app's word for it? A photo of that screen plus your TV model closes this either way: "it lit up" means it works, "it didn't" tells me exactly where to look next. And if you ever see "signalled, then withdrawn", that's the photo I most want to see. Same caveats as before, so nobody wastes an evening: profile 5 files (the ones with no HDR10 base layer) go to the server on purpose, dual-layer files aren't tagged, and on a TV that doesn't announce Dolby Vision nothing has changed at all. The rest of 1.4, briefly, since most of it came out of this thread. The on-device path from 1.3 now covers most of a library — H.264 films and shows, and HDR in MP4s, play with the server just serving the file, no transcoding. One visible effect: the end-of-episode stall, where the last stretch sometimes never arrived, can't happen on that path, because the app makes the cuts from the file itself. Beyond that: resolution and dynamic-range badges on the details page, as requested here; Skip Intro on episodes with markers — Emby makes those itself under Library > Markers, no plugin needed; Next Episode when the credits start; audio and subtitles pickable from the details page before playing; server discovery now finds Emby servers on the local network; and the favourites and watched buttons with Emby now actually do something. Whichever way the DV test goes, I want to hear it. Thanks

Should I make a bug report somewhere? I've just removed my extras for now, so I'd love to be notified when this is fixed and I can add them back to my library. Thanks again for your quick responses and assistance troubleshooting!

Yes I think you’re probably right.

We support M3U because it is a universal playlist standard. We do not have any plans to integrate with systems that are primarily or even exclusively for pirating live TV.

Unfortunately, even when locking the extras metadata, and then adding the 9th version, it again identifies them as their own movies. This does at least prevent the extras from suddenly misidentifying as whatever imdb entry their names resemble, so the lock is working, it's just there is no way to edit the metadata to indicate that this item is an extra and not a movie as far as I know.

Not to pile on, but I can't download anything either. On the Emby server (win server 2012) I select the media I want to download, go to download to..., select the device, it goes through the conversion and I can see it in the devices > downloads > ready to transfer. On my phone (iOS, Emby v2.2.56) I do to downloads and nothing is there. No Items Found. If I go to the iOS settings > downloads > manage downloads, there's nothing there either. I can't figure out how to trigger the transfer/push or download to my phone.

Adding parts one by one and rescanning, I was able to get to 8. When I added the 9th and rescanned, it split the extras again. Edit: I now also tried removing one "version", and rescanned, and the extras are no longer seen as movies. Adding the version again, they go back to being movies, so it is changing on only a "Scan Library Files". I will try to lock all the metadata of the extras, and then add the versions and see if that can get me where I want to be. Hopefully this is helpful info, it worked when I first added this movie in '23, so I'm fairly certain this is a newer feature, probably intended to treat folders full of movies in a smarter way, but that's a little problematic when it interprets correctly structured folders incorrectly.

Okay, I tried it with the brackets still, but only put two versions, and it seems to be identifying everything as I would like, extras are shown as extras, as shown below. I think my suspicion is correct, that when you get over some number of versions, it is changing its logic to assume you're being silly and not following the suggested formatting, and it begins looking for many movies within the folder. I will add some versions and keep rescanning and see if I can get them all in without the extras being caught as their own movies.

I will try that now and report back. I have brackets on all my other multiversion movies with no issue, see this example showing the brackets around the version name, and still the extras are treated correctly:

I wonder if the brackets are causing an issue. Can you test by whipping up a second folder that doesn’t have the brackets?

Yes, the versions are being grouped together correctly, but I did notice on closer inspection that there were some slight differences in their metadata (one I had edited and locked, and maybe the others had refreshed from another source since then?) I've tried a couple things now: First I deleted the .nfo files and rescanned, it didn't change anything. In order to ensure that all versions were being treated the same and the different metadata wasn't somehow causing it to look for multiple movies in this folder, I deleted the whole folder from my collection, scanned library files, verified it was gone from my library, and then copied the whole folder (with no nfo files or images back into my collection, and rescanned library files. After doing this, all versions look identical, and group correctly, but even on this totally fresh add to the library, it has put the extras as their own films. I then tried the above process again, re-adding the folder to the library fresh, but this time I removed " - 1080p" from the filenames of the extras, in case that was somehow an issue. This had the exact same result, the movie versions are together nicely, but the extras are their own movies.

No I haven't, do I have to call them? It's a, local net company. Any way to check. Thanks

Hi, I don’t have any news yet, sorry.

Are the versions actually grouped together?

@jcbeaver76 FYI, there is a new pre-release version for CDVR. v2026.08.29.0133 • IMPROVED: authentication for Verizon

Acutally, the nfo files were updated in July, so it's possible that it happened after I installed 4.9.5.0, and I just didn't notice until now, I'm not sure.

Here is the folder contents: And the contents of "extras": This has been in my library since 2023 with no issue, but when I added some movies and rescanned yesterday, I now have no extras on the film, and they show in the main Movies listing instead:

Thorium, set to plain English. Once added English (United Kingdom) and selected that as primary, dates are in desired format now. That's good enough, thanks. Though I reckon plugin should still follow server settings/locale.

Have you checked to see if your isp is using a cgnat?

@millerajm HI there, can you please provide a specific example? How to Report a Problem Thanks !

Hi I'm having this issue also, it appears to have started recently (last week?), even though I haven't updated emby in a while (4.9.5.0), not sure if that's possible. The issue has appeared on a film with 14 separate versions (a choose your own adventure film). Naming follows the recommended convention "movie (year) - [Start_Here].mkv", and the extras are under their own directory Is there a change in logic happening when a file has many versions?

My current Emby library is roughly 178TB. When I started, I had a single 8TB drive for my movies and shows.

I just tried Moonfin, probably switching over to that .. Also shame about Emby, because i rather use that also but I have no hopes of it getting updated.

The ASUS NUC 15 Pro 7 255H has a much better processor with a better encoding engine. I would agree with Luke, it is the better machine. If you can, turn the other one into your HTPC.

ffmpeg-remux-754143a4-6c19-484b-b06e-b93f23fa3705_1.txt stops 10 sec. in. srt...