All Activity

Hi @CBersand @FrostBytethanks for testing this functionality. I appreciate it. So I went on testing to compare the ATV version and the Android version. Shield TV Pro (2019) settings: Playing X-Men Days of Future Past with DTS-HD MA 7.1. The results are below. ATV version: SONOS app: Android version (option to convert to DD in the app setting is disabled): SONOS app: Android version (option to convert to DD in the app setting is enabled): SONOS app: One thing to note: please ignore the subtitle burn-in with hardware from the diagnostics plugin as it is not relevant. It has worked for me flawlessly so that is not the cause. I just want to focus on this comparison between the ATV and Android version. I hope this is more clear now what issue I am facing. If you need more details, please let me know.

Yes but people are paying for this product, so the money should fund more engineers if they have too much workload. waiting 6 years for basic features is not acceptable, as paying customers we have every right to expect better

Hello - any progress on this? Every day this week I've had to delete the American Experience documentary "The Vote" from my recording queue since I recorded it 6 years ago when it first aired, but which is apparently in heavy rotation this week. Maybe add an option for "I already have this."

I have this same issue.

any updates on this issue.

While I'd also like to see this feature added, Emby seems to have many more features than Jellyfin. Is anyone seeing that Jellyfin has caught up? They do have some different features like watch together, but they're still well short of what Emby has....I think.

I hinestly think emby don't have very many devs that build for it and fix things. That is why it takes so king for things to happen on emby but that is my opinion.

New Emby server beta release, v4.10.0.22. Release Notes

Thanks for your reply, I'll check that behaviour

Hi, I have read a lot of posts from various websites and forums on how to do this, but I cannot get it to work for me. - I have Emby running on a NAS (works perfectly internally) - I have setup Caddy in a docker container on a RPi - I have a domain with Namecheap I have forwarded emby.my_domain.tld to my IP from Namecheap's advanced DNS tab: Checking this is pointing correctly: curl -s "https://cloudflare-dns.com/dns-query?name=<mydomain>&type=A" -H "accept: application/dns-json" gives: `{"Status":0,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,"Question":[{"name":"<mydomain>","type":1}],"Answer":[{"name":"<mydomain>","type":1,"TTL":1472,"data":"<correctIP>"}]}` My docker compose for caddy: services: caddy: image: caddy:2-alpine container_name: caddy ports: - "80:80" - "443:443" volumes: - ./caddy/caddyfile.json:/etc/caddy/Caddyfile - ./caddy/data:/data - ./caddy/config:/config environment: - TZ=Europe/London restart: unless-stopped volumes: caddy_data: caddy_config: My Caddyfile (IP is my NAS): { <myemail> } <mydomain> { reverse_proxy 192.168.1.64:8096 } I have port-forwarded :443 to :443 on my Pi. My Caddy logs have two warnings 2026-08-01T07:55:31.141155000Z [caddy] {"level":"warn","ts":1785570931.1406991,"logger":"http","msg":"HTTP/2 skipped because it requires TLS","network":"tcp","addr":":80"} 2026-08-01T07:55:31.141758000Z [caddy] {"level":"warn","ts":1785570931.1407423,"logger":"http","msg":"HTTP/3 skipped because it requires TLS","network":"tcp","addr":":80"} ...complete logs: 2026-08-01T07:55:31.114360000Z [caddy] {"level":"info","ts":1785570931.113894,"msg":"maxprocs: Leaving GOMAXPROCS=4: CPU quota undefined"} 2026-08-01T07:55:31.115133000Z [caddy] {"level":"info","ts":1785570931.1139398,"msg":"GOMEMLIMIT is updated","GOMEMLIMIT":1787977728,"previous":9223372036854775807} 2026-08-01T07:55:31.115279000Z [caddy] {"level":"info","ts":1785570931.1139512,"msg":"using config from file","file":"/etc/caddy/Caddyfile"} 2026-08-01T07:55:31.115380000Z [caddy] {"level":"info","ts":1785570931.113958,"msg":"adapted config to JSON","adapter":"caddyfile"} 2026-08-01T07:55:31.116229000Z [caddy] {"level":"info","ts":1785570931.1158042,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//localhost:2019","//[::1]:2019","//127.0.0.1:2019"]} 2026-08-01T07:55:31.116563000Z [caddy] {"level":"info","ts":1785570931.1162255,"logger":"http.auto_https","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443} 2026-08-01T07:55:31.116812000Z [caddy] {"level":"info","ts":1785570931.116303,"logger":"http.auto_https","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"} 2026-08-01T07:55:31.116971000Z [caddy] {"level":"info","ts":1785570931.116306,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x7f71341600"} 2026-08-01T07:55:31.128901000Z [caddy] {"level":"info","ts":1785570931.1284323,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"} 2026-08-01T07:55:31.129253000Z [caddy] {"level":"info","ts":1785570931.1289337,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]} 2026-08-01T07:55:31.141155000Z [caddy] {"level":"warn","ts":1785570931.1406991,"logger":"http","msg":"HTTP/2 skipped because it requires TLS","network":"tcp","addr":":80"} 2026-08-01T07:55:31.141758000Z [caddy] {"level":"warn","ts":1785570931.1407423,"logger":"http","msg":"HTTP/3 skipped because it requires TLS","network":"tcp","addr":":80"} 2026-08-01T07:55:31.142140000Z [caddy] {"level":"info","ts":1785570931.1407516,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]} 2026-08-01T07:55:31.142695000Z [caddy] {"level":"info","ts":1785570931.1407676,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["emby.jchh.uk"]} 2026-08-01T07:55:31.142914000Z [caddy] {"level":"info","ts":1785570931.1416066,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"} 2026-08-01T07:55:31.143196000Z [caddy] {"level":"info","ts":1785570931.142191,"msg":"serving initial configuration"} 2026-08-01T07:55:31.145257000Z [caddy] {"level":"info","ts":1785570931.1448421,"logger":"tls","msg":"storage cleaning happened too recently; skipping for now","storage":"FileStorage:/data/caddy","instance":"4a0eecea-9c66-4011-bcd9-6bd73acd8cc2","try_again":1785657331.1448386,"try_again_in":86399.999998667} 2026-08-01T07:55:31.145491000Z [caddy] {"level":"info","ts":1785570931.145117,"logger":"tls","msg":"finished cleaning storage units"} Can someone please advise me?

Everything works fine so far.Rhat maybe why no feedback so far. Only issue I have is say I am scrolling my library and are at say albums start with the letter L and switch to the map I android auto and than move back to the app it does not remember the position it goes back to the first album, so I than have to scroll again to find what I want. Same if I back out of an album to the library it resets to the first item and not the album I was playing if that makes sense

?????

Maybe this part won't work? Was it a link before?

Hi, there currently isn't an option for this. What's the reason to want to limit them?

im like a hair away from just saying **** and going to jellyfin. i have to move my media stack to a dell PowerEdge R660. like this is taking way too long and should not be this hard to add. plus its free and seems to have more of a active development for plugins and 3rd party programs that enhance it. like a lot of the programs for plex. need to see if they dont have the same problem emby has before i switch tho.

Hi, what version number of the app are you testing with?

Ok, wife came back from vacation. Emby does not delete the downloads off of her iPhone after transferring them. I double checked by deleting what she already had, then redownloading everything back to her phone. It is still there after a full 24 hours. It seems as though emby is only deleting off of android devices. Attached is the latest log from my android device, in the hopes that it might help to shed light on what is happening. emby_android_1785547164509.txt

PageUp/PageDn are not working properly in the guide. They do work properly in the Android version. PageDn seems to maybe go one page and then puts you back to the top of the guide.

Hello everyone, I have been using Emby Premiere for about 3 years with an 80-device license, and during all this time it has always been more than enough for my server. However, recently I have noticed that my Emby Premiere device limit is being reached much faster than before. The number of users and the general usage of my server have not changed significantly, so I am trying to understand what could be causing this. Has there been any recent change to the way Emby Premiere devices are counted or registered? For example, are there any client actions or features that may now cause a device to be counted as a Premiere device when they previously did not? I would appreciate any information about whether the device-counting system has changed recently, or if there are any other factors that could explain why my 80-device limit is being reached much faster than it used to. Thank you!

Is this the beta for server or the Windows App? I can't figure out how to get the beta for the Windows App. None of the beta links to the Window store work. And I can't find the 'beta portal' to join.

The Roku will start blinking the white status light when it has no internet. At that same time any app launched that has any internet functionality (such as trailers, and some plugins on Emby) then it will also trigger a warning that the app might require internet. You can choose "launch anyways" and it will launch Emby anyways without internet. Then once you start to play an item the Roku will send video start/stop beacons over the internet indicating how long it takes the app to start playback and the URL playback is coming from. Without internet these beacons being sent may cause slight delays before playback begins. The URL they see from your Emby server is an internal URL with an ID playing stream.mkv or similar. They do not see the filenames, paths, mounts, anything else. The reason Roku does these beacons is to BAN any apps playing from blacklisted URL's. It isn't meant for Emby servers. It is meant to stop someone creating an app that steals content from a CDN. They would know you are. They would BAN that app and block that app from being installed on any Roku. Remove the app from any Roku that previously installed it. Any user having that app installed would have developer mode removed from their Roku to prevent them from being the one that made the app from doing it again with that Roku device. It blocks your entire developer account and all your Rokus serial numbers attached to it. They would have to create a new account and buy new Rokus to ever develop on Roku again. So at the start of any playback Roku is sending these beacons. They also send them whenever media stops playing. To keep metrics for how long each streaming app keeps their users inside the video player. Roku keeps track of total streaming hours for each app. Then you can see how popular everything is based on that metric. That is how their store works. So everything they are doing is to protect their store. I assume the same happens with Amazon. The Amazon fire sends beacons to track playback/URLs to ban infringing apps. You must send these beacons or they will BAN your app. This is completely normal since they own the store they make the rules. Since everything on Emby originates from your Emby server and nothing is played directly from online URLs this both protects you and Emby from infringing store policies.

Still not fixed, it’s been almost 6 months since this was broken…

I think we paying customers need to have a serious word with the Emby devs about progress

Has it really been six years?

I would love this