EmbyVision OCR GPU Edition, CPU Edition Credits Detector new plugin: Beta

[EncryptedCity 18]

Hi ebr,

Thank you for the follow-up and for clarifying that no one was trying to target me. I appreciate that.

I wanted to add a few important technical details that were not fully covered in my previous reply, because they directly explain both the similarities people noticed and why the two plugins should never be installed at the same time.

**On the original development path**  
When I started this work, my goal was to create improved detection engines (particularly better OCR and proper AV1 support) that could plug into Yocker’s existing EmbyCredits plugin. That is why some of the high-level concepts, terminology, and even a few UI patterns ended up looking familiar — I was deliberately trying to stay compatible at first.  

As development progressed, two things became clear:  
1. Yocker’s plugin was not handling my large AV1 library reliably, and  
2. The architectural changes I needed (especially around frame extraction, parallel processing, and the OCR microservices) were substantial enough that it made more sense to build a complete, independent plugin.  

That is how EmbyVisionCredits came to exist as a separate project rather than just a set of engines for EmbyCredits.

**What is actually original work**  
- The CPU and GPU OCR microservices were written from scratch (they are separate GitHub repositories).  
- The detection pipeline was largely rewritten to handle AV1 correctly and to support the performance characteristics I needed.  
- The plugin’s internal state handling, event registration, scheduled tasks, and overall architecture are my own.  

There is inevitable functional overlap because both plugins solve the same problem (detecting end credits and writing the markers Emby understands). Functional similarity does not equal the same implementation.

**Why the two plugins must not be installed together**  
Even with unique GUIDs (which I have already changed), the plugins still conflict at a deeper level:

- Both register for the same Emby events (`ItemAdded` / `ItemUpdated`).  
- Both maintain pending-episode queues and state.  
- Both extract frames and write the same chapter/segment markers that Emby uses for “Skip Credits”.  
- When both are active they can overwrite each other’s markers, fight over temporary files, and produce unpredictable results.  

This is visible in server logs when both are present — both start their own “Credits Detection Service” and both load the same pending episodes. It is a classic case of two plugins claiming ownership of the same subsystem. Users should choose one or the other, never both.

I have already updated my documentation and releases to state this clearly.

I remain fully respectful of the MIT license under which EmbyCredits was released, and of Yocker’s original work. Multiple independent implementations of a credits detector can and should exist, just as multiple implementations of other media tools exist. My intention has never been to diminish or claim credit for the foundational work Yocker did.

Thank you again for taking the time to look at this carefully. I’m happy to provide any further technical clarification if needed.

Best regards,  
EncryptedCity

Edited 1 hour ago by EncryptedCity