I have the same problem. Same platform and same version of Amarok. 
Please check if the failure has to do with internationalization, which in my case is Portuguese-Brazilian. 
I love the Amarok playlists creator, but as my lists has many songs is difficult to remove these special characters manually.

Well, this is due to some files still using the long obsolete ISO encoding instead of UTF, if you set all your systems to UTF there shouldn't be any problems.
FWIW: my system is set to UTF only and I can't reproduce this with special characters,  like accented characters in French for example. There are no strange characters here, éàèô or ç just display correctly.

So please check that your system and more specifically your files are all encoded to UTF, including the ID3 tags, this should just work. I have only seen such character mismatch with files imported from other systems (Windows file systems mostly, where some computers were migrated from version to version and never moved to UTF encoding, which is default since Windows 7 IIRC).

Although Brazilian, I do not I record ID3 tags with accents. Also, I noticed that my system is configured globally to use UTF-8. Just to make sure, I also re-recorded some ID3 tags forcing the use of UTF-8, but the result was the same. 
It is interesting to note that the Clementine application does not have this behavior and exports "playlists" without these strange characters. 
I believe there is something in Amarok's code that is not dealing well with "spaces", "single quotes" and other non standard characters.

Very strange, because it does work here for me in the git version for the Swiss French locale, maybe this was fixed already?

May be you are right. How can I install the git version, I would like to test it.

(In reply to comment #5)
> May be you are right. How can I install the git version, I would like to
> test it.

You can follow this guide: 
http://blogs.fsfe.org/myriam/2009/09/26/compiling-amarok-from-git-locally-full-summary/ 

You will also have to remove the package provided by the distribution, else it will make changes in path and environment settings more complicated.

Anyone solved this nasty issue? Or any workaround?

Nice to hear from you!

Peter

Sad, but the workaround that I found was uninstall amarok and install Clementine...

(In reply to peddanet from comment #7)
> Anyone solved this nasty issue? Or any workaround?
> 
> Nice to hear from you!
> 
> Peter

You are welcome to give a hand ...

   --
   Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail
   gesendet.



   Peter Wein <Peter.Wein@gmx.net>schrieb:

     If I have one valid, I will give it to you!

     For me it is very annoying , it was working last month perfectly,
     but I guess some late updates, potentially the big upgrade from
     12.04 did it!

     I tried to manually convert it, but failed. If I have the script,
     I can send it to you...

     Regards Peter
     --
     Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail
     gesendet.



     Myriam Schweingruber <myriam@kde.org>schrieb:

       https://bugs.kde.org/show_bug.cgi?id=333745

       --- Comment #9 from Myriam Schweingruber <myriam@kde.org> ---
       (In reply to peddanet from comment #7)
       > Anyone solved this nasty issue? Or any workaround?
       >
       > Nice to hear from you!
       >
       > Peter

       You are welcome to give a hand ...

       --
       You are receiving this mail because:
       You are on the CC list for the bug.

Peter: if an update of your distribution caused the problem then it is not an Amarok bug, but more likely something went wrong in the update.

FWIW: Amarok did not change it's code for 2.8 in over a year, so the culprit is elsewhere

   I suppose the problem lies somewhere in the locales (I just
   speculate), but the codes looked mixed up, some of them are definitely
   UTF8, others are ASCII, but what they have in common, that they
   interpret it in "I do not know the correct terminus"-http speak
   :-)...., so like %20 for space and %c4%b9 for Ĺ -sign or so... So for
   me it looks like the system finds a different codec but isn't able to
   translate it to the correct sign, so it prints out its hexadecimal
   representation... I have manually meanwhile translate one table so I
   could burn it partly with brasero, this is the reason for what I am
   searching for a solution, but it would be also nice, if it could work
   OS-independent... it is possible to put this in a bash script, but
   this is a rather bad workaround...and until now, it is not totally bug
   free...but it's easy. Cheers Peter *Gesendet:* Montag, 01. Dezember
   2014 um 11:24 Uhr
   *Von:* "Myriam Schweingruber" <myriam@kde.org>
   *An:* peter.wein@gmx.de
   *Betreff:* [amarok] [Bug 333745] Amarok exports unreadable playlists
   for other players...https://bugs.kde.org/show_bug.cgi?id=333745

   --- Comment #11 from Myriam Schweingruber <myriam@kde.org> ---
   Peter: if an update of your distribution caused the problem then it is
   not an
   Amarok bug, but more likely something went wrong in the update.

   FWIW: Amarok did not change it's code for 2.8 in over a year, so the
   culprit is
   elsewhere

   --
   You are receiving this mail because:
   You are on the CC list for the bug.

I have completely wiped my system and put Ubuntu 14.04 on it. I will try to reproduce the behaviour in the next few days.

While I assigned to myself, I am still having troubles getting my dev environment setup, so if someone else can fix this faster, be my guest to assign yourself.

And my speculation is that there is a change in either KUrl or QUrl's behavior that is causing this bug.

*** Bug 325369 has been marked as a duplicate of this bug. ***

Created attachment 99076 [details]
Non-problem-solving ugly script to remove the url quoting.

Hi!

I would describe this attachment as non-helpful in terms of solving the problem. But it will take a problematic m3u and overwrite (ignorantly write) another file with the suffix "_unquoted.m3u" without any checks. So no guarantees whatsoever.

If I had time to dig into the problem---but python is so awfully convenient...

Cheers,

Jan

Created attachment 99086 [details]
Fix the encoding in m3u exports using QUrl::path().

I had no luck using the FullyDecode-flag when using toString(), the flags were only partially removed. While I would prefer to have full urls, I am now using path(). With path(), the %-encodings are removed (FullyDecode is the default for this function).
The m3u-exporter seems to check if the track is a file or not, thus the patch should not change stream urls. But for other exporters, this check would have to be implemented.

Probably, this helps developers who know what they are doing. :-)

Cheers,

Jan

Have had this problem when copying the Amarok generated playlists into kodi.

Tried the patch from Jan-Matthias Braun, with not much success. There have been less % encoded characters, but not all have been removed.

I helped me by changing ~/kde/src/amarok/src/core-impl/playlists/types/file/PlayListFile.cpp, so that the path is never encoded. As this helps me, it will not be not of much help if you really have to store urls in the playlist. For a real fix I think you must distinguish the cases if a track is referenced by a file path or url.

QString
PlaylistFile::trackLocation( const Meta::TrackPtr &track ) const
{
    KUrl path = track->playableUrl();
    if( path.isEmpty() )
        return track->uidUrl();

    if( !m_relativePaths || m_url.isEmpty() || !path.isLocalFile() || !m_url.isLocalFile() )
//        return path.toEncoded();
      return path.path();

    QDir playlistDir( m_url.directory() );
//    return QUrl::toPercentEncoding( playlistDir.relativeFilePath( path.path() ), "/" );
    return playlistDir.relativeFilePath( path.path() );
}

Git commit 3a3367e6aeee5a26c4191821055f656ce7ce3f4a by Tuomas Nurmi.
Committed on 06/07/2024 at 16:24.
Pushed by nurmi into branch 'master'.

Improve encoding when exporting playlist files

Try to avoid excessive escaping local paths when exporting playlist files, and take
one step more to ensure that remote URLs are encoded sensibly.

I tested exporting to each playlist format and both Amarok and VLC seemed to be able
to open each of the files and URLs on them (including local files with non-UTF-8
characters and remote streams with spaces in URL etc). Rhythmbox apparently doesn't
support streams in playlists, but loaded the local files OK, too. In theory, e.g.
m3u shouldn't be UTF-8 (m3u8 is a separate file format for that), but at least all
three tested players successfully loaded tracks with paths saved as UTF-8, so it's
probably OK.

I'm definitely not confident this is perfect now, but I'm quite sure it is notably
better than it was before.

M  +10   -3    src/core-impl/playlists/types/file/PlaylistFile.cpp

https://invent.kde.org/multimedia/amarok/-/commit/3a3367e6aeee5a26c4191821055f656ce7ce3f4a