Bug 333745 - Amarok exports unreadable playlists for other players...

[Thomas Lübking]

On Mittwoch, 8. April 2015 02:14:26 CEST, Alan Ezust wrote:
> This is a change in the behaviour from previous versions of Amarok, however.

Can't say, but just installed amarok and tried: it's a bug.

This entry:

../../music/Klassik/Beethoven/Complete%20Symphonies/No.%203%20%20Es-dur%20Eroica%20-%201%20Allegro%20con%20Brio.mp3

is a relative path (the info, I btw. I asked for several times before) and should (aka. "must") not be percent encoded.

> And it is possible to use different *encodings* for url when serializing or
> de-serializing them.

I doubt that introducing your hand-crafted custom encoding would improve anything here.

> technically, you are not supposed to have actual spaces in URLs
This is not "technically" and you MUST not have spaces (and some other chars) in a URL.

> URLs are supposed to be on each line of a .m3u file
Nope. m3u's may contain urls or (relative) paths.

Since this seems a major communication blocker in this thread:


This is a URL:
file:///path/to/file.mp3

This is a relative path:
path/to/file.mp3

And this could be "on the edge" (meaning that ideally a robust reader *should* try path and url):
/path/to/file.mp3

For completeness sake:
a URL could theoretically even be considered a relative path, but if you have a subdirectory "file:" and insert dead separators ("//") into the saved path, that might be considered ebkac ;-)


Cheers,
Thomas