Bug: Icons with unicode characters may be reset to DefaultShortcut.png

[ghost]

When checking for icon overrides, one of the checks is to ask Kodi if the skin has the image in question. When there is unicode in the name, this check may return False even if the image does exist.

As the problem is not readily reproducible in a consistent manner, and my time is limited at present, I'll fix this when I can get into the problem properly.

[phil65]

One small advice: try to make sure as early as possible that all your inner workings are using unicode.
That for example means that everything you get from the kodi API needs .decode("utf-8"), otherwise it is a str.

from __future__ import unicode_literals

might also help, it automatically prefixes all "text" with u then (--> u"text") so that they are unicode.

Was struggling a long time with this myself but finally got everything right :) I dont need any try_decode() stuff anymore anywhere in my script.

[ghost]

Undoubtedly good advice, and advice I've taken into account with my recent update to the library node editor. In terms of this script, doing so requires a lot of code-checking and testing to ensure that no bugs are introduced (as, at present, we're using try_decode to handle the text being or not being unicode). In general terms, if scripts need to - by par of the course - convert anything coming from Kodi to unicode, there is a definite argument that Kodi should be providing text in this format by default ;)

In terms of this specific issue, though I haven't had time to get into it properly yet - and won't for a few days yet - the underlying format of the string, and therefore how it's imported into the script, processed, and so on, doesn't initially appear to be related to the issue. When initially adding a shortcut via the context menu add-on the text is unicode and the correct icon appear; when updating the icon of another shortcut the context menu add-on text is still unicode, but the correct icon doesn't appear - suggesting that, whilst the issue is unicode (as it only appears to affect paths with unicode), it's not how the text is encoded/decoded at issue (though it may well be related to the unicode workarounds that we have in place...)