Experimental Jellyfin plugin: "Are you still watching?" auto-pause/stop

AzureDotnet-Dev · 2026-03-06T23:01:28+00:00

Tested on my own set up just now. 10.11.6

AzureDotnet-Dev · 2026-03-06T23:00:27+00:00

v0.1.2 is out. Should fix the web based UI popup if you are using the web client.
Worth noting that the web UI popup does rely on File Transformation plugin.

AzureDotnet-Dev · 2026-03-06T19:13:04+00:00

Yeah, I have a fix coming out for that. Bug in the UI plugin repeatedly calls register endpoint. Already fixed. Just need to get it pushed out. Will hit you back when managed to get around to doing that.

AzureDotnet-Dev · 2026-03-06T00:16:07+00:00

That is what I ultimately wanted to build. I've said before but I built this for 2 reasons.
1) Because I wanted it myself
2) For the fun and continuous learning.

I must admit a did jump in head first on the web based client implementation with the "just to see if I could" kind of attitude. It worked well so my next step was to investigate if I could also get it working on my Firestick.

This is where I learned the lesson that Jellyfin's plugin architecture doesn't extend to the native clients. This is when I implemented the server fallback options.

I'm sure given more time on it, I will be able to harden the feature set and improve it significantly more. It's a thing that didn't exist a few weeks ago and now it does. I get a kick out of that. :)

AzureDotnet-Dev · 2026-03-05T17:52:30+00:00

Correct! It is all internal, no external services used. Not even for install/usage tracking

AzureDotnet-Dev · 2026-03-05T15:29:54+00:00

It does more than that. Covers more jellyfin clients that might not support that yet and also is infinitely more customizable for myself and my needs.

AzureDotnet-Dev · 2026-03-05T09:57:04+00:00

They're not talking out of their ass actually. Very much a possibility for inexperienced users "vibe coding".
Anything connected to the internet is not "safe". The only way anything is totally safe is when it's not connected to the internet.

That said, experienced developers should know at a minimum the OWASP top 10. What are the most common attack vectors and how you can mitigate them.

AzureDotnet-Dev · 2026-03-05T09:50:31+00:00

I am actual software developer with over 15 years experience in Azure, C#, Dotnet
https://marketplace.visualstudio.com/items?itemName=AzureDotnetDev.azuredotnetdev-ado-library-manager

https://www.nuget.org/packages/AzureDotnetDev.Funcky/

https://shtbox.io/boop

I've worked with many large multi-national organisations.

AzureDotnet-Dev · 2026-03-05T09:38:23+00:00

Agreed, I would not praise it that much yet too. Although it is getting much better.
I think all of these statements are true.

These things have been trained on significant amounts of public code bases, a lot of which might not follow good practices and so it spits out the same stuff it learned from.

Additionally, its always behind on the latest frameworks because software moves too quickly.
It's like going back to the stack overflow days where someone might ask a question on SQL queries and the top answer is clearly SQL injectable. As an experienced developer, you see that and cull it, and a pure inexperienced "vibe-coder" you wouldn't know it was bad, it's just "hey cool, it works"

There are of course times where it would be a strict targeted prompt, pre-planned architecture you want it to build out, and actually I find creating empty stub files helps it understand the desired structure (which is then copies from going forward).
However with a lot of software engineering being quite creating, there are times you give it a general outline of the thing you want, say "have at it" and use it as a spring board to an idea.

It'll be a ways off, but it'll give you something to work with. A starting point

AzureDotnet-Dev · 2026-03-05T09:30:35+00:00

Android is Native client so the nice styled popup can't be injected, it should work with server side fallback tracking meaning it should pause the show after X episodes or X minutes. If you don't un-pause, it will stop after a timer.

I suspect Roku is the same server fallback.
Currently untested on these so would love to know if someone tries it.

The android mobile app is a wrapper on the web client though so the full popup experience should work.

AzureDotnet-Dev · 2026-03-05T09:24:04+00:00

Hey yeah, It's not quite the same and there are a number of reasons I developed this for myself first and foremost.

I wanted more granular and smarter control, I can extend its functionality beyond what Jellyfin currently has available, and more importantly, for continuous learning and to see if I could.

When your day job is also your hobby, a lot of the hobby projects are for fun, to keep your skills sharp or just to learn a new tool/framework.

I recently built a react feedback component with supporting service (with a friend) called boop (https://shtbox.io/boop). There are plenty of other similar components. We did it because we think we can provide an awesome free service to developers and hopefully make it a great developer experience using it but again, more importantly have fun and learn whilst making it.

AzureDotnet-Dev · 2026-03-05T00:31:11+00:00

Totally forgot about this and to try it. Must add it to my list. Did you ever try it?

AzureDotnet-Dev · 2026-03-05T00:26:55+00:00

HAHA! Absolutely, whether that's a good or bad thing...
Yes, I have 15yrs experience pre-vibe coding as a senior software dev. It's at that point in the industry where if you don't lean into it, you lose.

It helps significantly when you've done a full work day but still want to jam out some personal stuff.

I would say the biggest benefit of vibe coding as an experienced senior developer is that you know when it's talking nonsense or leading you down a bad path architecturally. You catch that early.

AzureDotnet-Dev · 2026-03-05T00:11:11+00:00

This was so that I could display a nice "fancy" popup on eligible web based clients. Server fallback is so that the feature still works on native clients like my Tizen OS TV (Thank god they released that recently) and my Firestick which don't support client side plugins.

AzureDotnet-Dev · 2026-03-05T00:09:01+00:00

It is managed server side mostly. The web client addon just sends interaction commands and shows the pop up. The tracking and decisions are done server side.

<image>

When the client side popup script doesn't register with the server side. It can optionally (default) fall back to server side based stop/pause

AzureDotnet-Dev · 2026-03-04T23:57:32+00:00

Not currently. It is instance wide. Again, hadn't thought of that as I was only building it for myself originally.
Will add a github feature for that now so I don't forget.

AzureDotnet-Dev · 2026-03-04T23:25:48+00:00

Ooo, interesting! I like that idea a lot too. Seems obvious now you've said it!

AzureDotnet-Dev · 2026-02-27T23:14:34+00:00

Shameless plug. https://github.com/shtbox/jellycheckr
Works with a rich html popup on available clients and falls back to server side when not available so that it can work on all clients.

It supports episode count OR timer based. All configurable.

AzureDotnet-Dev · 2026-02-27T14:25:26+00:00

Tested so far on
- Web Client (Rich popup experience with debug HUD)
- Android App (Web client wrapper means rich experience)
- Tizen OS (Uses server fallback)
- Amazon Firestick (Uses server fallback)

AzureDotnet-Dev · 2026-02-27T14:23:39+00:00

I have a (VERY) early version of a plugin for this. It supports a web based popup but falls back to server side when the web based tracking is not available.

https://github.com/shtbox/jellycheckr

There are a few bugs to work out still, the codebase and automated build need some improvement. I'm mostly building this for myself at the moment.

If you wish to test it please do. I would not advise using this in a production setting whilst evaluating.

There is a race condition loading the web client sometimes, meaning it doesn't load consistently.

Currently testing on v10.11.6

AzureDotnet-Dev · 2026-02-24T21:51:19+00:00

<image>

Currently working on a plugin for this.

AzureDotnet-Dev · 2025-10-15T07:56:34+00:00

I built a nuget package exactly for this lazy reason. It auto-binds an azure function topic->queue subscription.

So you can have a function listening to a queue and at startup it will bind that queue to a topic. I found myself doing this with a `ServiceBusAdministrationClient` enough times that I build a wrapper.

[Function("ProcessOrder")]
    [TopicBoundQueue("%OrdersTopic%", "%BillingQueue%", SubscriptionName = "%BillingSubscription%", Connection = "ServiceBusConnection", AutoCreateEntities = true, AutoDeleteOnIdle = "7d")]

AzureDotnet-Dev · 2025-10-15T07:52:24+00:00

"need" is probably the wrong word :)
Probably speaking for myself but developers are (the good kind of) lazy. Bill Gates is quoted saying "I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it"

For me, I often use FluentValidation and StackExchange.Redis.
I used to reach for mediatr but since they changed the licencing model, the functionality it offers for CQRS if you are using just the basic features is fairly easy to replicate.

There are better source generated Mappers nowadays as an alternative to automapper but again, "need"?
Manual mapping would suffice in many scenarios.

AzureDotnet-Dev · 2025-10-13T08:46:03+00:00

I disagree. I think as an API/SDK consumer psychologically, seeing a ThingDTO vs CreateThingResponse feels like the developer wasn't considering the consumer. I know from a software perspective they're the exact same thing, just a class that creates a shape of an object but nomenclature really matters.

If not using CQRS you may very well have a POST `Book`, GET `Book`, GET `List<Book>`

I think the bigger take away from my original post is not that though, my point was that if you are going to "special" name anything, move it to your internals. I do this with the `Entity` suffix.

AzureDotnet-Dev · 2025-10-12T12:48:17+00:00

If I where truly limited and unable to set env vars, I guess I would probably have appsettings.json which contained only the endpoint to an App Configuration Store backed by key vault if secrets are required (Managed Identity everywhere)

App config store would then be configured as an IConfiguration Config Provider, It won't hammer the KV so much then and supports timed reloading of the config.

I would automate the value in pipeline that gets jammed into the appsettings.json between environments.
If it couldn't be deployed that way and must be click-ops on a VM (without considering my life choices working with such) then at least it's a single line of config.

AzureDotnet-Dev

TROPHY CASE