m3u playlists in non-English ANSI CP are broken

Problem description:

http://forum.videolan.org/viewtopic.php?p=89319#89319

By looking at stream_ReadLine() in src/input/stream.c, it activates apropriate conversion when some Unicode BOM is detected - but does not activate any when no BOM was detected (i.e. when the m3u playlist is in ANSI CP). In this case we obviously need to convert ANSI CP => UTF8

Incorrect. without a BOM, we simply DON'T KNOW. It can be anything. It's up to the M3U parser to determine the charset. Unfortunetly, the M3U systems doesn't support such a thing. It can be UTF-8, ANSI, KR anything. The only thing we might be able to do is to GUESS the locale, much as we do for subs, but that idea is fundamentally flawed of course.

This is why most modern playlistsystems have charset designations as part of the fileformat.

Also, no way this is gonna be fixed before 0.8.6 It requires too many changes, which i won't allow at such a late state in the release.

Can't we perhaps introduce an option (default off) which will make VLC assume it's ANSI CP if the user activates this option?

(this is what other players are doing)

assigned to @Courmisch

Unfortuntaly, we cannot fix this without extensive changes. It would conflict with other uses of stream_ReadLine(). The only band-aid work-around I can think of would involve invoking IsUTF8() in the m3u code, and using FromLocale if it reports malformed UTF-8 data.

(In [18230]) M3U: fallback to local code page if UTF-8 fails (close #862 (closed))

added Status::fixed label

closed

Md: please test then backport if you feel like it. Thanks.

(In [18261]) Backport [18230] closes #862 (closed) for 0.8.6-branch