TV Show Status — TMDB-powered Returning/Ended/Cancelled badges for series

[ginjaninja 652]

On 29/08/2026 at 16:42, Blueskies278 said:

Unfortunately per-episode on a shared image, and per-user can't be done. but I will still add it to the roadmap.

Hi @Blueskies278,
I am struggling to make sense of the options and the terminology.
My understanding - All levels can have thumbnails in theory, Shows, Seasons, Episodes....but the one that really matters is "Show"
IMO The options should perhaps ask (and answer) questions:

• What do you want on your show poster.
• What do you want on your show thumbnail
• What do you want on Season Poster
• What do you want on your show thumbnail
• What do you want on Episode Poster
• What do you want on your Episode thumbnail

Taking Show thumbnail as one example

• Do you want Show Status (Ended|Contuing)
• Do you want Premiere/Finale.*
• Do you want season completeness.*

Info - * calculated based on your preffered users watch status.

And then there are options about how you want the data presented (Color, Pill , Text, Location, blah blah blah), per level? per image type? not sure havent thought that through.

*when you you say "cant be done". are you saying logical imposssibility or sdk doesnt support or not part of current thinking or something else?

I dont know how the image processor function works but i assume its a case of the plugin deciding what it wants to be overlayed and how and tell emby to do that?
Can the plugin know if the preffered users episode watch status is at a  Premier or Finale point  - i assume yes (thats core functionality to know the properties of the show/season and getting the users watched status is possible)...and have they asked for this to be tattoed anywhere....then do that...(and if not at that point remove the request or request blank - i dont know how permanent a processed image is)
Can the plugin know if the preffered users episode watch status is at a season which is complete or not - i assume yes (thats core functioanlity)...and have they asked for this to be tattoed anywhere....then do that...

then subscribe to the watched event and recalculate show/season/episode images for the preffered user, their preferences and the episode just watched.
No doubt i have over simplified, but that was my thinking / suggestion.

I am no expert but it doesnt on the surface feel like a logical impossibility or a an sdk impossibility?



 

[Blueskies278 108]

1 hour ago, ginjaninja said:

Hi @Blueskies278,
I am struggling to make sense of the options and the terminology.
My understanding - All levels can have thumbnails in theory, Shows, Seasons, Episodes....but the one that really matters is "Show"
IMO The options should perhaps ask (and answer) questions:

• What do you want on your show poster.
• What do you want on your show thumbnail
• What do you want on Season Poster
• What do you want on your show thumbnail
• What do you want on Episode Poster
• What do you want on your Episode thumbnail

Taking Show thumbnail as one example

• Do you want Show Status (Ended|Contuing)
• Do you want Premiere/Finale.*
• Do you want season completeness.*

Info - * calculated based on your preffered users watch status.

And then there are options about how you want the data presented (Color, Pill , Text, Location, blah blah blah), per level? per image type? not sure havent thought that through.

*when you you say "cant be done". are you saying logical imposssibility or sdk doesnt support or not part of current thinking or something else?

I dont know how the image processor function works but i assume its a case of the plugin deciding what it wants to be overlayed and how and tell emby to do that?
Can the plugin know if the preffered users episode watch status is at a  Premier or Finale point  - i assume yes (thats core functionality to know the properties of the show/season and getting the users watched status is possible)...and have they asked for this to be tattoed anywhere....then do that...(and if not at that point remove the request or request blank - i dont know how permanent a processed image is)
Can the plugin know if the preffered users episode watch status is at a season which is complete or not - i assume yes (thats core functioanlity)...and have they asked for this to be tattoed anywhere....then do that...

then subscribe to the watched event and recalculate show/season/episode images for the preffered user, their preferences and the episode just watched.
No doubt i have over simplified, but that was my thinking / suggestion.

I am no expert but it doesnt on the surface feel like a logical impossibility or a an sdk impossibility?



 

 

Thank you for your input and suggestions. I will revise the wording in the next update. It has been a very intense few weeks, so I am taking a brief break from coding. Regarding the SDK, for now I can’t see a way to implement this feature, but it’s still on my roadmap. This will be my last post. Be back soon

 

 

[Blueskies278 108]

@ginjaninja

THE REAL CONSTRAINT IS THE CLIENT, NOT THE IMAGE

• The current badge isn't drawn onto an image at all — it's injected into the page by JavaScript in the web client
• That's why styling is basically unlimited there: colour, pill, text, position, icon shape are all just DOM and CSS
• Android and tvOS can't receive any of it. The Android app loads its UI from an index.html baked into the APK at build time, not from the server — so no server-side change reaches it
• There's currently no supported hook for third-party UI on those clients

POSTER OVERLAY — NOT IMPOSSIBLE. IT WAS BUILT, AND IT WORKED

• I've seen real badges rendered on real poster artwork
• IImageEnhancer only fires when a client sends EnableImageEnhancers=true — Emby confirmed no official client does, and there's no server override
• Stamping the badge into the poster file on disk does work, and does reach every client
• But it looks like a sticker on the key art, and it permanently rewrites files in your real media library
• So: not a logical impossibility, not an SDK impossibility — a "reaches everything but looks bad and touches your files" problem

WATCH-STATUS FEATURES — YOU'RE RIGHT ABOUT THE DATA, WRONG ABOUT WHERE IT CAN GO

• Yes, the plugin can know premiere/finale position and season completeness. That's just querying
• Yes, I can subscribe to watched events
• But a baked-in image is one file on the server, shared by every user — while watch status is per-user
• So a poster overlay can only ever reflect one user's progress. That's exactly why "preferred user" exists, and exactly why it feels awkward
• The web badge avoids this entirely, because it renders per session
• Images are also cached aggressively, on the server and on every client. A badge that changes each time an episode is watched would mean constant redraws, plus cache invalidation that clients may simply ignore — so people could keep seeing a stale badge regardless

ON THE SETTINGS MATRIX

• Your framing (level × image type × data type × presentation) is logically clean, and I take the point that the current options are confusing
• But it multiplies to roughly six image targets × three data types × several presentation options
• Most of those combinations only work on web — I'd rather simplify than ship a page of unavailable checkboxes

WHAT I'M THINKING OF DOING

One on/off tick per level, with Season and Episode off by default — nothing gets removed, anyone who wants them just turns them on. And the options relabelled using your wording, since I think the terminology was the bigger problem.

Concept :

TV Show Status — Settings

Preferred user:  [ Select user  ▾ ]

── SHOW ────────────────────
☑  Show badges on shows

     What do you want on the show poster?
       ☑ Status (Ended / Continuing)
       ☐ Premiere / Finale
       ☐ Season complete

     How should it look?
       Style      [ Pill       ▾ ]
       Position   [ Top right  ▾ ]
       Icon       [ Calendar   ▾ ]

── SEASON ──────────────────
☐  Show badges on seasons

── EPISODE ─────────────────
☐  Show badges on episodes

Season and Episode would expand to the same set of questions if you tick them.

With this many features I'm never going to please everyone, so sensible defaults plus an opt-in tick seems like the fairest approach. I think this a good compromise.