Re: [Savonet-users] Weird problems when calling a playlist of only 1 title
Hi ! Le mercredi 10 juin 2009 02:46:55, Kero a écrit : My guess is : each time this playlist is refreshed, the bug makes the refresh going a little worse. At the beginning it's not that bad, but after a few dozens (hundreds?) of refreshes, liquidsoap really starts to lose control. Your analysis was correct. While preparing another commit (a nice surprise that David suggested), I realized there was a bug in the feeding task for the queued source and also the playlist source. Basically, the feeding was not doing what we wanted it to do, resulting in the possibility to spawn an important number of parrallel refresh when the initial request was failling.. This is now hopefuly fixed by commit [6612]. Romain -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Savonet-users mailing list Savonet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/savonet-users
Re: [Savonet-users] Weird problems when calling a playlist of only 1 title
Hi About problem n°2, correct me if I'm wrong, but shouldn't liq go back to the playlist as soon as it succeeds on another file ? Because in my case, once Liquidsoap went in backup mode, it never goes back to normal. the backup sound is looped until I relaunch Liquidsoap. Apparently also, sometimes, even the backup sound stops playing, as underlined by the following custom log (liq writes all metadata to a text file) : Van Halen - Eruption is the backup sound, simple dashes are jingles : [09/06/09 17:55:22] Metallica - Master Of Puppets [09/06/09 18:03:52] Guns N' Roses - Sweet Child O' Mine [09/06/09 18:09:44] Jimi Hendrix - Little Wing [09/06/09 18:12:06] - [09/06/09 18:12:09] - [09/06/09 18:12:15] - [09/06/09 18:12:18] Van Halen - Eruption [09/06/09 18:14:00] Van Halen - Eruption [09/06/09 18:15:42] Van Halen - Eruption [09/06/09 18:17:24] Van Halen - Eruption [09/06/09 18:19:06] Van Halen - Eruption (...) [09/06/09 18:53:06] Van Halen - Eruption [09/06/09 18:54:48] Van Halen - Eruption [09/06/09 19:04:00] Van Halen - Eruption [09/06/09 19:04:02] - [09/06/09 19:06:42] Led Zeppelin - We're Gonna Groove As you can see, it never plays music again, and after 18:54, even the backup sound isnt played anymore (no metadata sent while the backup sound is 1:30 long). That's until I kill/relaunch it 10 minutes later. I guess this shouldn't happen on a simple struggle on decoding a file, except if there's no timeout in decoding. Is there any ? For problem n°1, I'll let you check it when you have time since you succeeded in reproducing it. Let me know if I can be of any help or if you want me to try anything. Thanks again for helping! On Tue, Jun 9, 2009 at 9:37 AM, David Baeldedavid.bae...@gmail.com wrote: Hi, About problem n°2: this could be because your playlist emptied, because it choked for too long on a strange file or something like that; in this case your fallback would only play jingles, but jingle playlists tend to empty quickly if played repeatedly because resolving a jingle takes the same as resolving a normal file but jingles are played (too) quickly; finally the jingles empty and you get your default file. Problem n°1 is much more of a puzzle to me. I just tried to reproduce it here by playing only a playlist of one file: $ src/liquidsoap 'out(playlist(reload=60,argv(1)))' -- ~/media/playlist.one It works well: one file is played, it lasts more than one minute so the playlist is reloaded and (at the same time) another file is played. The only possibly surprising thing is that the internal queue creates a latency of 2-3 songs before a change of the playlist takes effect. But your bug appears with this simple setup: output.dummy(mksafe(fallback([single(argv(1)),playlist(reload=20,~/media/playlist.one)]))) I have some suspicions to why this is the case but I should not talk too much before actually going into the code. I'll tell you more when I find the time to do so. -- David -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Savonet-users mailing list Savonet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/savonet-users
Re: [Savonet-users] Weird problems when calling a playlist of only 1 title
Thanks for the extra details: it does sounds more strange than I initially thought. Don't hesitate to file bug reports for your problems, it helps us to keep that in mind... -- David -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Savonet-users mailing list Savonet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/savonet-users
Re: [Savonet-users] Weird problems when calling a playlist of only 1 title
Hello, After carefully checking through my logs, I get the following feeling that might give you more hints on the full case : Problem n°1 and Problem n°2 are linked : they both appeared at the very same time. What made the problem start was a slight change in the script to give the play.m3u a much higher refresh rate (every few minutes or so instead of every few hours). As I told earlier, the problem with the one-title playlist (play.m3u) tends to go from bad to worse as time goes by (at first it's a few times, then a few dozen times, and after some hours, I'm flooded with several hundred of pages of refreshes). My guess is : each time this playlist is refreshed, the bug makes the refresh going a little worse. At the beginning it's not that bad, but after a few dozens (hundreds?) of refreshes, liquidsoap really starts to lose control. When it was refreshed like, once every 10 hours, this was not a problem : since the problem appears only after several dozens/hundreds of refreshes, it would only become noticeable after several days, perhaps even several weeks. Liquidsoap would either crash for some other reason before the problem occured, or I would even relaunch it myself because of some new script to load. But when the list is refreshed every 5 or 10 minutes, then after 24-48 hours, the bug becomes unbearable. How the two bugs are related, I don't know. I know they are because they appeared at the exact same time. The very day I launched the new script with high refresh rate, I had my first successfully loaded a playlist of 1 track flood in my logs... and my first switch to /backup.mp3 ever, a few hours later. Either the switch to /backup.mp3 is caused by that playlist refresh bug (maybe it struggles too much with loading that playlist to care anymore about normal fallback operation ?), or they are both the result of something else that they have in common. Hope this helps. On Tue, Jun 9, 2009 at 11:59 PM, David Baeldedavid.bae...@gmail.com wrote: Thanks for the extra details: it does sounds more strange than I initially thought. Don't hesitate to file bug reports for your problems, it helps us to keep that in mind... -- David -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Savonet-users mailing list Savonet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/savonet-users
Re: [Savonet-users] Weird problems when calling a playlist of only 1 title
Hello, The eat_blank operator is only used for the musique value, which relates to playlist.m3u - a playlist of +/- 100 mp3s with very little blank : this list is what's broadcasted about 20hrs/day every day. I never had a problem with eat_blank and that playlist. playlist.m3u must NOT be confused with play.m3u which is a playlist of only one file, played only on saturday evening. play.m3u is used in the metalinv value, for which no eat_blank is used. There is no eat_blank either in further mix (like after using a switch or a fallback), so it should not interfere with liquidsoap behaviors regarding the muting of different sources. As a consequence, my guess is eat_blank can not interfere with the metalinv/play.m3u/switch mess, which started all my troubles. The same goes for the crossfade operator, which is used before the switch, and does not interfere with the guilty metalinv. If you still think eat_blank could interefere with something, tell me, and I'll try without it. But for now, I'm doubtful. On Tue, Jun 9, 2009 at 1:05 AM, Romain Beauxisto...@rastageeks.org wrote: Hi ! Le Monday 08 June 2009 22:57:22 Kero, vous avez écrit : BOTH problems has appeared at the same time : when I added the one-mp3 playlist (play.m3u), and the switch to go with it. So I think they're linked in some way. I tried changing the switch logic but it didn't change anything. Thanks for the detailed description of your issue. My first guess would be to try to desactivate the eat_blank operator. Indeed, this operator consumes audio data until it finds something that is not a blank. I am not sure about its behaviour, but I guess it should be used for a source where you expect some audio data most of the time. If the source, for instance, is composed of tracks of blank data, it will pull data all the time and probably behave oddly. Could you tell us if the problem still occur without this operator ? Romain -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Savonet-users mailing list Savonet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/savonet-users
