Kodi Community Forum
Bug Skin settings not being retained profile to profile in Jarvis - 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: Bug Skin settings not being retained profile to profile in Jarvis (/showthread.php?tid=248318)

Pages: 1 2


RE: Skin settings not being retained profile to profile in Jarvis - Garfield135 - 2016-01-30

Greetings,

Kodi 16 rc2 - behavior as described
Kodi 17 20160129 - behavior as described

I've done some more testing ...
- starting kodi and loading profile looks good
- switching profiles always uses the profile settings we switched from and not the settings we switched to

Have a nice day!

Garfield


RE: Skin settings not being retained profile to profile in Jarvis - rainman74 - 2016-02-02

re-testet with Kodi 16.0 RC 2 on Android... everything works fine here! :-)


RE: Skin settings not being retained profile to profile in Jarvis - rainman74 - 2016-04-04

Profiles still aren't 100% independent again in 16.1 RC1 and 16.1 RC2 ! What's wrong?

It seams that there is still a problem, perhaps in chaching (?) "addon_data" directories where settings.xml files for skins are placed?


RE: Skin settings not being retained profile to profile in Jarvis - rainman74 - 2016-04-06

... any ideas for that long drawn profile problem?

The new feature "Split up skin settings" was officialy indroduced with Kodi 16.0 Alpha 1 on Sep 03, 2015. That means this bug is now 7 month old :-(


Skin settings not being retained profile to profile in Jarvis - Memphiz - 2016-04-06

so what? We don't have anyone fixing bugs based on bug age if you think that?


RE: Skin settings not being retained profile to profile in Jarvis - Scott00007 - 2016-04-06

Why not? That would just be common sense. Older bugs should be fixed before new ones.....but only if you want the software to get better and not just to add one more version to the name........so I'm guessing that version 18 or 19 will happen so that the development team can say "look at all the work we do"....all the while core features like this will stay broken.....it's dumb but it's the new approach that is being taken.....broken things don't need to be fixed if a new version is in the works...just move on and forget.


RE: Skin settings not being retained profile to profile in Jarvis - rainman74 - 2016-04-06

@Scott00007: You're completely right.

As a KODI fan I don't need KODI 17+, I only wish a much more stable and feature complete 16.x version.


RE: Skin settings not being retained profile to profile in Jarvis - Martijn - 2016-04-06

(2016-04-06, 14:00)Scott00007 Wrote: Why not? That would just be common sense. Older bugs should be fixed before new ones.....but only if you want the software to get better and not just to add one more version to the name........so I'm guessing that version 18 or 19 will happen so that the development team can say "look at all the work we do"....all the while core features like this will stay broken.....it's dumb but it's the new approach that is being taken.....broken things don't need to be fixed if a new version is in the works...just move on and forget.
You are welcome to try and fix it. Each dev has his/her own agenda and no one is forced to fix something he doesn't want to work on.
So as is it seems no dev is using profiles or it works for their use case.

Also no one forces you to upgrade. You choose to do that yourself. You can always go back to v15


RE: Skin settings not being retained profile to profile in Jarvis - Ned Scott - 2016-04-07

To explain, the real issue here isn't so much that a bug has come up, but that the current profile system has already been identified as broken. This kind of settings spill-over happens a lot, and for many years. The "fix" is to completely replace the profiles system. This is no small feat, and since the profiles feature is not used as much as others, it gets put on the back burner. That's actually a fairly reasonable approach, IMO, and I am someone who does use profiles.

That being said, it's normal to wonder "why". It's not a demand, it's just a curiosity. Cheers.


RE: Skin settings not being retained profile to profile in Jarvis - Scott00007 - 2016-04-07

(2016-04-07, 07:26)Ned Scott Wrote: To explain, the real issue here isn't so much that a bug has come up, but that the current profile system has already been identified as broken. This kind of settings spill-over happens a lot, and for many years. The "fix" is to completely replace the profiles system. This is no small feat, and since the profiles feature is not used as much as others, it gets put on the back burner. That's actually a fairly reasonable approach, IMO, and I am someone who does use profiles.

That being said, it's normal to wonder "why". It's not a demand, it's just a curiosity. Cheers.

Thanks for the info.


RE: Skin settings not being retained profile to profile in Jarvis - rainman74 - 2016-04-07

Thanks for the info, too!

For parents with children at least two profiles are strongly necessary... and with that bug, parents occasionaly get the profile-skin-settings from the children (kids background, disabled menu buttons, etc.)...


RE: Skin settings not being retained profile to profile in Jarvis - scott967 - 2016-04-07

Even without profiles, I don't think skin settings get updated to file until the skin is unloaded. So there doesn't seem to be any way to backup skin settings from within a skin. I don't know if this also impacts what happens on a profile switch, but suspect it is related.

scott s.
.


RE: Skin settings not being retained profile to profile in Jarvis - rainman74 - 2016-04-07

i think it could be a problem with the caching of addon-settings (e.g. \addon_data\skin.confluence\settings.xml). Occasionally a still cached settings.xml from the last active profile gets loaded instead of the settings.xml file on filesystem of the new logged on user. Then that "other" settings.xml overwrites the physical settings.xml from the logged on user and voila...