Skip to content
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

Support %characters in m3u files and other m3u complexities #1215

Closed
kbridger opened this issue Jun 29, 2021 · 3 comments · Fixed by #1275
Closed

Support %characters in m3u files and other m3u complexities #1215

kbridger opened this issue Jun 29, 2021 · 3 comments · Fixed by #1275

Comments

@kbridger
Copy link

kbridger commented Jun 29, 2021

Is your feature request related to a problem? Please describe.

I am trying to synchornize my playlists across Navidrome and my desktop player and be able to play them on mobile apps. I am leveraging the playlist import/sync capabilities in Navidrome (thanks for that!). I have my playlists in a folder saved as .m3u. Navidrome reads these and imports them nicely.

The problem is that my desktop app (Lollypop player for Gnome) saves m3u files in a format different than what Navidrome understands. When I make changes to the playlist in Lollipop and save them to the file, Navidrome does not update because it fails to find the files specified in the updated m3u file.

Specific problems:

  1. Lollypop saves m3u files with a song per line:
    file://

It appears this might not be supported by Navidrome's importer.

  1. Lollypop saves paths like a URL, translating spaces and other characters into %. Navidrome can't parse these and just fails to find the file. If I manually change this in the m3u to replace the % with proper characters then Navidrome can find the files.

Describe the solution you'd like

I make a change in Lollypop's playlist, Lollypop saves the changes to the playlist (current functionality). Navidrome notices the updated m3u and re-parses it (current functionality). Navidrome parses the updated m3u and the playlist update appears in Navidrome.

Describe alternative solutions that would also satisfy this problem

Apparently m3u is not really a "standard" so this can be complex.

I've reviewed why Lollypop saves m3u in this format and the author had good reasons in his mind. So asking him to save in a different format went nowhere from what I could see. He relies on a library that he doesn't control.

Additional context

Sample m3u file from Lollypop
#EXTM3U
file:///media/Music/Tycho/Weather/02%20-%20Pink%20&%20Blue%20(feat.%20Saint%20Sinner).ogg
file:///media/Music/Kelly%20Finnigan/The%20Tales%20People%20Tell/06%20-%20Since%20I%20Don't%20Have%20You%20Anymore.ogg

Changing it to the following allows Navidrome to parse it
#EXTM3U
/media/Music/Tycho/Weather/02 - Pink & Blue (feat. Saint Sinner).ogg
/media/Music/Kelly Finnigan/The Tales People Tell/06 - Since I Don't Have You Anymore.ogg

@certuna
Copy link
Contributor

certuna commented Jun 29, 2021

It's not so much the % character, what you're looking for is support in Navidrome for local filepaths encoded as URLs. M3U can contain file links as either a URL or a local filesystem path. Most applications write local files as filesystem paths in playlists, and remote files as URLs (https://servername.com/musicfile.ogg), but it seems that Lollypop also writes local paths as URLs (file:///). That's unusual but in principle it is allowed in the M3U specs, so yes I guess it's a good idea for Navidrome to support that.

@deluan
Copy link
Member

deluan commented Jun 29, 2021

I agree with @certuna, this is unusual but covered by the specs, and Navidrome should support it (file:// schema).

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 10, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants