Hi David,
* On 2007-08-18 David Baelde <[EMAIL PROTECTED]> wrote : > Hi, and welcome :) Thanks :) > 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. I'm afraid I don't have much more details than this at the moment. We retained from implementing the 'view queue' on our website because of this error for now, but if it is of any help I could do some more tests, of course. Usually I'm not afraid of debugging and fixing things myself when software has quirks, but this case is different because liquidsoap is writtin in ocaml, which is not on my list of languages I speak fluently. (which might change in the near future, however, since I started working my way through some tutorials since a few days) > 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. This is not available through the tcp socket interface, is it ? > 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. Ok, so this is working as designed. As you mention I would be better of using another command then. The 'metadatas' command produces a lot of data though, while I'm at this time only interested in the current track. But that's no problem, I just pick out what I need. > > - 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 Yes, you are right, I managed removing the line :) Actually, I figured that out 3 minutes after sending out this mail, too late :) Thanks for your answer so far, enjoy the last piece of your holidays, _Ico -- :wq ^X^Cy^K^X^C^C^C^C
