The "Add URL(s) to bottom of playlist" feature applies URL decoding which breaks some URLs

[marrmist]

Describe the bug
syncplay appears to have an additional step when you add URLs to the bottom of the playlist (this does not happen when you use "Edit playlist") where it decodes URLs. I assume this is meant to look nice, but the problem is, this is not a lossless operation, and the ambiguity will catastrophically change how some URLs are then interpreted.

This bit me in particular because of my workflow where I download podcasts into my web share in order to listen with friends. My podcast software was naming files based on the episode title metadata, which sometimes started with an episode number like #802. The proper URL for these files encodes that #. When "unquote" is called (I think in OpenAddURIsToPlaylistDialog), the resulting URL ends up getting interpreted as a fragment link, and the fragment is not sent to the http server, thus the link fails to load for everyone.

It is worth noting that there are numerous other potential encoding ambiguity issues, I think including ones with worse ramifications (like causing a request to go to a different domain entirely), and '#' turning into a fragment is just what bit me in particular here.

To Reproduce
Steps to reproduce the behavior:

1. Place a file on an http file host with a filename starting with '#'
2. Browse to your http share and copy the file's link
3. Insert it into your syncplay playlist using "Add URL(s) to bottom of playlist"
4. Attempt to play the file

Expected behavior
You copied a working link out of your browser. It should work. This is what a user would think, yes? Syncplay should work with any valid http url to a media file, and not be picky, because the user might not always be in control of what the url looks like.

Version and platform:

• OS: Debian 13
• Syncplay 1.7.4
• Media player and version: mpv v0.40.0

[Et0h]

I agree that Syncplay shouldn't unquote the URL at that stage. Your PR #803 fixes this, and I'll use #801 to make the OSD display prettier.

Looking back, that line was something I originally added to Syncplay back in 2016 as part of going through the code to add Unicode support wherever I could. Apparently I went a bit too far in this case, so thanks for helping me fix my decade-old bug.