Hi David, thank you for your work. Meanwhile I have the feeling, the problem ist quite easy.
I must make these copies, for not to have too many tracks at the same time. The reason for this is, that the GVL (a copyright collecting agency here in germany) calculates there fee after the available tracks at a time. And this is a legitimate way to avoid too high costs. I think I have found the reason: LIQ simply doesn't restart when it is told to do so. I do think so, because the log doesn't have any entry about restarting, when it should have neither at 4:00 nor at 6:05). But when I restart manually it does: 2010/04/19 06:36:17 >>> LOG END 2010/04/19 06:36:22 >>> LOG START I should have seen that earlier :( So I changed my script to: ------------------------------------------- #!/bin/bash sudo /etc/init.d/liquidsoap stop #Skript, um alle 24 Std die Statistik umzubenennen und die Titel umzukopieren /home/musik/stat_umbenennen /home/musik/autocopy sudo /etc/init.d/liquidsoap start -------------------------------------------- I hope, that helps. Yes, I am using Ubuntu. If it does not, what else can I do? Regards Christian David Baelde schrieb: > Hi, > > I think I understood your problem. > > (1) The playlists don't reload as soon as you expect. The > one-reload-per-round means that liquidsoap won't reload before it > plays the last file of the round, which involves playing at least one > file. > > (2) I looked up the source code, the message "unresolved request" > should be harsher, it's a bad sign: it means a request had been > prepared, ready and all, but suddenly it's not ready anymore. > > This is because you manage your playlists by copying stuff to one > directory. To prepare the next playlist you delete the directory and > create new copies. At this point liquidsoap still has in mind the old > filenames, thinks they're ready to be played, and gets a bad surprise. > If you reload it loads the new directory content. > > I'd advise not to use this technique. Can you simply create a file > containing all filenames? This wouldn't cause the "unresolved request" > because liquidsoap would have "in mind" the real filenames, not the > copied locations. > > You'll probably still be unhappy with problem #1: you can avoid it by > forcing a reload manually using the server command > "<playlist_id>.reload". Then you'll notice that there's still an "old" > playlist item in the prepared request queue (cf problem #2) and for > that I've no good solution for now -- except not using playlists... > > Cheers, > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
