Bugzilla – Bug 1477
Audio stops if quoted display command entered via telnet
Last modified: 2009-01-28 10:20:44 UTC
When telnetting to the slimserver to test out the CLI interface, I found that, if you enter the command display "Hello World" you can stop the audio. I don't know what the correct syntax would be/should be for entering more than one word on the top line of the display, but I shouldn't be able to freeze playback by guessing and getting it wrong. Slimserver running on WIN98SE, telnetting from Windows 2K using the built-in Microsoft telnet agent. I've rated the severity minor because I know the CLI interface isn't really intended for interactive use and I'm guessing at the syntax for multi-word display, but this hints at a bigger underlying problem, that I could stop playback at all with a syntax error on this interface. Michael
sorry, forgot: Player Firmware Version: 40
Michael, there really arent the resources to go back to debugging on 5.4.0. Please try the recent 6.0.2 release for any new testing, or design work. if you still have problems with that, we can reassign this to Fred to handle as part of his CLI work.
Fred, any comments on this?
Tested now in 6.0.2 The example given in the CLI docs, specifically display Hello World 5 if you wait after typing the "5" stops the song currently playing. It also does not display Hello World for 5 seconds, which is what, from the documentation, I expected. The display flashes something, too fast for me to see what, and returns to what it was showing before.
the display duration bug is a known one and should be fixed in the latest nightlies (at least 6.1 nightlies)
For the duration problem, it was working last week with 6.1 but maybe something changed since then. For the other problem, it is strange as <socket> should not return any data on the program until return is hit on the keyboard, so it is strange than SOMETHING happens if you don't type anything after 5... Could this be a "feature" of the Perl used in Win98? What is the OS of your client and server, what is the terminal program you are using, and could you try it all again with d_cli and d_command on ? That could help a lot.
Server is running 6.0.2 on a windows 98 SE host. Client telnet is the one built into windows 2000. There are several things going wrong here, because as I understand it, telnet clients are supposed to buffer their input and aren't supposed to send anything until the final CR, but this one clearly is. Also, telnet hosts aren't supposed to act on what's sent until the CR, but clearly slimserver is. So it's all bizarre. As for 6.1 fixing the display duration, I don't know. I used the packaged 6.0.2. I need to fall back because I have to DJ tonight and I don't have time to learn how to use the nightlies and no time to get enough time under my wheels to assure myself it's stable. I will submit that as a separate bug report, since it doesn't really belong here.
For display, yes check for an existing bug or create a new one For the other problem, please test with d_cli and d_command on whenever you get the chance. The nightlies are just complete version of SlimServer built every night. Nothing to learn really, just download and install (at least on Mac OS X). And I'd be interrested in knowing how you use SlimServer/CLI/display in your DJ context ! Good luck for tonight.
Fred: is there more to do here for 6.1?
Not until we get more data from Michael. I just can't reproduce that behaviour.
I'm sorry - work has been nuts recently and I come home exhausted every night. I will try to reproduce shortly, on the weekend if all else fails. Michael
I ran this test tonight. Version was 6.1.0 trunk locale cp1252. I started it with the following bat file: perl slimserver.pl --logfile log.txt --d_cli --d_command Here is the output of the log file 2005-06-21 21:41:25.3200 Server slimserver.pl accepting command line interface connections on port 9090 2005-06-21 21:41:33.2450 Executing command 00:04:20:05:7b:d2: playlist (add) (E:\shared\My Music\__00_04_20_05_7b_d2.m3u) () () () () () 2005-06-21 21:41:33.7800 Returning array: playlist (add) (E:\shared\My Music\__00_04_20_05_7b_d2.m3u) () () () () () 2005-06-21 21:41:37.5700 Executing command 00:04:20:05:7b:d2: play () () () () () () () 2005-06-21 21:41:38.0118 Returning array: play () () () () () () () 2005-06-21 21:41:46.1839 Accepted connection 1 from 192.168.1.100 2005-06-21 21:42:01.5700 Clients: 192.168.1.104:33614 2005-06-21 21:42:01.5705 Processing command: display hello world 50 2005-06-21 21:42:01.5718 Executing command 00:04:20:05:7b:d2: display (hello) (world) (50) () () () () 2005-06-21 21:42:01.5754 Returning array: display (hello) (world) (50) () () () () 2005-06-21 21:42:01.5760 Command line interface response: display hello world 50 2005-06-21 21:42:01.5768 Ready to accept a new command line interface connection. 2005-06-21 21:42:01.5944 Sending response 2005-06-21 21:42:01.5951 No more messages to send to 192.168.1.100 2005-06-21 21:42:30.5860 Executing command 00:04:20:05:7b:d2: stop () () () () () () () 2005-06-21 21:42:30.6491 Returning array: stop () () () () () () () 2005-06-21 21:42:33.8894 Executing command 00:04:20:05:7b:d2: power (0) () () () () () () 2005-06-21 21:42:34.1303 Returning array: power (0) () () () () () () 2005-06-21 21:42:40.4015 Client at disconnected 2005-06-21 21:42:40.4020 Closing connection 2005-06-21 21:42:40.4037 Ready to accept a new command line interface connection. Terminating on signal SIGINT(2) I hope this means more to you than it does to me. It still froze the music. But the display duration bug is fixed. :-)
What did you type from the CLI: display hello world 50? And what is the effect that is wrong? Sorry I am a bit confused. The log seems OK. The player is stopped and powered off but that may be you from the web or did it happen on its own? Is the problem still there with the CLI accepting commands before you type return? Did this happen in the log you sent ?
As I said in additional comment 4, if you wait after typing the "5", the song currently playing stops. That is, if you type display hello world 5 and then wait a while before hitting the carriage return, the music stops. Yes, this happened in this example. Yes, I afterwards stopped and turned off the player. I was trying to find a way of making a clear sign in the log that the test was finished.
Created attachment 572 [details] log with slimproto and protocol also turned on I produced this log by starting the server with d_cli and d_command, starting the music, then turning on d_protocol and d_slimproto, then finally starting to type at the telnet interface. You can see that the buffer runs out of stored music while I'm typing at the telnet interface. I hope this helps.
Fred, can you move this forward (Target Milestone to 6.2 or Future) if you don't think it's likely you'll have a fix within the next 2 weeks?
OK, had a look to it. It is a socket problem of some sort, and the CLI only uses the stuff in Networking::Select. So does Slimproto and voila the bug. Michael, can you try it again but add d_socket? It looks like the command goes through and is processed normally by the cli and then added to the socket for writing. Then nothing happens for a while and this is where the client buffer empties. At some point the response is finally sent and then the client is happy again. I think that during the wait, slimserver is sending NOTHING out (stuff gets in though, we get the slimproto status frames from the player). Maybe whoever wrote Networking::Select should have a look at it. I can kind of reproduce it by sending something to the CLI without $LF at the end: everything stops. It looks like slimserver is actively waiting for the $LF to arrive... Not sure how to correct it, though...
I seem to recall another bug report that would leave the server waiting for \n. I can't find the bug at the moment, however.
Bug 630? Can this be due to the fact the CLI uses <$sock> ?
SVN 3601
This bug was marked resolved in Slimserver 6.1, which is several versions ago. If you're still seeing this bug, please re-open it. Thanks!