All Activity

yes, agree, HDR10+ are still problematic. Any work to resolve this?

In the past, search was working with the LG App. Problems started when updating the Server to 4.9.1.90

I have countless sr.srt (and srp and hr and hrv) subs, not once have they been recognized as Hindi. Is it possible that those are hearing impaired subs, i.e. <moviefilename>.sr.hi.srt? Can you show the exact subs filename for that example?

Hi. If it is the same genre, there is only one image for it. You can edit images and give it whatever image you like though.

HDR10+ AND Subtitles, real struggle

Almost - one setting to flip first, otherwise the fallback never gets used. Install the plugin, then in its config page enable "Also insert markers into the media's existing NFO file" (it's off by default). That's what turns on reading the <markers> block Cheese's plugin left in your NFOs as a restore source. With that on, running the Restore task will: check for a JSON backup first (you won't have any yet, so it'll skip that), then fall back to reading <markers> straight out of the existing NFO next to each video. Same schema Cheese's plugin used, so it should just work without any conversion step. One thing worth checking first: make sure "NFO" is enabled under your library's metadata savers, and that the NFO files are actually still sitting next to your media (not just in Emby's internal metadata cache) - the plugin only reads NFOs it can find on disk next to the video file. One more thing worth doing right after: once Restore has pulled everything in from the NFOs, run the Backup task once too. That converts what it just read into this plugin's own JSON backups, so you're not relying on the NFO fallback going forward - JSON is faster to read and gets you the TVDB/IMDB-based matching (survives renames) instead of the NFO path just matching by filename.

Sry Luke but i see 100% translate in Italian...so what you need for Alexa in Italian ? But we cannot use Alexa in English while I wait for it to be ready? or is there a trick to using it in English? Hispa

I have two libraries: TV Shows and Movies, both set to their appropriate library type. In the Movies library, when I go to Genre - the images shown in the main window include covers from what are clearly TV Shows, and the same for the genre menu in the TV Shows, with lots of movie covers. Is this normal? When I click on the respective genre categories, they show TV Shows only / Movies only as I would expect, and do no include the errant entries shown in the genre category thumbnail. I have deleted the images, told it to re-scan the artwork - and the same thing - artwork from a totally different library is included. I have taken a quick look at the DB and I have found movies showing as: "isinmixedfolder=0" as expected... but the TV Shows, the containers are fine, but the individual episodes show: "isinmixedfolder=1" I am concluding that "isinmixedfolder" simply denotes that the folder contains different video files, not different versions of the same content... so fairly sure this is not behind the weird thumbnail generation of genres for the two different libraries being "mixed" up. Are the thumbnails being mixed by design, or is this a potential bug? Emby Server: v4.9.5.0

Have you tried the 3-letter ISO standard srp to see if works any better?

@bubanecesitas tener una libreria de libros

HI @arrbee99the web app uses the Desktop profile if visited from desktop and mobile is visited from your phone, there is no web only profile. Hi @GrimEvilsorry for the late reply been working the emby related issues submitted on github first. There are 5 different versions of the media bar, my version of your spotlight. At the time I couldn't find an API equivalent on Emby for the spotlight and even then it's a custom feature since Jellyfin doesn't have native media bars either. The playback controls are disabled for intros, our version of your trailer, because people were complaining about it since intros are usually short and it blocked their view. Interesting about the subtitles, it SHOULD be displaying, let me look at it today

Sorry for the late reply, but from current testing everything looks to be working fine with no errors or other issues, thanks

Hey guys. I've had this issue for a while. So, I download Serbian subtitles, they have .sr.srt extension. But for some reason, in most cases (not always) they are recognized my Emby (both regular Android and Android TV apps) as Hindi, as the screenshot suggests. Any ideas why this happens? Also, a suggestion. Why doesn't Emby have a fallback option for subtitles, like many other media players? I mean, if one subtitle language is not available, I would like the next best thing. Many players have this option.

It seems to be playing by track number now! Thanks!

Hey Luke, Any news on mTLS support? All of the exposed services I'm running at home are using mTLS, except for Kodi. Home Assistant and Immich are good examples of android apps which work well with mTLS.

Being more than a bit generous saying only 3 weeks.

Hi everyone. Any ideas what the problem might be? Emby Server version 4.10.20. For playback, I tried the Emby Android and Emby for Android TV apps—the latest versions from the Google Play Store. I tested about six different movies; all used the AV1 video codec and Dolby Atmos TrueHD audio. In all cases, the streaming boxes were connected directly to a Samsung HW-930F soundbar. The boxes I tested were the Xiaomi Mi Box 3, Ugoos SK-01, and Homatics Box 4R; the problem was the same on all of them. Between the 55- and 65-minute mark, a severe audio-video desync occurs (a lag of about 2 seconds). If I watch the same movies on the Google TV Streamer, there are no such issues—though that device doesn't output TrueHD audio. The problem only occurs in the Emby apps; everything works perfectly via Vimu and Kodi. I checked the server logs, but there are no errors.

Can you update the Release Notes for v3.5.41 please.

You can do the same in the Android app by hard pressing the enter button which pops up a menu with those options

@Luke

Potential new Emby User here, I finally wanted to make the switch from Plex to Emby and tried following the Migration Guide provided by Emby and I am completely frustrated. The guide says to "Install and setup Trakt Scrobbler in Plex and sync your watch history" -> Does not work, Trakt Scrobbler seems to be outdated since Trakt does not support non-https redirect URIs. Found another tool that works, got my watch status synced from Plex to Trakt. First annoyance solved. Then I try to import my watch status from Trakt to Emby and this also does not work. Next annoyance with no workaround. These are the exact problems that made me want to switch from Plext to Emby. Plex does not give a .... about the issues that users experience with their product, but since this seems to be the same with Emby, I guess I won't make the switch.

So to restore my backups from Cheese's plugin, I simply need to install your plugin and run the restore task?

Hi Luke, this version works with both .ass and .srt subtitles. What I have noticed is that Emby takes a while to start. The logo appears, it takes a bit, and then a "Connecting to server" screen appears, which is very brief. I'm mentioning this so you're aware in case you can improve it. Thanks to everyone.

v1.5.0 is out. Fixed a real data-loss bug. If a backup was written before intro detection had run (so it only had a Credits value, no Intro), restoring it would wipe out a correct Intro value that had since been detected live - the restore logic treated the backup as a complete replacement instead of a partial update. Found this while testing native intro detection interacting with existing backups. Fixed: each marker type is now merged independently, so a backup only overwrites the field it actually has a value for. New: auto-backup on manual edit. This answers the "what if I change it on purpose" question from earlier in this thread. Turns out ChapterApi, EmbyCredits, and Segment Reporting all bypass Emby's update event when saving a correction, so those edits were never being backed up automatically before now. The plugin now watches for edits from all three (plus Emby's own native intro detection) and backs them up immediately - no need to remember to run Backup afterward. One limitation worth flagging: manual JSON or NFO text editing isn't detected, only edits made through those tools' own interfaces. Both new behaviors verified at scale - dozens of episodes across several shows, mixing automatic detection and manual corrections, all handled correctly with no data loss. New setting: "Auto-backup on manual edit" (off by default, alongside the existing "Auto-restore" toggle). Release (with prebuilt DLL): https://github.com/guilty57/credits-intros-backup-restore/releases/tag/v1.5.0

According to my experiece, it would be very useful if Emby could warn the server administrator when attempting to delete a media item that is currently being streamed by one or more users. Would it be possible? Thanks!