URL encoded path make tracks unplayable
alexpado opened this issue · comments
Hi,
Just noticed this issue, if the path contains spaces, VLC will encode them to %20 which will cause the music to be unplayable.
Manually editing the file replacing %20 back to spaces works.
For reference, when %20 are present, this is what I get in the logs:
INFO: Searching path by EventID 991472
INFO: Found and set file scripts\XNFSMusicPlayer\musics/need-for-speed-underground-2/SpiderBait%20-%20Black%20Betty.ogg to 991472
INFO: Type: OGG stream
ERROR: Error creating stream handle for file: scripts\XNFSMusicPlayer\musics/need-for-speed-underground-2/SpiderBait%20-%20Black%20Betty.ogg | BASS Error: 2
ERROR: Can't set volume attribute (handle: music): BASS Error: 5
Altough this is an easy fix with any editor using search & replace, this is still a pretty annoying thing to do.
Is there any way to fix this ?
EDIT:
This seems to affect every characters being URL encoded. Just had the issue with ( and ) with are encoded %28 and %29 respectively.
Maybe this bit of code could help you ?
I'll consider it. Currently everything in this player is very custom and very jank.
It reads the file line by line with the fgets function, so if it's filled with the URL tokens it is going to be a problem, yes.
I could consider adding escape characters for these or maybe just redo everything related to this and do it better.
The biggest limitation is BASS not supporting unicode chars (I think), so paths have to be ANSI.
The BASS_StreamCreateFile seems to have a BASS_UNICODE flag to it.
From the doc page:
BASS_UNICODE - file is in UTF-16 form. Otherwise it is ANSI on Windows and UTF-8 on other platforms.
I don't know how UTF-16 would work on windows though
Edit: But this is getting away of the original problem here where %<code> could just be swapped to their unencoded equivalent. For this I don't think unicode support is the main issue
Oh cool, so it supports it.
I thought of it only because I remember this being one of the problems I need to resolve and it'll affect the parser.
But for this particular instance, no, it won't really change much.