Closed cywteow closed 2 years ago
My addon (https://github.com/pikdum/plugin.video.haru) is also broken after upgrading to 5.1.67.
Seems to be related to this:
2022-05-08 15:09:40.707 T:16007 ERROR <general>: /home/pikdum/.kodi/addons/script.module.resolveurl/lib/resolveurl/lib/websocket/_abnf.py:37: UserWarning: NumPy was imported from a Python sub-interpreter but NumPy does not properly support sub-interpreters. This will likely work for most users but might cause hard to track down issues or subtle bugs. A common user of the rare sub-interpreter feature is wsgi which also allows single-interpreter mode.
Improvements in the case of bugs are welcome, but is not on the NumPy roadmap, and full support may require significant effort to achieve.
import numpy
After opening up my addon, and opening up 'SubPlease - Airing', Kodi crashes.
Commenting out the import numpy
block and replacing with numpy = None
fixes it as a workaround.
Not sure if same exact issue as above.
@cywteow 5.1.67 removed closed to 35 defunct plugins, so that log is normal. The messages are cosmetic and do not affect anything. To get rid of those log messages, one has to delete the resolveurl userdata settings.xml file and restart kodi. Any debrid authorisations have to be redone after that
@pikdum 5.1.67 adds websocket code to support some plugins. it was tested in Android, windows, CE/LE and Linux with python 2.7 and 3.8. Are you running on Linux with python 3.9 or 3.10 by any chance?
Looks like my issue was fixed with https://github.com/Gujal00/ResolveURL/commit/d2a13ccb186b747f953eeb17a4851ec240f1fb14. Unsure if it was the same as the original issue though, since mine caused Kodi to crash entirely. Here's a thread on reddit I found with a tiny bit of context on the original, but unlikely to be enough to reproduce: https://old.reddit.com/r/Addons4Kodi/comments/ukwsp1/the_gogoanime_addon_isnt_working_for_me/
Wow i missed all the fun today :) @pikdum original issue was different as you can see by his log file. All those plugins were removed. If you look even closer, things like CocoScopeResolver and JetloadResolver were removed some time ago and not in the last release.
Think the bigger issue he is having is here:
https://github.com/cywteow/gogoanime/tree/main/plugin.video.gogoanime/resources/lib/resolveurl/plugins
He has his own resolvers and those imports need to be fixed. P.S. take that reddit with a grain of salt....99.5% of the active members cant read code or a log file π
@cywteow
Thanks to @shellc0de27 to referring to your code.
Okay the latest resolveurl had the two lib folders consolidated to one.
So what it means is in your code if you have
from resolveurl.plugins.lib import helpers
you need to change it to
from resolveurl.lib import helpers
and that will fix the issue you are having with your custom gogostream.py, streamani.py and fcdn.py files
@Gujal00 Happy to assist when i can :P
As it seems, this last update had so many changes that it should get a major version bump to 5.2.x instead of staying at 5.1.x.
Uwc (unmaintained for 1+ year now) broke for me, but changing line 60 of plugin.video.uwc/resources/lib/utils.py
from
from resolveurl.plugins.lib import captcha_lib
to
from resolveurl.lib import captcha_lib
fixes it. Many thanks to @Gujal00 for his example at the comment above.
Maybe there's an easy way to maintain backwards compatibility by having both the old + new import paths working? Looks like this might break more addons than expected. I can't think a way off the top of my head, though. :)
@pikdum You are right, a path change could affect many old/unmaintained addons to be broken.
@Gujal00 you can consider to make both paths to be compatible.
@shellc0de27 Thanks for the help!
@Gujal00, regarding op's issue - well not an issue actually, just log spamming as resolvers and their settings come and go and leave obsolete settings entries on user's (userdata) settings.xml, what'd you think about a function like this:
https://github.com/bleak-lodge/ResolveURL/commit/5c0529107d29a8add5f6791bded970fe288ce33c
It cleans .kodi/userdata/script.module.resolveurl/settings.xml
from obsolete entries, keeping only the active ones.
I've used this function in my add-on for years, it's working great there, no issues, but obviously needs excessive testing on smr as it holds accounts tokens etc.
I put the main function on kodi
lib so if it works ok it could be used elsewhere as well, eg under here https://github.com/Gujal00/ResolveURL/blob/master/script.module.resolveurl/lib/resolveurl/__init__.py#L329 when we create a new settings file.
The whole idea was to consolidate all the libraries into one folder rather than having them split in two different places, no reason why it was like that in the first place.
@cywteow I do not know why you have fcdn resolver separately. It is already supported in Fembed resolver
class FEmbedResolver(ResolveUrl):
name = "FEmbed"
domains = ["fembed.com", "anime789.com", "24hd.club", "vcdn.io", "sharinglink.club", "votrefiles.club",
"femoload.xyz", "feurl.com", "dailyplanet.pw", "jplayer.net", "xstreamcdn.com", "gcloud.live",
"vcdnplay.com", "vidohd.com", "vidsource.me", "votrefile.xyz", "zidiplay.com", "fcdn.stream",
"mediashore.org", "there.to", "femax20.com", "sexhd.co", "viplayer.cc", "mrdhan.com", "votrefilms.xyz",
"embedsito.com", "dutrag.com", "youvideos.ru", "streamm4u.club", "moviepl.xyz", "asianclub.tv",
"vidcloud.fun", "fplayer.info", "diasfem.com", "fembad.org", "moviemaniac.org", "albavido.xyz",
"ncdnstm.com", "fembed-hd.com", "superplayxyz.club", "cinegrabber.com", "ndrama.xyz",
"javstream.top", "javpoll.com", "suzihaza.com", "fembed.net", "ezsubz.com", "reeoov.tube",
"diampokusy.com", "filmvi.xyz"]
If you want to I could include the additional resolvers that you and @groggyegg maintain into the resolveurl base distribution, you only have two each not counting fcdn which is already covered
My personal opinion on this.... Why even use an old an unmaintained addon in the first place? Especially an old UWC addon...really? There is fork out there i believe lmao. Things change, like kodi, python, OS's, etc.
@Gujal00, regarding op's issue - well not an issue actually, just log spamming as resolvers and their settings come and go and leave obsolete settings entries on user's (userdata) settings.xml, what'd you think about a function like this: bleak-lodge@5c05291 It cleans
.kodi/userdata/script.module.resolveurl/settings.xml
from obsolete entries, keeping only the active ones.
Thanks, Good idea, I will have a look and see how it can be implemented safely and also possibly run silently whenever resolveurl updates, rather than give the user that option unnecessarily
Yeah that's how I thought should be in the long run, I just made it as a temp settings action so it could be tested more easily.
My personal opinion on this.... Why even use an old an unmaintained addon in the first place? Especially an old UWC addon...really? There is fork out there i believe lmao. Things change, like kodi, python, OS's, etc.
Offtopic. Speaking for myself and only for myself. On my kodi-only (libreelec x64) laptop, I get some weird framedrops on kodi 19, regardless of the video resolution, so I stay on kodi 18 until I fix it. Plus I have a tvbox that runs coreelec 9.2.8 and nothing newer than that. As for uwc, I think its fork's menus are harder to navigate through, so I still prefer it for sites that still work with it.
If that's what you prefer @pitsi but your missing the big picture. You and only you are running those risks cause Its not actively being maintained. Can't expect to have Resolveurl (maintained) to bump some crazy version number cause it breaks an old addon or revert back. Am i wrong?
Offtopic, part 2. That is why I did not request any support and fixed it myself, because I want it to work on my end, at least for the time being. And since I fixed it, I thought that posting the fix is a good gesture for anyone else that may come along this issue report. As for the tvbox, allow me one correction. It CAN'T run a newer version of coreelec because it is not supported anymore. The reason for that lack of support is clearly mentioned in coreelec's releases page.
Ontopic.
Out of the may addons that I use, some have the resolveurl dependency with no version at all, e.g. smr_link_tester has
<import addon="script.module.resolveurl"/>
Some have 5.0 or 5.1 as the minimum version dependency
<import addon="script.module.resolveurl" version="5.0.00"/>
or
<import addon="script.module.resolveurl" version="5.1.0" />
and some have an exact version number
<import addon="script.module.resolveurl" version="5.1.49"/>
I don't think that a version bump to 5.2 would break any of these. However, now that many of them have to be updated because they stopped working overnight, I am sure that their devs will add v5.1.67 as the minimum.
@pitsi The version mentioned in the addon.xml if any is the minimum version required for operation, not themaximum version. So bumping resolverurl to even 6 is not going to fix the issue. The only addon that seems to use resolveurl's internal routines is uwc. Dramacool and gogoanime are adding custom plugins which could been added to resolveurl itself. AliveGR used to have custom plugins but the dev @twilight0 moved them to resolveurl a while ago. I don't see any other addon affected by this change. Haru addon technically wasn't broken as the issue was due to the websocket module using a functionality not compatible with python 3.10 (only in very latest Linux desktops) which was a fringe case and has been addressed already
If you want to I could include the additional resolvers that you and @groggyegg maintain into the resolveurl base distribution, you only have two each not counting fcdn which is already covered
@Gujal00 Thanks, I will do a PR later when I have time since the resolver's are not working for the time being. But regarding fcdn, if I don't remember it wrong, there were some issue with the existing resolver. It might have been fixed now, something that I have to try out first since it was a long time ago.
@pitsi The version mentioned in the addon.xml if any is the minimum version required for operation, not themaximum version. So bumping resolverurl to even 6 is not going to fix the issue. The only addon that seems to use resolveurl's internal routines is uwc. Dramacool and gogoanime are adding custom plugins which could been added to resolveurl itself. AliveGR used to have custom plugins but the dev @twilight0 moved them to resolveurl a while ago. I don't see any other addon affected by this change. Haru addon technically wasn't broken as the issue was due to the websocket module using a functionality not compatible with python 3.10 (only in very latest Linux desktops) which was a fringe case and has been addressed already
I still do have custom plugins but I fixed the imports already.
@pitsi The version mentioned in the addon.xml if any is the minimum version required for operation, not themaximum version. So bumping resolverurl to even 6 is not going to fix the issue.
I know that detail. I am on kodi since the word "addon" was unknown to the kodi community and I have learned a lot by searching the kodi wiki and relevant resources for addons. And that is exactly what I am saying. that a version which brought so many changes, should receive a major version bump, because it would not affect any addon that depends on resolveurl in any way. Now that the change is in place, regardless of the version number, it is up to the other addon devs to correct their addons. Enough with the offtopic though. I let you guys do your work :)
@shellc0de27 @bleak-lodge Can you please test this commit This adds an option in settings to cleanup defunct resolver settings from user's settings.xml Please take a backup of your settings.xml in userdata\addon_data\script.module.resolveurl folder and then try cleanup option from settings and report back if any issues
For now I have kept it as manual option, but will look at possibility of running that function automatically whenever resolveurl gets updated
@Gujal00 This works awesome. Did find 2 that it didn't clean based on my quick test.
<setting id="VideozUpload_enabled" default="true">true</setting>
<setting id="VideozUpload_login" default="true">true</setting>
<setting id="VideozUpload_priority" default="true">100</setting>
<setting id="VidspaceResolve_enabled" default="true">true</setting>
<setting id="VidspaceResolve_login" default="true">true</setting>
<setting id="VidspaceResolve_priority" default="true">100</setting>
Don't know why the settings entry for these doesn't include the word Resolver
but it doesn't match the regex here:
resolvers = set(re.findall(r'id="(.*?Resolver)_', settings_xml))
Are you seeing the same on your end?
@shellc0de27 Those defunct plugins had typos in the class name
looks like VIdeozUpload was the class name and didnt include Resolver in the name
and Vidspace plugin class name was missing r
at the end VidspaceResolve
oh ok i see :)
Yep, my observation as well. My settings were also preserved (r-d & d-l auth elements), so no issue in that front as well. PS might be placebo, but I think on a low-powered device with slow storage I own, resolving magnets from r-d does seem a bit faster now. Probably because the settings file that is read from the disk is much smaller (the installation of smr on that device is years old).
@shellc0de27 @bleak-lodge Thank you for testing the cleanup code and feedback. Based on your feedback I have modified the regex pattern slightly, so that it cleans videozupload and vidspace as well.
resolvers = set(re.findall(r'id="([A-Z][^"_]+)', settings_xml))
Please test and if you are happy will release it
@Gujal00 Yeah no problem. Can confirm new pattern removed those two. π
As per @bleak-lodge suggestion, in commit https://github.com/Gujal00/ResolveURL/commit/f933a5f070bc703dedf3da81450394293adc8bfd the user settings cleanup function is now set to run silently when resolveurl updates
you can test this by deleting the addon settings.xml file (not userdata resolveurl settings.xml), put back your old user settings.xml in userdata resolveurl folder then start smr link tester. It should then silently build a new addon settings.xml and based on that cleanup the userdata settings.xml
@Gujal00 wouldn't it be safer to call cleanup_settings
within the try/except block, where we try to write the new_xml?
If that fails for some reason wouldn't make sense running settings cleanup anyway.
@Gujal00 wouldn't it be safer to call
cleanup_settings
within the try/except block, where we try to build the new_xml? If that fails for some reason wouldn't make sense running settings cleanup anyway.
The new xml is already in memory and the cleanup call is inside the if condition
if old_xml != new_xml:
So I thought it is time to cleanup anyway regardless if the addon settings xml is written or not. Do you thing there an issue with that approach?
Ah yeah, you're right, cleanup_settings
can be run even if add-on settings.xml isn't present.
5.1.66 still working fine