All Activity

Hi, yes we are working on improving this. Thanks.

Hi, I would go into user permissions and check what libraries the user is granted access to.

Emby server 4.10.0.29 currently only recognises & labels DV 8.1 and HDR10 I did an extensive set of tests with all modern HDR formats using Emby (Web Client running on Safari) and the following is missing: - DV 5, DV 7.6, DV 8.4 (all list as generic HEVC) - DV 10.0, DV 10.1, DV 10.4 (all list as generic AV1) - Dolby Atmos (lists at generic EAC3) I hope this is something that can be implemented in the future! Thanks for reading! I tried to use the old thread discussing this but it's locked: (feel free to reopen it and move this there) https://emby.media/community/topic/72953-add-dv-atmos-dtsx-hdr10-hlg-information-to-database/page/9/

@softworkzHappy to test when a version becomes available - mines waiting for that implementation.

When opening File Station on the NAS, it was located under NAS / Emby

Back again with another problem, it seems. A month or two ago I ran into an issue when I started up my Emby server (hosted on a laptop) and tried to watch something on my TV, in that while I was logged in and connected to the server, there was no media displaying, only my 'playlists' folder and the created lists within, but even checking them, absolutely no media visible anywhere. While troubleshooting online previously I noticed my TV, at some point, seemed to fully connect and displayed the media, and it even worked, so I assumed it might just an internet issue itself, maybe the files were just loading up on the TV itself, who knows? But I've run into this problem again and again, and sometimes it doesn't resolve at all, such as today. I had the day off work and decided to try and fix it, but to no avail, hence why I've once again had to come here asking for help with this specific problem. I start up the Emby server on my laptop, it runs fine, be it via browser or the desktop app. In both cases it shows the full media library (as confirmed via screenshots). I can access the internet itself fine using the laptop, there's absolutely no issue with that there. Then, if I try to access the same Emby server using my TV or another device (phone, desktop PC, the result is the same regardless), I get nothing more than a blank page with 'playlists' and nothing else. I've tried looking for help online, I tried the old faithful method of completely removing the media libraries and re-syncing, but that hasn't changed anything. I futzed around with internet connections, tried making the media folders 'shared' to be accessed directly by my PC, still hasn't done anything to help. I've even tried the most basic of steps, shutting the laptop down completely and starting it up again, even double-checking it was connected to the internet and troubleshooting for any problems, but I've found absolutely nothing changed in either case. The laptop is connected to the internet, the media libraries are readily accessible through the laptop, but when it comes to actually linking any other device to the same server, the media libraries cannot be found. To confirm, regarding the attached images, it IS the correct server, I have triple-checked this and even 'removed' the server and re-added it to ensure it's DEFINITELY correct, and I am logged in to the correct account on all devices (as confirmed with the visible avatar in the top right corner of both screenshots). I also ran a quick test by putting a few generic video-files I had lying around into a folder on my desktop PC, adding it as a library, and checking it. It showed as watchable on the desktop PC and my TV, but not on the laptop. I have no idea what the problem is, nor how it even began. One day I switched on my TV and accessed Emby, only to find nothing available to watch. The best I can think to even try and describe it is, it's like the laptop is just in it's own separate sector, where the server is there, but the media files (despite being confirmed accessible and visible on the laptop itself) aren't accessible to the rest of the world. If I try to access the server on any other device, it simply cannot find the media files. And, as I've said before, it DID work before, this problem sometimes resolved itself, it even worked fine as of less than a week ago. I'm typing this to post on 05/09/2025, I was able to watch some TV episodes on 02/09/2026, rolling over into the morning of 03/09/2026. Since then, it's back to not detecting any playable media files, despite verifying that both my TV Shows drive and my Movies drive are plugged in, fully scanned, and completely accessible via the laptop they're attached to, and where the Emby server is being hosted from.

Awesome - will test daily - I see 3.5.55 is available now. I can report the current (previous) version still exhibits the issue as fully as I can attest to.

Humming along now, but the ETA is high, I assume because the "QI" TV series which is using Chromaprint (which was failing before your fix)? These episodes do have both credits and timed text subtitles In this example, the credits actually start at 29:00, but EmbyCredits says "00:27:56 / 00:298:26"

What is the path to it?

The folder "Emby" which was a top level folder on my Nas

Oh, and this might have been mentioned on another thread, but when in TV mode there's an "on page" keyboard that's awkward/slow to use. Why can't it just like everywhere else with just a regular text input box and pop up the assigned system keyboard from there? Yes, it can cover the results while typing, but the user should be able to escape out of the keyboard popup to see them and then hit a button again to pop up the keyboard for more editing if needed.

Hi, what exactly did you delete?

In a bit of a hole here. Emby was running and working fine a few hours ago. I downloaded a few plug-ins, restarted Emby and it's never come back online. After losing patience, I deleted everything from the Emby folder, uninstalled Emby, restarted the NAS and reinstalled Emby (emby-server-synology7-mono_4.9.5.0_armv7_legacy) Emby is installed on the NAS, after setting it to run, it says "manually stopped" after a few moments. Sometimes it does Run, but I can't connect to the web interface. Desperately hoping someone can help, please!

Hi, Emby doesn’t decide to delete info out images.

How have you configured your Emby user audio settings? That’s what matters more than what track is marked as default in the file.

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.