skin migration and addon compatibility checking

[tamland]

This adds compatibility checks for addons on startup, replacing the weird repository workarounds current in place. It will now checks all installed addons and disable them/notify.

Similarly, the skin (special treatment because it breaks every release, and it's critical that it works) will be auto-updated, or if that fails fallback to default skin, preventing incompatible skins from being loaded.

[ronie]

nice one, thx!

[MartijnKaijser]

awesome. Very much appreciated :)
Wanted to try on Windows but fails to build http://jenkins.kodi.tv/job/WIN-32/9775/console

[tamland]

jenkins build this please

[tamland]

builds now;)

[MartijnKaijser]

@tamland it seems indeed to mark skins incompatible and switches to default skin. However is does this check before it fetches data from the newer repo which does compatible skins/addons. So now all current installed versions are marked "disabled" while it should probably first fetch the updates before just hitting everything disabled and the users needs to get everything sorted again. Additionally users are now still able to enable "incompatible" add-ons again while this should not be possible?

[MartijnKaijser]

Seems there's a small additional issue. Tvtunes (as example) is marked incompatible but it's not auto disabled while it should be.

[tamland]

Hm, I think we have to make a choice to either accept that it doesn't automatically updates, or don't do any disabling, only warn about it. Auto updating everything before startup is not an option; this can take far too long time.

What you're seeing with tvtunes is expected. There's an update for it that is marked broken, but it's not incompatible or have unmet dependencies in any way. These are completely different things previously mushed together.

[MartijnKaijser]

Well if it's marked broken it should certainly be disabled. To me incompatible and broken are the same and disabled is the way to go without option to re-enable unless a fixed version is found.

Leaving user with a warning and don't disable doesn't sound like an option cause that will leave it in broken state. Forcing the user to go and hunt down Addons that do have working update but the Addon is disabled isn't a very good option as well.

Edit:
Preferred would certainly be update all available before startup. Not sure what should be done if usr has auto update Addons off.
Should go in same category as database upgrades and a "busy upgrading" splash with some indication it's not stuck would be ideal

[MilhouseVH]

I've added this PR in my test builds. In my test builds I include the Kodi Game repository.

This repository is being reported as incompatible:

which is fine, as it is incompatible.

However, this popup is appearing every time Kodi is started - is this expected behaviour?

[ronie]

i've tested this and it all appears to work fine on my end.

kodi waits at the splash screen while the selected skin is being updated.
after switching to the home screen, all the other addons get updated.

nothing ends up disabled at my end, except the re-touched skin, which is correct.

[MartijnKaijser]

Seems my auto update setting was off for whatever reason, Sorry for that confusion.
Tried again and now it crashes on upgrade
thread log http://pastebin.com/1B0hWHgG
debuglog http://pastebin.com/yRhfSgrw

[ronie]

yeah, i got the crashes as well.
http://paste.ubuntu.com/23095159/

the crashlog seems to indicate the skin helper addon is causing issues.
after deleting the addon and all skins that depends on it, the upgrade went fine.

i think what happens is the skin helper addon is started (as a service) before the skin has loaded, because kodi is still busy downloading the krypton version of the skin you're using.
the helper addon tries to evaluate a skin setting (Skin.HasSetting(SkinHelper.EnableAnimatedPosters)), but i assume these settings are not available as the skin hasn't been loaded yet?

result: crash-boom-bang.

[ronie]

edit: it's not the addon itself thats evaluating the skin setting...

it's kodi reading the context menu section of the skin helper addon.xml file
https://github.com/xbmc/repo-scripts/blob/helix/script.skin.helper.service/addon.xml#L16

[tamland]

jenkins build this please

[tamland]

Ok, the amount of unrelated fixes is piling up!, but as far as I can test it doesn't crash now.

[tamland]

@MilhouseVH I can only guess but probably it's reenabled or cant be disabled for some reason (eg it's a required system addon).

Well if it's marked broken it should certainly be disabled. To me incompatible and broken are the same and disabled is the way to go without option to re-enable unless a fixed version is found.

The 'marked broken' stuff is not touched here. It should still show popups (all 50 of them). It just wont be part of this startup process because logically they are completely different things.

Leaving user with a warning and don't disable doesn't sound like an option cause that will leave it in broken state. Forcing the user to go and hunt down Addons that do have working update but the Addon is disabled isn't a very good option as well.

Edit:
Preferred would certainly be update all available before startup. Not sure what should be done if usr has auto update Addons off.

And if user have a lot of skins and addons installed, a slow connection or the mirrors are slow? It's not hard to imagine an update like that is going to take an hour. That's just an unacceptable wait time.

I think we need to pick our battles here. If an upgrade require some manual intervention, so be it. Any sort of migration we do is always going to be an 80% solution. I'd rather see the 'hunt down addons' and re-enabled process made easier and do the safe thing (it already lists all problem addons so there should be no surprises to the user).

[MilhouseVH]

The repository.kodi.game add-on is "built in" to the image (so not user installed) and is also present in the addons-manifest.xml - the disabled button is greyed out so doesn't appear possible to disable. If we can't avoid the repeated "incompatible" messages at startup then the best short-term option would be to drop this repository from LibreELEC (unless whoever maintains it can address the incompatibility, is this @garbear?)

Edit: Add note to clarify inability to disable this add-on. Also to add that the best option would be to ship a compatible add-on, we included this repo to facilitate testing but clearly things aren't progressing in that direction so dropping the repo will be best, at least in the short-term. It's not this PR's fault if we ship a broken add-on. I'll drop it from my own builds starting from tonight, and if repository.kodi.game remains broken then I guess we'll have no option but to eventually drop it from LE master.

[tamland]

Changed it to not include failed ones in the dialog, just log a warning. Should be ok in this case.

[tamland]

jenkins build this please

[MartijnKaijser]

Looks like non relevant fail on linux. Just to be sure...
jenkins build this please

[tamland]

So, beta 2 or beta 3?

[MartijnKaijser]

I don't see beta2 happening this week and we have several days of devcon. I'd say merge :)
Thx

[bkuhls]

Afaics this commit causes a segfault when starting Kodi.
This is the last working commit: fcce26e
This is the first broken commit: 8836740

The segfault also occurs when Kodi is started with an empty home directory so I guess the choice of addons installed does not play a role here.

System is Linux, kernel 3.18.36 i686, uClibc, gcc 4.9.2, cross-compiled using buildroot,
kodi.log was not created, so I can only provide a gdb backtrace:

Program received signal SIGSEGV, Segmentation fault.
0xb5b197ab in std::string::_Rep::_M_grab(std::allocator<char> const&, std::allocator<char> const&) ()
   from /usr/lib/libstdc++.so.6
(gdb) bt full
#0  0xb5b197ab in std::string::_Rep::_M_grab(std::allocator<char> const&, std::allocator<char> const&) ()
   from /usr/lib/libstdc++.so.6
No symbol table info available.
#1  0xb5b197f8 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) () from /usr/lib/libstdc++.so.6
No symbol table info available.
#2  0x082e7e09 in pair<ADDON::TYPE, void> (__x=<optimized out>, __y=..., this=0xbffffbbc)
    at /home/fli4l/.fbr/fbr-unknown-custom-x86/buildroot/output/host/usr/i586-buildroot-linux-uclibc/include/c++/4.9.2/bits/stl_pair.h:134
No locals.
#3  __static_initialization_and_destruction_0 (__priority=65535, __initialize_p=1)
    at AddonSystemSettings.cpp:66
No locals.
#4  _GLOBAL__sub_I_AddonSystemSettings.cpp(void) () at AddonSystemSettings.cpp:170
No locals.
#5  0x08e4c287 in __do_global_ctors_aux ()
No symbol table info available.
#6  0x082936f1 in _init ()
No symbol table info available.
#7  0xb5a5c4eb in __uClibc_main () from /lib/libc.so.0
No symbol table info available.
#8  0x08306c72 in _start () at libc/sysdeps/linux/i386/crt1.S:128
No locals.

[MartijnKaijser]

@tamland
Probably same issue on Android
http://forum.kodi.tv/showthread.php?tid=290934

Same happens on my phone/tablet.

[koying]

http://flightgear-devel.narkive.com/ytqWx9LM/static-array-of-std-string-valid
Basically, might be that the CSettings::SETTING_* std::strings are not constructed, yet

Probably compiler dependent.

[Paxxi]

Could very well be, just move it into the class as a non-static member variable and we should be fine for beta

[tamland]

#10476

[BigNoid]

@tamland with this PR there's something wrong with storing the skin settings. The log is not really interesting but you can easily reproduce by disabling a main menu item in Estuary and than doing a skin reload on the Home screen. Each reload hides/shows the disabled menu item.

[BigNoid]

ping @tamland
The alternating skin settings on reloadskin() is quite annoying for skin development. Can you take a look please?