Hi, and welcome :) On 8/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > - The first problem is that sometimes - not sure when and why - the > telnet interface locks up after issuing the '.next' command on a > queue. Instead of returning the next songs to be played, an error > message is returned : > [...] > If this command is sent once more, no reply is received from > liquidsoap - not even an END message - and the telnet interface does > no longer respond. Reconnecting also does not seem to fix this.
I believe you as you precisely described a bug that I also experienced. Shame on me, I didn't write that down anywhere and just restarted the radio, I don't even remember if it was radiopi or geekradio. In any case, I need to eventually study the problem. I'm glad you report it, because you probably experienced it on a simpler conf than me: please keep all possible information (and don't hesitate to send me tons of details) and be patient. Also, you probably won't experience the same problems with request.equeue(), so that might be a good experiment to try, and even a decent workaround. In any case, an operator-level failure shouldn't affect the whole telnet server. > - The second issue has to do with the on_air command. We are using a > default playlist, which is overruled by the queue if anything is > requested. The on_air commmand results two numbers when the playlist > is interrupted in favour of the request. Often the first number is the > track currently playing (the request), but *sometimes* it seems that > both numbers are reverted. Is there order of numbers replied from the > on_air command defined ? Indeed, on_air lists in no particular order the IDs of the requests which are currently being played. Paused requests are also listed as you noticed. So this is an intended behavior. I'm sure you're trying to do something which is not conveniently done with on_air, and you should look for another solution. Maybe the outputs' "metadatas" commands, or metadata stores ? Give me more details if you're stuck, I'll be happy to help. > - The third issue is more of a question. Whenever a request is filed, > the queue kicks in and interrupts the currently playing track from > the playlist. Is there a way to let the current track finish before > switching to the request queue ? What you want is the default (track sensitive) behavior of switch operators (in particular fallback() which you're probably using). It seems that you've overridden the mode to track insensitive. I bet you can remove that "track_sensitive=false" that you pasted :p > Thank you for your time, Again, you're welcome. Don't hesitate to give feedback, ask questions and raise discussions, that'd be a nice retribution. However, I believe the community (lists and IRC) will be quite sleepy until September. See you then and have fun. -- David
