[scott967]

Hi everyone,

Any progress on this feature? Actually  > 50% of my music files have unicode special character in their names. So I would like to see this feature actually get implemented and am even willing to do it myself.
Considering back compatibility, code changes and potential influence to other programs discussed above, I suggest this feature to be implemented in the following way:

When saving playlists, create m3u8 files (with .m3u8 extension) by default unless the name of the playlists ending with ".m3u"

I skimed kodi's GUI code. Adding new options to choose which format to "save as" requires changes to both interface message handling and skin files. And I am not sure if adding new options in the GUI brokes 3rd-party skins.

Besides, I am having this problem in a Linux, whose local charset is already configured to "UTF-8". Kodi seems to set default UserCharSet to "CP1252" (windows) ignoring my locale settings (see xbmc/LangInfo.cpp function CLangInfo::SetDefaults()). To make things worse, I cannot find UTF-8 as an option in kodi Settings->Interface->Regional->Character Set
I have checked that if I change the default charset to "UTF-8", m3u playlists work fine with my songs in my linux setup.
I would like to confirm if "ignore locate settings and force UserCharSet to be CP1252" is a bug or I configured something wrong. And why "UTF-8" is not listed as an option in kodi settings?

Thanks!

I'm pretty sure the system environment locale is only used for setting the collation.  Otherwise Kodi regional settings are used.  Note that for Android and maybe iOS the locale is forced to "C" as Kodi doesn't access the system's localization apis for those platforms.

I'm not sure when the user character set gets used, other than for reading subtitles (and that's a different setting than the UI setting).  Also when you set the UI language (install a language resource) the resource addon sets a default UI and subtitle character set.  But AFAIK, all the strings in strings.po are encoded utf-8.

It does seem like if a UI charset option of utf-8 was available, that would help, though still needing the m3u8 extension.

Something else to consider from a text charset decode standpoint is cue sheets.  It's been a while but ISTR that in testing cue sheets encoded in utf-8 they will be read but if there is a BOM the first line of the cue sheet is dropped.  Obviously a BOM isn't needed in UTF-8 but Windows seems to like to encode it anyway.

I suppose if the charset is set to utf-8 that would work OK if m3u are strictly ASCII (<128).

I looked at the wiki pages, and I think they have errors.  For example Language_support (wiki) says the UI character set is used in reading mp3 tags.  However, both ID3 2.3 and 2.4 specify that ISO 8859-1 must be used if not utf encoded.  And since 8859-1 != CP1252 in the range >127 it would be a bug to use that charset to decode ID3.  And the default UI and subtitle charsets are defined in addon.xml, not langinfo.xml as indicated here Language_support (wiki).

Maybe some of the intent of the user charset was to access the ttf font character map, but I think any ttf today has a unicode table in the character map so using unicode should suffice.

scott s.
.