Bugzilla – Bug 4543
Giving commands to absent players plays on another player, rather than being ignored or erroring
Last modified: 2007-04-05 16:29:10 UTC
Commands given to a player which is not available (eg because it is turned off) will instead be directed to another player. This is highly frustrating when you want to isolate the players. Requirements and steps to reproduce: 1. You need a slimserver running (I have used 6.2 versions which have this problem, but am now using the svn trunk 7.0 version, so I've filed the version as 'unspecified' because I believe it covers quite a few). 2. A SqueezeBox or SoftSqueeze running. 3. A way of requesting a queued item, eg wget under linux. 4. Issue a command for a player which does not exist, for example: wget -q -O http://buttercup:9000 status.txt\?player=192.168.0.55\&p0=playlist\&p1=loadalbum\&p2=\*\&p3=Beth+Orton\&p4=Central+Reservation where 192.168.0.55 is not a registered player. 5. This command will be processed as if it were sent to the running squeezebox, even though it was explicitly directed at another. This sort of sequence appears to fail in the same way if a MAC address is given, rather than an IP. Why is this a problem ? For me, I use the server as an alarm clock. The above command line, or something like it, is issued on the server (a linux machine named buttercup in the above example) in the morning to wake me up. A few minutes before this, the Windows system (a different machine - the one running on 192.168.0.55) is woken up and runs SoftSqueeze, so that when the alarm goes off it is ready to play music. However, sometimes the Windows system won't start. Either because the house power has gone off (Windows isn't on a UPS, but the linux server is) or, as happened this morning, because Windows failed to un-hibernate. The result of this is that instead of being ignored, the operation is routed to the hardware SqueezeBox in the living room. Which is on a proper amp. Which is set to be quite loud. Fortunately this still wakes me up. Unfortunately it's probably waking people next door as well. Now, I can't control Windows failing to start, and I don't see that I should have to as the problem lies with the operations being misrouted by the server. Why might this be a problem for other people ? Let's say that we use multiple squeezeboxes in a real environment - say one in the main bar of a pub and one in private bars or conference rooms. Let's say that you want to play something particular in the conference room, but someone's unplugged it so that they can plug their projector in earlier in the day and forgotten to plug the player back in. Now you issue your command to the conference room and suddenly the music starts playing in the main bar. That doesn't sound all that professional, does it ? :-) What do I think is happening ? Without looking at the code, I would guess that a lookup is being performed on the player identifier given, with a fallback of the 'last player given a command', maybe something like this ... $player_to_operate_on = $player{$identifier} || $last_player; $last_player = $player_to_operate_on; If this is the case then it should be changed to only perform this defaulting action if the identifier (IP or MAC address) is not supplied. If the identifier is supplied and the player isn't present then an error should be reported or the system should ignore the command. Or possibly queue it for when/if the player returns. I've marked the problem as major because of the fact that playback (or other operations) may occur in the wrong location and is actually a problem, rather than being a nuisance. I'm not sure if that's right, but that's my view.
use of status.txt is deprecated. you should consider using the CLI which is well documented and shouldn't have this problem (which is derived from wanting to use the last chosen player when accessing the web interface).
Using the CLI is less ideal because it then means that I have to write code to make things work, rather than just a shell script as status.txt provides. I don't see anywhere in the documentation that status.txt (or status.html or any of the other suffix commands) is marked as deprecated. Indeed the documentation cites examples using status.txt for the web interface. Should I file a bug that the documentation needs updating to deprecates status.txt and friends ?
From Slim/Web/HTTP.pm } elsif ($path =~ /status\.txt/) { # if the HTTP client has asked for a text file, then always return the text on the display $contentType = "text/plain"; $response->header("Refresh" => "30; url=$path"); $response->header("Content-Type" => "text/plain; charset=utf-8"); # This code is deprecated. Jonas Salling is the only user # anymore, and we're trying to move him to use the CLI. buildStatusHeaders($client, $response, $p); The CLI was created to give outside programs as much control as possible while allowing the web server to properly serve the needs of the web interface. there are ways to issue single cli commands with one line program calls. nc is a common suggestion.
(In reply to comment #3) > From Slim/Web/HTTP.pm [snip] > # This code is deprecated. Jonas Salling is the only user > # anymore, and we're trying to move him to use the CLI. > buildStatusHeaders($client, $response, $p); > > The CLI was created to give outside programs as much control as possible while > allowing the web server to properly serve the needs of the web interface. Well that's great but it's always useful to tell people that the interfaces they're using are going away. > there are ways to issue single cli commands with one line program calls. > > nc is a common suggestion. It's certainly not as easy as using wget. In any case, since your response to the bug is that the behaviour shouldn't be expected as the interface is deprecated, and the fault occurs with all the web interface commands, I conclude that the web interface is deprecated. I'll create a bug to update the documentation to reflect this.
Ross, could you reproduce this (perhaps using Justin's example of the alarm) and make sure it's as severe as it sounds? Please use 7.0 to reproduce.
Is there some documentation about how to use status.txt and wget? As far as I can tell the CLI would be the way to do this right? I'm not able to reproduce this using the CLI, but I realize thats not what Justin is reporting. Can someone offer me a hand and point me to where I can read how to use status.txt to send commands to the player/db?
Help->technical information->Slimserver Web Interface. basically, it's the command-line interface using parameters p0, p1, p2, etc through p6. It's legacy stuff, and not actively maintained as far as parity with the CLI.
Thank you KDF for pointing me to the documentation. I appreciate you taking the time to help me with this bug. I'm having a hell of a time trying to reproduce this. When I try wget http requests I always get HTTP request sent, awaiting response... I've managed to send commands from HTTP (via browser) as well as CLI commands via CLI, via both means I can send commands to a player that has since had its power cut, and the command doesn't go to the other player I have connected to the server, it is ignored without an error message. Theres a good chance I'm not doing something right, does this look like the proper way to use wget & http commands with SlimServer? wget http://localhost:9000/status.txt?p0=playlistp1&=play&p2=file:///music/1.mp3&player=10.0.3.145 (tried this with and without the cauth parameter)
I believe you're missing out the shell escapes for the system you're on; that's why it's not responding in the way that you expect. If you're using bash under linux, the & means that the command should be backgrounded. To include a literal ampersand you need to escape it with a \ character. The request would be : wget http://localhost:9000/status.txt?p0=playlistp1\&=play\&p2=file:///music/1.mp3\&player=10.0.3.145 I'm not sure that that's the right way to specify a playlist OTTOMH, but I think it's the &s that are giving you a problem there. HOWEVER, if you look at your message you'll also see that your & and p1 are in the wrong place. You've got "...p0=playlistp1&=...". Notice that the p1 and & have been transposed. You want "...p0=playlist&p1=..." (but if using it under a shell you also need to escape the & with a \. Thus, in this case you'd want something like : wget http://localhost:9000/status.txt?p0=playlist\&p1=play\&p2=file:///music/1.mp3\&player=10.0.3.145 Personally I'd be tempted to raise the hang as a separate bug - you've effectively requested "http://localhost:9000/status.txt?p0=playlistp1" and the connection has hung. Hope that helps.
Justin thank you very much, I appreciate the knowledge! With your help I'm easily able to get status.txt CLI functionality via wget in bash. However, I'm still not able to reproduce the bug you're describing. I connect 2 players to the server, verify that both can receive commands via wget, then disconnect the power to one and send commands to it, the other player never does anything. Am I missing something else here? Has anyone else noticed anything like this?
Justin, if it's alright with you I'd like to mark this bug as worksforme. If you see it again please feel free to re-open this bug with more details.