All Activity

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.

It’s a fair question. It may look similar because it started from the same general idea and builds on the EmbyCredits concept, but it has been heavily modified and expanded. There are new components, including the OCR service, GPU/CPU OCR support, different detection options, new configuration, and a lot of changes under the hood. The detection engines have also been designed and developed from scratch rather than simply being copied over or rebranded. I’m a little surprised you were able to reach that conclusion only 23 minutes after the post went up though, since the documentation and changes are fairly extensive. I’d be interested to know which parts you looked at that made it appear to be just a reskin.

2.4.5 SSA/ASS subtitle rendering improvements Fix new folder view style on apple devices

Emby for Samsung TV: A new Release version is available Download Emby for Samsung TV Changes 2.4.5 SSA/ASS subtitle rendering improvements Fix new folder view style on apple devices

That looks like a reskinned EmbyCredits? Not that i mind, would just like to know for clarification sake.

to get image and bio, it's not populated because it's not have tmdb id, all crew like director and writer not picking up tmdb id when scanning on tv show library, actor is working fine though they pick up tmdb id.

Can you please post a strm file and the folder structure ok the external audio track please. Do you use native or addon mode?

what exactly did you try to do?

نفس الرد للاخت هيه كما الرابط

I checked again and works fine on my setup. Can you please show me a screenshot of your folder structure and send me one of you srt files for review please. Also a screenshot of your subtile settings on Emby server might help.

For those subscribed to this thread for updates, please switch to this topic now that we have it automated: Thank you everyone.

Hello Everyone, I am happy to announce that there is now a Beta version plugin that will detect credits in TV Shows. I originally posted in tools and utilities however since then I have made several improvements to the plugin. The plugins I posted in the tools and utilities were very early versions of EmbyVision OCR. They do support H264 and HEVC files but the latest version of this plugin now supports AV1 as well with CPU and GPU. I developed the software mostly for myself because of my large av1 library and limited tools available that will detect AV1 files for credits. I decided to share it because it is such a cool development. I realize that this may not be the only credits detector plugin and you are probably wondering, why you should install my version and test it vs the other? Because watching end credits is boring for most! The original docker containers for the tool are on GitHub. Pease see the posts in tools and utilities for information on installation and also there is installation instructions inside the plugin for the CPU and GPU docker containers. They use the same plugin. I have also used them with the original in store plugin for OCR detection. They are on GitHub and they do work with the plugin in the Emby forum however it is recommended to use them with my new plugin as it has been designed to work efficiently with them. This image is the OCR Detection working on AV1 files which is mostly what my library is composed of due to my transcoding them to AV1 with my Tdarr and handbrake method. It's easy to get started. I quite busy and I am not sure how much support I can offer for this plugin but you can find help in the debug logs and they will help you configure the plugin. it runs on Default settings for most servers. You will need docker for this. Feel free to leave comments and post your experiences with the plugin or ask for help, if I can't get to answering in time surely other people will be able to help you if you have questions. There is lots of documentation. Please read through it. The software also works well on Unraid. Thank you. Please watch the video. I uploaded one. EmbyVision by EncryptedCity.mp4 EmbyVisionCredits.dll