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
Code:
--------------------
/opt/music/all/Alison_Krauss-I've_Got_That_Old_Feeling/01-I've_Got_That_Old_Feeling.mp3
--------------------
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.
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 0
--------------------
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
------------------------------------------------------------------------
pgf's Profile: http://forums.slimdevices.com/member.php?userid=58510
View this thread: http://forums.slimdevices.com/showthread.php?t=112108
_______________________________________________
Squeezecenter mailing list
Squeezecenter@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/squeezecenter
