New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhance M3U UTF-8 encoding support #1370

Open
tkem opened this Issue Dec 23, 2015 · 6 comments

Comments

4 participants
@tkem
Member

tkem commented Dec 23, 2015

As observed by @Joolee in #1364, there are several issues with the M3U backend's current (lack of) UTF-8 encoding support:

  • Though UTF-8 is supported when reading .m3u8 files, M3UPlaylistsProvider.save() will always use Latin-1 encoding.
  • Some clients use the .m3u extension and a BOM when saving M3U playlists in UTF-8 encoding. If these are to be supported, the BOM should probably also be written when editing and saving such playlists.

Generally speaking, the M3U backend badly needs some love, and also a major refactoring IMHO.

@tkem

This comment has been minimized.

Member

tkem commented Dec 23, 2015

Note that @Joolee's patch uses the external chardet module, which is not used by Mopidy yet. Whether we want to introduce an additional dependency remains TBD. This wouldn't be much of an issue if the M3U backend was split from Mopidy core, as already planned, and made a separate extension.

@jodal

This comment has been minimized.

Member

jodal commented Dec 29, 2015

I'd prefer to not add any deps as long as it is part of Mopidy core.

@adamcik

This comment has been minimized.

Member

adamcik commented Dec 29, 2015

Then BOM check can probably be done just fine without the extra chardet module, as we only need that if we want to guess what the rest of the file is. An other option could also just be to have a list of encodings to fallback to. But at the same time I'd rather kill our playlist parsing in favor of the totem libs.

@tkem

This comment has been minimized.

Member

tkem commented Dec 29, 2015

@adamcik: Parsing is just "half" part of the API - do the totem libs also support writing playlists?
@jodal: Me too, so as a first step I consider making the encoding for *.m3u configurable, with default latin1 but can be set to utf-8-sig by the user.

@kingosticks

This comment has been minimized.

Member

kingosticks commented Dec 29, 2015

@tkem

This comment has been minimized.

Member

tkem commented Dec 29, 2015

@kingosticks: Thanks! However, since totem-pl supports several playlist formats, I'm wondering whether this shouldn't become a separate backend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment