Bugzilla – Bug 2753
For certain queries, CLI returns invalid answer half of the time (every other response is nonsense)
Last modified: 2008-09-15 14:37:04 UTC
I have 2 squeezeboxen: 00%3A04%3A20%3A05%3A18%3A72 is the name of one of them. I send 00%3A04%3A20%3A05%3A18%3A72 mixer volume ? 4 times and get these results: 00%3A04%3A20%3A05%3A18%3A72 mixer volume 50 192.168.1.105 mixer volume %3F 00%3A04%3A20%3A05%3A18%3A72 mixer volume 50 192.168.1.105 mixer volume %3F In other words, it only works properly every other time. Just to ensure that other things are working: I send player count ? and get back player count 2 I send player id 0 ? and get back player id 0 00%3A04%3A20%3A06%3A16%3A17 I send player id 1 ? and get back player id 1 00%3A04%3A20%3A05%3A18%3A72
So as to make the output a little clearer, I named one of the squeezeboxen SB1, the other SB3. So now I issued the command SB1 mixer volume ? a number of times and got back: SB1 mixer volume %3F 00%3A04%3A20%3A05%3A18%3A72 mixer volume 50 SB1 mixer volume %3F 00%3A04%3A20%3A05%3A18%3A72 mixer volume 50 SB1 mixer volume %3F 00%3A04%3A20%3A05%3A18%3A72 mixer volume 50 SB1 mixer volume %3F 00%3A04%3A20%3A05%3A18%3A72 mixer volume 50 It seems to me that both responses are wrong. 00%3A04%3A20%3A05%3A18%3A72 is 00:04:20:05:18:72 which is my MAC address, (I checked the bottom of the box - it is my mac address) but I don't believe from the CLI docs that it should be doing that translation in my reponse. It should be echoing what I sent it. SB1 mixer volume %3F (which I think is the question mark) gives me my question mark back rather than an answer.
I committed a fix in 5448 (6.2.x branch). Please check (next nightly) if the problem is still there. I can't reproduce the bug using an ID, but I can using a name. This patch fixes it, but it is more of a workaround to a strange Perl bug? Re. the wrong responses to "SB1 mixer volume ?", the ones with a MAC ID are correct. The CLI is quite lenient with what it accepts as client identifier, but it tranforms it into the "native" one, i.e. the MAC ID. In the other case when %3F is returned, %3F is ? url-escaped. It means the query was not understood as one (for whatever reason, there is currently no provision in the CLI protocol to reply with an error code). In this particular case, it is because "SB1" is not recognized as a client ID and therefore the CLI thinks the command (a) has no client and (b) is "SB1", which of course is not a valid command.
(In reply to comment #2) > I committed a fix in 5448 (6.2.x branch). Seems to be fixed. Thanks. > I can't reproduce the bug using an ID, but I can using a name. Exactly. It worked correctly using a mac address, but failed half the time when using the name. Do I mark it resolved? Or is that someone else's responsibility?
If you are the reporter on a bug, you may close it off at any point when you are satisfied that the issue is resolved. Developers may mark it off when an expected fix is merged in. I'll mark as resolved now, since it seems to be the case :)
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.