Support for intl letters in playlists (bug !)


International letters of the ANSI (Windows-1252) charset are NOT supported by the WDTVLive playlists processor, despite having “Western Europe” support enabled.

Problem shows in audio mode : files which path or name includes special characters can be browsed and played without problem… as long as you’re not using an m3u or wpl playlist to play them (they’re just kicked out from list !).

I tested removing those characters from both playlists and file paths and names, and it allowed the very same playlists to work fine. NOT an acceptable solution !

Please… fix it !

I will escalate this to the product team.  Can you also post this as an idea in the Ideas Lab?  We do have product people looking at the Ideas Lab, and this way we can hit them with it two ways.

Ideas Lab

WDTV Live’s Windows-1252 support is only for subtitles and does not support Windows-1252 characters for filenames.

I have placed this on our future features request list for you as I do not see this being a big issue to add to the unit.

I found a solution !

→ use UTF-8 character encoding ←

“m3u” playlists with an UTF-8 encoded content ARE suported by the WDTVLive and as far as I can tell from my music collection, all file paths & names with unusual characters are correctly handled now.

From what I understand about encodings, supporting UTF-8 is a clever choice, as it is more likely than any other encoding to support a real-world variety of characters. Pretty important to international music fans like me.

On the other hand most users probably don’t even know what a character encoding is, and playlists are unfortunately often encoded with something else than UTF-8.

So I would say this is finally not a bug, but rather an information problem. WD’s design is actually good. But the “UTF-8” keyword should definitely appear somewhere in the WDTVLive documentation. Preferably close to the “m3u” keyword.

Thank you Bill / James for your quick moves !

Hope this can help other users - Rad

Radenim wrote:

So I would say this is finally not a bug, but rather an information problem.

I’d still call it a bug since those special characters (german umlauts at least) are listed in the file browser as well as depicted from SRTs that are encoded in ANSI instead of UTF-8.