Kodi Community Forum
v17 About those disabled addons after deleting addons.db - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: OS independent / Other (https://forum.kodi.tv/forumdisplay.php?fid=228)
+---- Thread: v17 About those disabled addons after deleting addons.db (/showthread.php?tid=322860)

Pages: 1 2


About those disabled addons after deleting addons.db - jim_p - 2017-10-23

Hello everyone.

This is my very first thread here, although I have been an xbmc/kodi user since version 10 or so, back when the word "addon" was unknown to xbmc, and with many installations so far on a variety of hardware, so I can say I am an expert in from setting it up to fine tuning any available option. I use kodi 17 on my pc (debian testing x64), on my pi zero (openelec 8), kodi 14 (openelec 5) on an old netbook which is 32bit only and kodi 16 on my friend's (windows) pc.

I consider version 17 to be the worst version so far for various reasons which I will not analyse now. If I could, I would not upgrade to it, neither on my pc nor, on the pi zero, past 16. However, apt "forced" me to move to 17 on the pc, while I did a clean install of it on the pi zero, switching from libreelec 7 to openelec 8.
And, as most (if not all) users who went from 16 to 17, I encountered that black screen when kodi started up, because it was unable to update the database where it stores its addons info. The solution was to delete userdata/databases/addons.db so that kodi would make a new, "proper" one for version 17. This comes with the well known drawback: all addons (excluding the pointless ones installed with kodi like metadata.tvdb.com) are disabled!

The problem is that only version 17 does this stupid thing! Deleting addons.db on version 14 and 16 simply forces kodi to make a new one and results in EVERY addon to be ready and working on next launch, and I am talking about dozens of addons, from major ones (like plugin.video.youtube) to minor ones (their dependencies).
Opening addons.db with an sqlite editor (sqlitebrowser is what I use), shows the many "0" (zeroes) in the "enabled" column, under the "installed" table. Turning all these zeroes to ones requires
- either enable the addons one by one in kodi, which is a long and tedious task
- or some sqlite kungfu with a command which will turn all the above zeroes to ones in one go, which I do not know
- or some built in action to do the same, like scan for installed addons and enable them, which I also do not know.

This weekend, I decided to upgrade my friend's installation to kodi 17 as well, deleting addons.db beforehand. The upgrade happened with no problems other than the disabled addons which had to be enabled again. And as a test, I deleted my addons.db, and now I face the issue I describe.

Moreover, version 17 does not have an option to list all the disabled addons in settings > addons > my addons, like versions 14 and 16 do. Plus, when an addon is disabled, it does not appear in the relevant menu for reinstallation, in case a reinstallation would enable it again. E.g. I can not reinstall the confluence skin via install from repository > look and feel > skin > confluence because it is already installed. If that seems simple to do, try finding the greek language pack in there and install/enable it...

And all that is done because of this stupid behavior of version 17, which is probably hardcoded, because I see no way to configure it, neither in kodi's visible (= accessible via gui) nor in its hidden (= configurable only in some text file) options.

Please do something about it. Thank you.

P.s. I know that every version has its unique numbering of addons.db, eg addons20.db is from kodi 16 and addons26.db from kodi 17, but, for simplicity, i refer to it just as addons.db.


RE: About those disabled addons after deleting addons*.db - trogggy - 2017-10-23

If you search you'll find that it's deliberate behaviour - apparently to make life difficult for some hypothetical box seller. If you go through 'myaddons' and enable everything manually it should be back to normal service. AFAIK any other (easier) solution can't be discussed here.
Edit: your 'test' doesn't sound like a great idea tbh. Why not rename the database instead of deleting it?


RE: About those disabled addons after deleting addons.db - jim_p - 2017-10-23

I am not a box seller, I am just a typical user who installs and maintains kodi on friends and relatives. Sooner or later, I will have to upgrade all them to kodi 17 as well, and this stupid behavior will cost me more time than reinstalling everything from scratch.
As for my "test" idea, do not worry, I have a backup of my kodi configuration and stuff as of early October/late September Tongue


RE: About those disabled addons after deleting addons.db - Klojum - 2017-10-23

We're happy to give you a refund if you are that unhappy with our htpc application.

From a personal view:
- Debian + Kodi = An flawed combination of an older Kodi version and stubborn Debian developers
- OpenELEC 5: simply prehistoric
- OpenELEC 8: product from a 'one-man-band', making awkward decisions when encountering a bug upgrading the Kodi MyAddons database.
- OpenELEC: Has been widely surpassed by LibreELEC in overall support and keeping uptodate with Kodi builds.

Quote:I consider version 17 to be the worst version so far for various reasons which I will not analyse now
You've come so far by registering on the Kodi forum, and now you won't you share your problems? What a shame.

PS: I don't think the Raspberry Foundation will be pleased by your avatar.


RE: About those disabled addons after deleting addons.db - jim_p - 2017-10-23

One at a time...

- Actually, I made the account to report some problems on youtube, soundcloud and twitch addons, but so far I only used github to report the one on youtube. The problem described here happened yesterday, so I started with this.
- It's debian + kodi from the deb multimedia repo, which has a really responsible maintainer. He is the one who made it available to debian users before xbmc was accepted in the stock debian repo in 2012. Plus, although I do respect team-xbmc's work on the ubuntu ppa repo, I would not install ubuntu just for that.
- Openelec 5 is the last 32bit version of openelec. 6 and the future ones are 64bit only. I would love to change it, so please let me know if you have a suggestion for a 32bit distro which follows openelec's idea (just enough os). Hmmm, this seems like a new topic Tongue
- I did not know about openelec being an one man project. However, this one man gives me the ease to request stuff for openelec via github while the ones on libreelec don't. Plus, he also packages/includes htop for openelec, which is a valuable tool for me that libreelec lacks.
- I consider version 17 a bad one because of the too many changes it introduced.
- What is wrong with my avatar? I just wanted one that looks different than the default square smiley thing your forum has. I will change it to a better one when I have time.


RE: About those disabled addons after deleting addons.db - scott967 - 2017-10-23

I understand a requirements decision was taken to require the user to take specific action to install or enable all addons not included with the program install. This I suppose to eliminate "drive-by" installs. I agree that it would be helpful to have better visibility of disabled addons within Kodi (eg, AFAIK, there is no way to at least easily see the status of addons classed as "modules").

scott s.
.


RE: About those disabled addons after deleting addons.db - jim_p - 2017-10-24

When you say "addons classed as modules" do you mean all the script.module.* addons? Yes, these are impossible to find in kodi 17 addon lists Sad
So, I found a quicker way to enable them via the db file. Can I share it or is it considered piracy?


RE: About those disabled addons after deleting addons.db - DarrenHill - 2017-10-24

No, posts that work around it are not allowed.


RE: About those disabled addons after deleting addons.db - rmrector - 2017-10-24

Script modules and other dependencies (like "Grab Fanart" or "Image Resource Select Addon") can be accessed from Kodi settings, System -> Add-ons -> "Manage dependencies". The settings level needs to be at least Advanced to see it.

It is awkward and confusing that these add-ons are treated differently, but Kodi does provide a way to get to them.


RE: About those disabled addons after deleting addons.db - jim_p - 2017-10-25

@rmreactor
What you mention is more like a workaround than a way to access them, but you are correct nevertheless. I will look it up. Thanks

@DarrenHill
Thanks for the clarification.


RE: About those disabled addons after deleting addons.db - jim_p - 2017-12-23

One more annoyance I found in kodi 17 today and it reminded me of rmreactor's post above about script.module.* addons.

I wanted to install plugin.video.playthis, which is a completely legal addon.
https://github.com/anxdpanic/plugin.video.playthis

This addon lists script.module.urlresolver as an OPTIONAL dependency, but I decided to install it by hand anyway. Why isn't it listed anywhere in addon browser? Why does the search return NO results when searching for it with its full name?
I managed to install it like so
Code:
kodi-send --action="InstallAddon(script.module.urlresolver)"
What if I did not know about kodi-send and the action=blablabla parameter? What if I was on windows where there is no kodi-send? Ok, I agree that some things are intentionally made hard to do because of piracy, but this is getting ridiculus. And please, no stupid, mocking comments about refunds etc this time. I really hate this opensource-y attitude of some devs.

Needless to mention that on kodi 14 (yes that old one I use on my netbook because there is no newer 32bit version of openelec/libreelec), the addon appears as usual under get addons >  kodi repo > addon libraries.


RE: About those disabled addons after deleting addons.db - scott967 - 2017-12-24

This is not an authoritative answer, but the intent of the "module" media-type is specifically so it is not shown to users as an add-on, since the purpose is that it is installed as a dependency.  As such, it probably is best practice that any required module is part of the official Kodi addon-respository, though I don't know of a prohibition against including one in a 3rd party repository.  In this case, script.module.urlresolver is in the Kodi official repo, but not the version "playthis" requires.  Using identically named add-ons (modules or otherwise) as those in official Kodi repo with different versions I don't believe is supported as it could break other addons that use the official version.

From a developer perspective, making a module add-on "optional" is probably not effective for typical users.

scott s.
.


RE: About those disabled addons after deleting addons.db - jim_p - 2017-12-24

To be honest, I never had an addon from the official repo that needed urlresolver as a dependency. I won't mention the exact reasons I installed playthis, but I intend to use it (= the kodi addon + the browser extension as a whole) as a "cast to" solution from my pc to the pi zero. So, I want that addon to work at its full potential, which means it must play EVERYTHING I decide to throw at it, which, in turn, means to be able to use any method needed for the job, not only the ones script.module.youtube.dl supports.
Considering I am a simple user, can I do what I described? With the current kodi behavior, no. What if I am an advanced user who knows how kodi-send works? Yes and no, depending on my os.

As an advanced user, I partially agree with your opinion on optional dependencies. I think the dev must keep things as minimal as possible so the user's kodi is not filled with junk, without taking away funcionality. Take amber (a skin I use) for instance. It has like 10 or so settings that, when clicked, a small message pops up saying "this function requires this addon to work, do you want to install it?" and the user simply decides. None of them is listed as a dependency, regular or optional.

Good find on the dependency version.


RE: About those disabled addons after deleting addons.db - jim_p - 2018-01-04

And the other way round, because it just happened here. I installed skin.apptv which pulled these 2 as dependencies,
Code:
        <import addon="script.skin.helper.service" version="1.1.3"/>
        <import addon="script.skin.helper.widgets" version="1.0.22"/>
and one more (resource.uisounds.apptv).
I did not like it, so I removed it, along with its sounds. How will I remove the above dependencies? They do not show up as orphaned dependencies and, being script.* ones, they do not show up anywhere else, but they are still installed
Code:
$ ls .kodi/addons/ | grep "script.skin"
script.skin.helper.service
script.skin.helper.widgets
I know I can delete the above folders, but this is the expert way of dealing with it. What is the ui way, or the user friendly way of doing it? I doubt there is one...


RE: About those disabled addons after deleting addons.db - host505 - 2018-01-04

(2018-01-04, 11:03)jim_p Wrote: And the other way round, because it just happened here. I installed skin.apptv which pulled these 2 as dependencies,
Code:
        <import addon="script.skin.helper.service" version="1.1.3"/>
        <import addon="script.skin.helper.widgets" version="1.0.22"/>
and one more (resource.uisounds.apptv).
I did not like it, so I removed it, along with its sounds. How will I remove the above dependencies? They do not show up as orphaned dependencies and, being script.* ones, they do not show up anywhere else, but they are still installed
Code:
$ ls .kodi/addons/ | grep "script.skin"
script.skin.helper.service
script.skin.helper.widgets
I know I can delete the above folders, but this is the expert way of dealing with it. What is the ui way, or the user friendly way of doing it? I doubt there is one...

It's called "search"Wink
But you have to be quick reading the notifications while dependencies are being installed, and of course have notifications enabled, and remember which ones were installed...
So I guess no user friendly way, on most cases they will remain installed and unused...