All Activity

just adding new movies and tv shows library, it's a new emby setup. after it's done i try to refresh metadata on tv shows library and the crew tmdb id still not there.

Yes it's running, like I said I can still access it directly via MyCloud and through Plex. I don't use a dynamic IP on the server. It's only Emby that says it's unable to connect.

Are you sure the server is running? Does your server machine ip address change regularly?

It seems to be working a lot more consistent now but maybe 1 of 15 times it will just go silent after you ask it to play the next song, and the only way to get it to play again is changing it to Amazon music and then switching back. Also, is there a way it can let you know if it reached the end of the playlist when you ask it to play next song? It was something Plex plugin had that was pretty nice. As alway appreciate your hard work hatharry!

Forgive my ignorance but, how do I do that when I can't connect to the server?

as of now its been almost an hour sense log said it was being refreshed but they are still not updated / available to watch.

to have the new episode shown in emby so i can watch it.

what update were you expecting?

the fact that it never updates the shows in library. i run plex and emby. plex will show new shows added in about 1-3 minutes if not instant. emby is always hours. dont think its ever updated the show in under 4-5 hours. 2026-08-06 05:19:32.624 Info LibraryMonitor: Season 5 (/data/media/anime/Battle Through The Heavens (2017) [tvdb-337284]/Season 05) will be refreshed. i did see this that it said its refreshing but never updates.

Hi there, what exactly makes you think it isn't working?

anyone mind helping me figure out why rmt doesnt work. for reference it has never worked. 4+ years lol. but im using emby more and its very annoying as it can take up to a day to update newly added items. have searched but found no info on what to look for. most rmt threads only have ppl asking for logs but never say what they are looking for. here is my latest logs as i just added a few new shows.embyserver.txt no network drives all are local.

Hi Luke! Let's try to make it clearer. Does Emby have a planned release date for its HarmonyOS app (Huawei OS)? And what is that date?

I mean what exactly did you do in the user interface?

I have a shield pro.

Honestly & "sadly", since I switched to Shield Pro, I don't have ANY problem anymore. The difference is real. But it's another device to buy... (this is the sad part - I could get a second hand with a reasonable price)

To be fair, I probably wouldn't have started this project if it had already met the needs I was trying to solve. I wanted reliable OCR support, dedicated CPU/GPU services, improved detection, and a different architecture, so I ended up building those pieces myself. It wasn't about replacing EmbyCredits for everyone—it was about solving the problems I was running into and then sharing the result with the community.

Progress so far after running about an hour.

As said i don't mind, EmbyCredits is made under the MIT license so you can basically do with it what you want. I just wanted to know if it was at least originally EmbyCredits. Open Source would have been good though.

Thanks for clarifying. I understand why some similarities stood out, especially with the UI elements and the tracer naming. To answer your question: yes, it started from the EmbyCredits foundation, and I should have been clearer about that relationship. The goal was never to present it as if the original concept came from nowhere or to hide the connection. It was developed as an extension/evolution of the idea, while also remaining compatible with the original plugin. A lot has changed since then. The OCR service, CPU/GPU OCR support, detection engines, processing logic, configuration system, and many other components have been redesigned, rebuilt, or expanded. The detection engines themselves were developed from scratch rather than simply being copied over. The backend is also completely different in terms of architecture. It now uses dedicated Docker OCR services: CPU OCR Edition: ~1.89 GB container image GPU OCR Edition: ~8.34 GB container image Separate CPU and GPU endpoints GPU edition uses CUDA acceleration with PaddleOCR Dedicated OCR microservice architecture instead of relying only on the plugin process It was also listed under Tools & Utilities because these services are designed to work with EmbyCredits as well. Users can use the OCR services with the existing plugin or use the expanded project alongside it. Both can be installed simultaneously. The tracer naming similarity is a fair point — I should have picked a more unique name there to avoid confusion. I appreciate you bringing it up. Hopefully this clarifies that this is not simply a reskin, but an expanded implementation built from the original concept with a significantly different backend and additional functionality. https://github.com/encryptedcity/embyvision-ocr https://github.com/encryptedcity/embyvision-ocr-gpu

You're right — the server does populate it, and I can now show you exactly why it never reached me. There are two separate problems, one of them mine. Mine first. My CodecProfile was written with Jellyfin's range enum names (HDR10, DOVIWithHDR10…). Emby compares against the literal VideoRange string on the stream, which for these files is "HDR 10" — with a space. Your log says so plainly: Profile: VideoCodecProfile, DirectPlay=false. Reason=Atrium tvOS.VideoRange Condition: EqualsAny. ConditionValue: SDR|DOVIWithSDR|HLG|…|HDR10|…|DOVI So the server correctly concluded this client can't take HDR, and went off to tone-map (tonemap_opencl=tonemap=mobius). Omitting VIDEO-RANGE in that situation is the right thing to do, and my earlier post was wrong to read it as a missing attribute. Apologies. Now the part that isn't mine. When I fix the profile to "SDR|HDR 10|DolbyVision", PlaybackInfo accepts it — it even offers direct play for the title. But the TranscodingUrl it hands back has lost the space: Sent in the profile: Value = "SDR|HDR 10|DolbyVision" Came back in the URL: hevc-videorange=SDR,HDR10,DolbyVision And the manifest generator compares that against "HDR 10" again, so it fails a second time and tone-maps anyway. The two halves of the same request disagree with each other. Putting the space back by hand is enough to prove it. Requesting the same master playlist with hevc-videorange=SDR,HDR%2010,DolbyVision: #EXT-X-STREAM-INF:BANDWIDTH=26581586,AVERAGE-BANDWIDTH=22151322,VIDEO-RANGE=PQ,RESOLUTION=3840x1600,FRAME-RATE=23.976 There it is. VIDEO-RANGE=PQ, exactly as you said. So this is a serialisation bug, not a missing feature — and from a client's point of view it's unreachable, because the value that passes the profile check is the one the URL builder mangles. Two things still don't work even once the attribute appears: The segment endpoint throws. With the space present in the URL, /videos/{id}/hls1/main/init.mp4 returns HTTP 400 with an unhandled System.ArgumentException: The index is equal to or greater than the length of the array, or the number of elements in the dictionary is greater than the available space from index to the end of the destination array. So the correct value breaks the other end of the same round trip. That's why no client can work around this on its own. CODECS is still absent from the #EXT-X-STREAM-INF line even when VIDEO-RANGE=PQ is there. That one matters for a different reason: it's what lets a player rule a variant in or out before downloading anything, and on Apple platforms it feeds the initial decision alongside the range. Environment, in case it's version-specific: Emby 4.9.5.0 on Linux from the .deb, source is HEVC Main 10, yuv420p10le, bt2020nc/bt2020/smpte2084, in an MKV (so the container forces the HLS path rather than direct play). One last observation while I'm here, since it's the root of my original mistake: the ProfileConditionValue enum only exposes VideoRange, so a client has to match on a free-form string whose exact spelling — spaces included — isn't documented anywhere I could find. Meanwhile the stream itself carries ExtendedVideoType (Hdr10, Hdr10Plus, HyperLogGamma, DolbyVision) and ExtendedVideoSubType, which are properly typed but can't be used in a profile condition. Being able to condition on those would have made this whole class of bug impossible. Happy to re-test any of this against a fix.

Because it's not really hard to spot the similarities. Many of the UI elementals are precisely the same. Even the tracer feature which i gave that name because i thought it would be a fun and original name to give it. This is from EmbyCredits. Plus many more examples. As said, i don't mind. Just want clarification if it's EmbyCredits underneath.

I wanted to share a quick demonstration of the progress so far. The credits detection is working extremely well and is detecting credits across my library with a very high success rate. In this video, you can see the detection process running and finding credits successfully. The only ones being skipped are items that already had credits markers detected previously, which is expected behavior. This is a huge step forward, and I’m excited to keep improving it with more testing, optimizations, and additional features. EmbyVision OCR Credits Detector video.mp4

Has this ever been corrected? Is it just not going to be?

So I ended up using the web browser for a couple days until it started showing choppy video. I uninstalled the server and restored from backup but had the same issues. I reinstalled again without backing up which seems to have fixed the problem. Lost all my settings and show progress though. Had to reinstall emby for windows on both PCs for them to load properly. So it doesn't seem like it was an issue with just one of them.

EmbyVision OCR GPU Edition, CPU Edition can also be installed alongside the original EmbyCredits plugin, so users can run both independently if they want to compare functionality or migrate at their own pace. You can also install both the CPU and GPU containers simultaneously.