Hi -- I tried searching for posts related to this, but came up empty.
If i ask the server to play a track whose name contains an ascii(duplicated, for some reason) apostrophe, the notifications I get from the "listen" command aren't consistent in their percent-encodings and are in some cases double-encoded.
Here's an example. The track I'm playing is
There are two apostrophe characters, in the two instances of "I've".
I use the "playlist play" command, directed at the squeezelite player named "den". The pathname is fully percent-encoded, so the apostrophes are now %27.
The server sends back two (well, three, actually -- the second is duplicated for some reason) notifications -- one for the "playlist play" command, and the other one for "open file".
The "playlist play" notification contains raw apostrophes. That may well be legal, but it's a little surprising. Shouldn't they be encoded?
The "open file" notification goes to the other extreme, and returns the apostrophes as %2527, which is an encoded version of %27, which is itself an encoded apostrophe. In other words, the string in the "open file" notification that was encoded for reply already contained encoded apostrophe characters.
I have a monitoring script that watches the server notifications, and uses them to keep a record of which tracks were most recently played. It depends on being able to parse the pathname from the "open file" notification. My workaround is obviously to decode the path, and then, if the path still contains the pattern "%[0-9A-F][0-9A-F]", decode it again. This is unlikely to fail, but it would, of course, if I had a track with "%AB" (or other digits) in the name.
I used to be on the developer list, but haven't been for some time. I could ask about this there, but perhaps someone here will have an insight into this -- I think it's pretty clearly a bug. (I'm running what I think is the latest release: "Logitech Media Server Version: 7.9.2 - 1578996832 @ Tue Jan 14 12:17:56 CET 2020")
paul
If i ask the server to play a track whose name contains an ascii(duplicated, for some reason) apostrophe, the notifications I get from the "listen" command aren't consistent in their percent-encodings and are in some cases double-encoded.
Here's an example. The track I'm playing is
Code:
/opt/music/all/Alison_Krauss-I've_Got_That_Old_Feeling/01-I've_Got_That_Old_Feeling.mp3I use the "playlist play" command, directed at the squeezelite player named "den". The pathname is fully percent-encoded, so the apostrophes are now %27.
The server sends back two (well, three, actually -- the second is duplicated for some reason) notifications -- one for the "playlist play" command, and the other one for "open file".
The "playlist play" notification contains raw apostrophes. That may well be legal, but it's a little surprising. Shouldn't they be encoded?
The "open file" notification goes to the other extreme, and returns the apostrophes as %2527, which is an encoded version of %27, which is itself an encoded apostrophe. In other words, the string in the "open file" notification that was encoded for reply already contained encoded apostrophe characters.
Code:
$ telnet slimserver 9090
Trying 192.168.111.4...
Connected to slimserver
listen 1
listen 1
den playlist play %2Fopt%2Fmusic%2Fall%2FAlison_Krauss-I%27ve_Got_That_Old_Feeling%2F01-I%27ve_Got_That_Old_Feeling.mp3
00%3A00%3A00%3A00%3A00%3A27 playlist play %2Fopt%2Fmusic%2Fall%2FAlison_Krauss-I've_Got_That_Old_Feeling%2F01-I've_Got_That_Old_Feeling.mp3
00%3A00%3A00%3A00%3A00%3A27 playlist jump 0 0
00%3A00%3A00%3A00%3A00%3A27 playlist open file%3A%2F%2F%2Fopt%2Fmusic%2Fall%2FAlison_Krauss-I%2527ve_Got_That_Old_Feeling%2F01-I%2527ve_Got_That_Old_Feeling.mp3
00%3A00%3A00%3A00%3A00%3A27 playlist open file%3A%2F%2F%2Fopt%2Fmusic%2Fall%2FAlison_Krauss-I%2527ve_Got_That_Old_Feeling%2F01-I%2527ve_Got_That_Old_Feeling.mp3
00%3A00%3A00%3A00%3A00%3A27 playlist load_done
00%3A00%3A00%3A00%3A00%3A27 prefset server currentSong 0
00%3A00%3A00%3A00%3A00%3A27 playlist newsong I've%20Got%20That%20Old%20Feeling 0I used to be on the developer list, but haven't been for some time. I could ask about this there, but perhaps someone here will have an insight into this -- I think it's pretty clearly a bug. (I'm running what I think is the latest release: "Logitech Media Server Version: 7.9.2 - 1578996832 @ Tue Jan 14 12:17:56 CET 2020")
paul