Le Friday 21 September 2007 10:24:22 David Baelde, vous avez écrit :
> On 9/19/07, Vincent Tabard <[EMAIL PROTECTED]> wrote:
> > * with restart = false, liq doesn't try to reconnect when the connection
> > goes down. This behavior should definitely not be kept as a default,
> > above all when you consider that liq doesn't stop or anything (even if
> > no other output is defined): it just goes on with no output, sometimes
> > appearing to try to reconnect ("Shout socket error..."), never
> > successful. Worse, it eats 100 % CPU.
>
> This is odd. With restart=false liquidsoap tries to reconnect at least
> on Shout.Socket errors. I have successful reconnections on Dolebraï.
> But if the reconnection doesn't work immediately, liquidsoap should
> crash. At least, this is the intended behaviour.
>
> Concerning Romain's fix here, I'm not 100% sure but it seems
> off-topic: this behaviour is priori to the restart mode and there
> should be a way to fix it without half-using the devices created for
> the restart mode. (Also, I wonder if the reconnection won't be only
> after the restart_delay, with that fix.)Well, actually I don't like the behaviour of actual restart in this precise case. That's because when the connection drops, it's almost sure it's not gonna get ready again at next send. We better wait for the same restart_delay before attempting another try. Also, this handling does not close actual connection by itself, so there's a chance that next sending will be attempted -- Ok I don't know well the way output_stop <- true is handled. In case the send is attempted then this may explain the "stuck-with-100%-cpu" behaviour to my understanding.. Anyway, as we have seen with vorbis headers, the restart is a tricky thing that might be reworked short after the release. That's why I would prefer to unify both way to handle restart, which is what this patch is doing.. I'm even almost sure the restart we worked out for vorbis will not work in this restart case. Romain
