Recent incompatibility messages on Kodi 17.6

[anohren]

I recently started using Kodi again and noticed now that upon every relaunch it will display a message box saying this addon is incompatible with this version of Kodi (17.6), after which it disables the plug-in. The add on still works as expected after enabling it manually though (!)

Is this something that anyone else has experienced, or know the reason behind? It's curious since I've been running this same Kodi version for a long time on this machine, considering Ubuntu 18.04 has been EOL for some time (except security updates).

What in this repo has changed to make 17.6 choke? I see a fair bit of activity in this repo since I stopped using Kodi last summer...

[nullket]

The plugin changed to yt-dlp as the default resolver for URLs as YouTube-dl was not maintained for a long time. yt-dlp requires python3 which is no problem with Kodi 19 while YouTube-dl still works with python2 . We did some workaround to fix YouTube-dl and users have actually the choice (via the settings) to pick which resolver the want (default is yt-dlp on python3 systems and YouTube-dl on python2 Systems).

The plugin still works on Kodi 18 (python2 only), therefore I would expect it wir work fine on Kodi 17 as well. On the other hand I do not have a Kodi 17 instance to checkout the problem and considering that Kodi 20 is around the corner I would say it is time to upgrade ;) I know, sometimes old hardware does not work with newer software but the problem here is that this plugin highly depends on an external url resolver which itself depends on how the websites (YouTube etc.) work. We did not break python2 or old Kodi version support on purpose but we had to go with the time.

I would recommend that you upgrade and in case you do not want/can do this, you should figure out how Kodi 17 actually decides that something is incompatible. In any case good luck.

[anohren]

Thanks.

I agree that what you describe doesn't sound like it would break anything. I was thinking there had been changes in some manifest, since it's the most reasonable thing to actually validate upon launch for non-running plug-in addons.

Yeah, I'd have to find out how it determines this then.

[anohren]

Ok, so apparently a manifest has been changed. Changing the required xbmc.python version from 2.26 to 2.19 in addon.xml solves the problem.

The question now is: why was the xbmc.python requirement bumped for the Python 2 version of the addon?

[nullket]

Yes, every Kodi version has its specific xmbc.Python. https://kodi.wiki/view/Addon.xml#.3Crequires.3E

so 2.26 is for Kodi 18 and 3.0.0 is for Kodi 19 you would need to manually change it to 2.25 for you version.

We automatically build and release the version for Kodi 18 and Kodi 19 https://github.com/firsttris/plugin.video.sendtokodi/blob/master/.github/scripts/build-addon.sh

supporting the very old 17 might break 18 again so I would like to avoid changing the version to something older.

I am just on mobile but I hope that helps.

[anohren]

Well, that doesn't really answer the question of what part of the plug-in mandates the increase of the requirement from 2.19 → 2.26. If there is no answer to that question then technically that requirement bump is the very change that causes breakage and so should be reverted.

Whether Kodi 18 ships with 2.26 or not doesn't seem relevant considering we're not talking about an absolute version requirement, but a lower bound:

The version attribute specifies the minimum version of the required add-on to be installed.

In other words Kodi 18 already satisfies a dependency on 2.19.

I'm not sure what you refer to when you say manually changing "it" to 2.25 — manually change what exactly? Nevertheless, the point is that if the plug-in doesn't require the 2.19 → 2.26 bump in version dependency then that's what should change, not requiring manual intervention for no tangible benefit.

supporting the very old 17 might break 18 again

I'm not sure I follow — can you expand on this? It sounds as if you're hinting at that you've previously identified a dependency on 2.19 to be problematic. What breakage of 18 are you referring to? How did the dependency bump fix it?

Or maybe @firsttris knows the answer to why the requirement went from 2.19 → 2.26?

[nullket]

In other words Kodi 18 already satisfies a dependency on 2.19.

That might be true for Kodi 18 but I know for sure that something about the settings changed really much in Kodi 20 and xbmc.python 3.0.0 was required (I do not recall the exact reason tho). I think the wiki means your local kodi instance has to be at least this version. If you read a little further

Each Kodi version contain a certain backwards compatibility. For example add-ons made for Gotham 13.x can still work ion Jarvis 16.x. Do note that this might change in the future.

So it might break kodi 18, right?

I'm not sure what you refer to when you say manually changing "it" to 2.25 — manually change what exactly?

Instead of changing the plugin here for an old legacy version and maybe break it for kodi 18 users, you could download just the latest zip (not the repo zip but the addon zip) and just manually edit the addon.xml with 2.25

I'm not sure I follow — can you expand on this?

Sure, I was a bit unclear there, what I meant: No, I do not recall there was a specific reason to bump that version for kodi 18. We could surely try to roll it back but the question arises are we fixing it for you (maybe the last kodi 17 user of this plugin) and simultaneously breaking it for all other other kodi 18 users? I mean it would not even require 2.19 just 2.25.0 instead of 2.26.0. That would be enough to work with kodi 17, and this might no change a thing for kodi 18 users.

Do you have a kodi 18 to test before be break stuff for others?

[anohren]

Thanks for the clarification!

The comment under the compatibility table:

The ABI version you see in the table above is the backwards compatibility version for which add-ons are still marked "working".

...means, I think, only that care has been taken to not break backwards compatibility for addons using that version (e.g. 2.1.0 up to Kodi 18) — not that there are separate compatibility layers emulating earlier behavior of the API. In this case an addon requiring 2.19 will still use 2.26.0 on Kodi 18, including — I assume — the bug fixes that come with it. I.e. the behavior will likely not change.

I'm mostly mentioning 2.19 since that seems to be what was used before the breakage, and I generally follow the principle of only changing something like that if there's a reason for it. That way we don't have to speculate on whether or not I'm the only one using Kodi 17, or whether 47 people are using Kodi 16 — we can just follow that principle. It's not like this Issue section is swarming with users of any particular version, so the fact that I'm even here mentioning it says something.

I think that arguing for not using e.g. 2.19 simply because it was bumped to 2.26 for no apparent reason — thereby demonstrably breaking Kodi 17 — just because it might break 18 to change it back (wasn't Kodi 18 working for a long time while we used 2.19?) would end up a bit circular.

Sure, I can test both 2.19 and 2.25 with Kodi 18 (although I don't think it makes a difference since Kodi only vends one single version), but regarding the comment about breaking it for others, well, that's what happened already when it changed to 2.26; I was one of the others. Did anyone test it with Kodi 17 then to make sure not to break it? Or was there a discussion to decide to drop Kodi 17 support?

Don't get me wrong, I don't want to break 18 (I use many versions) I just see no reason for why it should and don't think we need to entertain that hypothesis at length, but instead just act accordingly when it happens, if it happens. It's not like the plug-in has worked flawlessly in the past. Things might break, but also, they already have.

I'll try 18, and if someone else does it too we can cover more use-cases.

[nullket]

That way we don't have to speculate on whether or not I'm the only one using Kodi 17, or whether 47 people are using Kodi 16 — we can just follow that principle.

That would follow the assumption we all have enough time to fully understand all effects of those versions (concerning the kodi api, it is all our free time and we depend on the kodi wiki). But I get your point and you are right.

Did anyone test it with Kodi 17 then to make sure not to break it?

Yes a lot of the plugin was changed and two users helped a lot with testing. Of course everybody as limited time thus we could only test versions of this plugins which always contained multiple changes.

Or was there a discussion to decide to drop Kodi 17 support?

We thought even about dropping kodi 18 as the resolver situation was really bad for python2 systems. We even had incoperated a self-patched youtube-dl version for a while...

Things might break, but also, they already have.

Yes for even older legacy version. 18.04. had EoL one year ago. Kodi 17 is two releases past the last one. python2 support ended January 2020. Aas long as old stuff works it is fine (like stable debian) but EoL is somewhat EoL. Do not get me wrong, I do not want to break support for EoL versions on purpose if it still could work but that was simply not the focus when you have limited free time to work on something like this.

Sure, I can test both 2.19 and 2.25 with Kodi 18

I just created a new version for the repo with the downgrade, please test it with both versions and report back

[anohren]

Oh yes, I followed that throttling issue from a distance. Quite the confusing mega thread over at youtube-dl.

Sounds like you've gone live with the change. I'll try it out.

[anohren]

I'll report here then for 0.9.169.

Sending single-video Youtube URL:

• Kodi for Debian 17.6 on Ubuntu MATE 18.04: works
• 18.9 Media Center Kodi on OSMC: works

When I checked the settings for the latter it seems to have defaulted to yt-dlp which allegedly is Kodi 19+ exclusive. Still it worked. Haven't really looked at the plugin code in some time so I'll just assume there's a conditional on the Kodi version.

The settings screen for the former doesn't appear to show any options. That shouldn't be an issue on Python 2 platforms though, as long as the plugin ignores the yt-dlp option on them.

Not tested:

• Sending playlists. The performance of that is simply so abysmal that it's nigh-unusable anyway, until we decide to merge the fix for that. I'm hoping it might be possible to enable performant playlist URL parsing for Kodi 19+, judging by my earlier tests which seemed to break the play queue only on older Kodi versions (like 18).

[nullket]

Sounds like you've gone live with the change. I'll try it out.

Yes, I thought that might accelerate the procedure a bit ;)

I'll report here then for 0.9.169.

Perfect! Thank you very much for testing - it is quite hard to get testers with different kodi versions!

it seems to have defaulted to yt-dlp

Yes, I had a solution were the setting would be greyed out and it would automatically choose a certain setting based on the version but that did not work before kodi 19. The addon settings were completely reworked in kodi 18/19 and thus such features do simply not work in previous versions.

The actual ignoring of yt-dlp for python2 versions takes here place: https://github.com/firsttris/plugin.video.sendtokodi/blob/cd520fa800cf6af122fb6b1dc3818636734cf1d1/service.py#L90

yt-dlp which allegedly is Kodi 19+ exclusive

It is python3.6.+ see here

Sending playlists. The performance of that is simply so abysmal that it's nigh-unusable anyway, until we decide to merge the

Sending a playlist was never a use case for me that might be the reason why I have not looked into this issue. I just saw you opened a new issue. Lets work there together on the problem.

[anohren]

Sending a playlist was never a use case for me that might be the reason why I have not looked into this issue. I just saw you opened a new issue. Lets work there together on the problem

I did open a new issue, but that issue is actually not about the problem described (bad performance). The performance issue is described and solved in an old issue with corresponding PR.