Recompiling Plugins due to Jellyfin Update


I read on another post that once 10.6 is ready it will be necessary to recompile the plugins before release.

Forgive me, but isn’t such a procedure building a recipe for disaster?
As Jellyfin becomes more popular and more developers release plugins this could seriously impact upon delivery and quick fixes.
Surely plugins should be agnostic where feasible.
Maybe they might be Jellyfin Version Integer reliant by surely not Version Decimal.

Many other FOSS folllow this process and Certify that a plugin is Integer compatible or that a new plugin has been created.

I suggest that agnostic plugins should be the way forward. If a plugin is not Certified by Jellyfin then it is not listed or endorsed within the main Jellyfin plugins catalogue.

Kind regards,

jB :sunglasses:

Plugins have minimum compatible server versions defined in their manifest that match up with required code changes, so incompatible versions won’t be able to be installed. Additionally, the only plugins currently available in the catalog are official ones or from third party devs who work closely with the team and are aware of the changes. When we do a release plugins should get rebuilt and new compatible versions will be made available. Historically whenever we have a major server release the plugins will lag behind by a few days while the fixes are applied to them. The process surrounding this is getting better, but it’s not exactly an easy problem to solve with the technology stack that we have. In the future we’re planning to have an unstable repository of plugins as well so we can verify full functionality before an official release.


Thank you for your reply.
Whilst I understand what you are saying, it really only reiterates what I surmised.

Should the day hopefully arrive are the good natured developers really going to sit and recompile possibly hundreds of plugins?

Some will fail badly, some will fail and can easily be fixed, many will survive to be re-released. But my point here is that with the correct SDK and hooks agnostic plugins will not require this. They just continue.

Where there is a fundamental change in compatibility the plugin is automatically, gracefully rejected; hopefully with an advisory to the end user and a log entry.

No recompiling on a grand scale.
If it doesn’t work then the developer can take charge and ameliorate the rejection, re-applying for certification as necessary.

Believe me this will in the medium term reduce workload considerably.

Kind regards,

jB :sunglasses:

I’m really not sure what you’re asking for here. I’m not sure any software platform on the planet (except maybe the linux kernel) says “here’s how you can hook into the system, it will never ever change”. It’s a moving target, and it will always be a moving target. There’s really no way around that. There’s things in the server that have to change, and some of those changes force changes in the addons. It sucks sometimes, but it’s just a fact of software development. We’re working to make it more streamlined with less breakage and more automation in the future, but there’s simply no way we can guarantee endpoints will never change. Even the HTTP API is scheduled to go through an overhaul for version 11, the internal APIs that plugins hook into are absolutely going to be seeing changes. Especially on an inherited software where we’re choosing different directions than the previous devs, change is inevitable.


Perhaps you are correct in that I am not explaining myself.
Take for example Odoo the FOSS CRM. They have a catalog of plugins which have against their names an indicator as to which Integer Version of Odoo the plugin supports. It is not recompiled each time a major release is delivered and certainly not for a decimal release.
So for instance I can install Odoo 10 and work my way through Odoo 11 and Odoo 12 using the same plugin. Once I hit Odoo 13 I need to install a new release of the plugin. Which is also available from the catalog.
The compilation is not done every time Odoo is released. But re-certified by the catalog maintainers.

This is essentially what I was trying to describe by employing agnostic plugins.

Kind regards,

jB :sunglasses:

To put it more to the point:
What you are looking for may happen in the future. We don’t want to change everything all the time.

Right now, even 18 months in to the project, still working to remove old broken code from the interfaces the plugins use. A lot of it was outdated, slow, and often duplicated multiple times for no reason. As a result, with each minor release (e.g. 10.5 to 10.6), we have changes on those interfaces that plugins need to comply with. Some require no changes, some require very few syntax changes.

As the Dev Relations person, I make sure we reach out to everyone affected as much as possible, so everyone can anticipate the changes needed and react better. We are also improving our own systems to make this happen faster, allowing us to eventually react before a release.

There will come a time when we have enough re-written that the interfaces will be largely stable, though there may be small changes (hopefully non-breaking). Since very early on in the project, myself and the other Core Team members decided that we would making these types of breaks in version 10, with an aim to be stable in version 11, with a new API as well. As @mcarlton00 pointed out, we manage most of the plugins ourselves, and for the few others, we’re in contact with their makers. It’s all fine :slightly_smiling_face:

It’s also not that every plugin needs changed every release. For example, the Kodi Sync Queue plugin was last released March 25. There’s been 3 server releases since then that didn’t require any changes. So while the plugins do all need work for 10.6.0, that doesn’t necessarily mean that when we release 10.6.1 they’re all going to need recompiled again.

Thank you for taking the time to listen to me, but also explaining the current ideology.
Please don’t get me wrong, I have not been criticising how Jellyfin works, but I do not intend to be a pedestrian user. If I can bring any of my many years of IT experience to help then I will/would like like to.
Where it comes to UI/UX due to my disabilities I am very active. Where it comes to logic processes I am also very keen.
Although I am unable to offer more than about 1 hour at a time actively on-line I hope I can help with the future state of Jellyfin.

Thanks and kind regards,

jB :sunglasses:

I support the v5 version of the NextPVR addon waiting for a bit more feedback before submitting a PR and since I don’t use jellyfin I depend on the limited documentation for going forward. As long as the bridge dll on nuget doesn’t change (currently at 10.5.5) then I shouldn’t have to do anything

For fun I tried with the nightly and it is crashing big time because of initialization differences on the backend so whatever is going on is more than a recompile.

There’s some logger changes I believe. I’ll have a look at the plugin repo.

Moving to ILoggerFactory did solve the crashing problem. The issue is where to plugin authors find out about breaking changes?

Good news - we just posted this: