All Activity

Thanks — glad it's landing well. On the MKV point, though: they do play. What the app doesn't do is *direct* play the MKV container, because the native player can't open it — so the server repackages it into a stream the player can take. That's a remux rather than a re-encode: the video is copied through, not compressed again, so it's a lot cheaper on the server than a full transcode and the picture is untouched. My own library is about 96% MKV and all of it plays this way, so if you've got a specific file that won't start, that's not the design and I'd like to hear about it — tell me the codecs and I'll dig in. Staying on the native player is a deliberate trade. It's where the system track picker, the chapter menu and the rest come from, and having the server do the container work is a cheap price for it.

only thing is your app dont play .mkv files due to using native player and most rips are in mkv container good job on the app keeep up the good work

Well I installed CDisplayEX, Challenger Viewer, ComicScreen but it did not work when I try to open from emby. I tested adroid.intent.action.VIEW with a local file over adb and I could open the file but in emby I could not. I used this instruction adb shell am start -W ^ -a android.intent.action.VIEW ^ -t application/x-cbr ^ -d "file:///storage/emulated/0/Documents/file_1.cbr"

A correction to my own post, and it goes in Emby's favour, so I'd rather put it up than leave it standing. I wrote that Emby was sending real HDR and simply not describing it in the manifest, and that the transcode came out 8-bit with visible banding. Both of those are wrong. I re-ran the same measurement today against the same Emby version, and what arrives is a proper tone-map to Rec. 709 — on the HDR10 title and on the Dolby Vision one alike. The manifest carries no HDR label because there is no HDR to label. That is Emby doing the correct thing. What I had actually caught was a fault on my own server: tone-mapping was failing there in a way that left the HDR tags attached to a picture that was no longer HDR, and I read the tags rather than the picture. The same Emby build handles it correctly now, so that was my machine and not the server. What doesn't change is the limitation I posted about. With Emby, Atrium still shows SDR, for the same reason as before: the manifest doesn't describe the dynamic range, so tvOS never switches the TV into HDR mode, and asking for HDR anyway would only mean HDR content on a display that stays in SDR. Asking for SDR is the honest option, and it's what the app does. For anyone who wants the actual measurements, that side of it belongs in the developer section — I'm posting the details in topic 149003.

I guess i have the same issue. The first screenshot with the "Black Samson" album creates a new "Wu-Tang" artist in emby. Musicbrainz correctly links "Wu-Tang" to "Wu-Tang Clan". The tagging in MusicBrainz seems correct to me at a first glance. Is this something emby can please fix? I have only noticed this issue with emby.

You were right about the route, and I checked rather than take it on trust — Moonfin direct plays these files and the device does the remux, exactly as you described. The approach works. It isn't the one I want for this app, though, and that's a goal of mine rather than a verdict on the engine. What I'm building leans deliberately on two things: the native tvOS player, and the server's own stream. No bundled engine, no external dependencies. That's a line I've drawn for myself, and it's why the app behaves the way it does — the system track picker, the system chapter menu, all of it comes free as long as I stay on the platform player. That combination already gives me real HDR wherever the manifest describes the stream. Here it doesn't yet, and that's the whole of the gap: VIDEO-RANGE and CODECS on #EXT-X-STREAM-INF, and the player handles the rest by itself. On the Dolby Vision point — playing the media playlist directly is the one thing I can't do, because the master is where the display switch comes from. Skip it and the TV never leaves SDR, whatever the segments contain. Still curious which HLS problems you ran into, if you get a moment.

Here some log files. embyserver.txt embyserver-63923173689.txt embyserver-63923212800.txt hardware_detection-63923173758.txt

Hi, when i use emby for playback it overheats my phone , when enable play with external player (vlc player) it doesnt overheat. Android verion 15 Emby 3.5.36 and 3.5.45 is anyone having this issue? Cheers

And what firmware version do you have now on the G5?

Meanwhile, I can confirm that it works on my 425. Just tried with a movie which is h265 to transcode it to 720p 4Mbit. Without Transcode for x25 installed.: 8-9 fps. After installation: >100 fps.

Why would you point it at Emby’s manifest though? The engine will ingest media files directly (mkv, avi, ts etc) so as far as the server is concerned, you’ll be direct playing via http. The engine will do what the server does (mkv to fMP4 + HLS to AVPlayer) directly on device and where not possible due to an older or unsupported codec, it will use ffmpeg software decode. Also, AVPlayer does DV to HDR to SDR tone mapping natively during playback. You don’t need to transcode to play DV on an SDR monitor (just need to skip the master playlist and play the media playlist directly instead). Lots of apps already use AetherEngine like Moonfin, Plezy, Silo, Sodalite… etc. I use Moonfin for Emby and Sodalite for Jellyfin. I do hope the web client gets better with HLS though as I prefer it to third party apps. It’s more power efficient on mobile.

Thanks, but doesn't seem to work for AppleTV

Is this comming to fairphone 5 android 15 ? i am still on v3.5.36 and there arent any updates available on the app store.

And if you have a file with TrueHD, can you also confirm whether it plays fine (no freezing) with just an audio remux and not a full transcode? Thanks

Can you please do a quick test for me? You mentioned previously that if you play a file with a DTS track it freezes after 10 seconds, but if you then change the quality or do a double playback correction the it plays fine (just with crap video). Can you please start playback with one of these files, let it freeze, then drop the quality enough so that it transcodes and starts playback, then please send me the server log, ffmpeg remux log and ffmpeg transcode log for that test? I just want to try comparing something against the old logs. Thanks

Does it really matter how I have it setup? Maybe its the way I want it to be. I mean either way it should work right? Honestly I really think you guys arent seeing the points that are being made. This really has nothing to do with what I am saying... Things are being misidentified Emby is not going to the correct sections of the MovieDB and TVDB to correctly identify shows.... It goes to the movie section regardless if you have it setup as a TV show or movie... I showed the example in a previous post with images. Having to re-do all of your collections when moving things to a newer drive stinks Be nice to have a feature where you can mass select things to change images instead of having to do them singally. It shouldnt matter how you want your TV shows setup...

Bonjour à tous, ce matin impossible de me connecter. Ça m'indique que le serveur est introuvable et/ou peut-être même inexistant. Quelqu'un peut m'aider? J'ai redémarrer J'ai supprimé l'application et recommencer Ca ne fonctionne toujours pas

Hello, after migrating my database from DS918 to DS425 and copying all movies to the 425, lots (if not all) movies miss metadata (pictures of actors), see attachment. I already tried to update the metadata of the whole library without success. I have to update each movie individually in order to get the missing data. Whats wrong here? Emby Premiere Server 4.9.5.0 Regards, Jens

Yes I have tried changing it but like I said, for some reason its only certain TV shows. Like He-Man is misidentified as the new movie and automatically uses the metadata from that for some reason. Try it.... Doesnt matter what setting you use when it is misidentifying shows and movies. I dont think you are following what I am saying. Go back to the posts I mentioned about the TVDB and MovieDB are not going to the correct sections of the site to identify the shows. Try it... I even included images.

That's fixed in the next release. Thanks

My files are sorted in directories according to collection. Different collection, different directory. The movies are setup as movies and TV shows as TV shows. I have 14 different libraries.

In Continue Watching row, Season Premieres get additional/duplicated badge top-left (seems like default position-default size), although setting is Extra Large Bottom centre and episode images themselves do not have that extra badge. Season Finales are okay.

Thanks for the pointer — I hadn't come across this one, and I went and read it properly, because I wanted it to be the answer. For my case it isn't, and I'd rather be precise about why than vague. Its README is explicit that a non-live remote .m3u8 handed to the loopback path gets rerouted onto the AVPlayer bypass: the bundled FFmpeg is built without network support, so the playlist can't be demuxed locally, and as they put it, remote HLS is AVPlayer's native domain anyway. That's a reasonable call rather than an oversight — but it means that pointed at an Emby transcoding manifest, the engine hands the same attribute-less #EXT-X-STREAM-INF to the same AVPlayer I'm already using, and the display stays in SDR for the same reason. The on-device remux is real; it applies when the source is something FFmpeg can open, not when it's already a remote HLS playlist. Where it would change things is by a route I hadn't considered, so the pointer was worth it anyway: skipping the HLS path altogether and direct-playing the original file. Once the CodecProfile uses the range spelling Emby actually compares against — the literal "HDR 10" from the MediaStream, with the space, on Property: "VideoRange" — Emby stops deciding to tone-map and offers direct play on these titles. I couldn't use that, because AVPlayer won't open an MKV. An engine that demuxes with FFmpeg and decodes with VideoToolbox can. So the value would be as a way around the manifest rather than through it, with the HDR coming from the original file untouched: 10-bit, and the Dolby Vision RPU still in place. I've written that down as a real option. It isn't a small one, to be fair to it. LGPL-3.0 with an App Store exception — well drafted, and it does cover the store's signing and re-linking restrictions, but only for the binary; the source obligations stay. Bundling FFmpeg. And on that path subtitle rendering moves out of the native tvOS picker and into the app's own overlay, which is a chunk of work I've already done once. It's a question for a later version. It's also why the two attributes are still what I'd rather have. VIDEO-RANGE and CODECS exist precisely so a client doesn't have to carry its own demuxer to find out what it's being sent — any client using the platform player benefits, and only the ones shipping FFmpeg can route around their absence. On "Emby's HLS implementation still needs some minor improvements" — which ones did you hit? The two I ran into are that the range value loses its space somewhere between PlaybackInfo and the transcoding URL, so the manifest generator never matches it; and that putting the space back by hand does produce VIDEO-RANGE=PQ, but then the segment endpoint answers 400. I owe this thread the full measurements on both and will post them. If you hit the same things from a different pipeline, or something else entirely, I'd like to know — you've clearly looked at this more recently than most.

@vdatanet Have you ever thought about using the open source AetherEngine? It does on-device remuxing to specs-complaint Apple-friendly HLS and uses the platform-native AVPlayer with all the privileges that entails. https://github.com/superuser404notfound/AetherEngine That said, Emby’s HLS implementation still needs some minor improvements (it’s way better than when i last tried it years ago). Any improvements would be welcome.

Just wanted to say a huge thanks for this! I only ever use the native player on my Apple TV and the emby implementation - while pretty good - is missing a few things when it comes to 4K playback. Regarding iOS playback - I use the safari web interface and that uses Apple's native player on iPad / iPhone - so that works and looks great. No need for a seperate app - keep focus on making this the best Native Apple TV Emby client (Emby team - maybe implement this app into the mainstream one? With blessings from the author of course )