[vdr] Re: How to kill an svdrp connection from vdr ?

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Philip Lawatsch wrote:
> 
> syrius.ml@no-log.org wrote:
> > Gregoire Favre <Gregoire.Favre@freesurf.ch> writes:
> >
> >
> >>>Apparently this is the most pressing problem at the moment, so I guess
> >>>I'll drop working on buffer and tuning stability and attend to this one
> >>>first...
> >>
> >>Tremendous :-)
> >>Maybe you are just ironic and I don't understand it ;-)
> >
> >
> > hmm i'll take it like that. (ironic)
> > I don't need multiple svdrp support. If you need it, hack/write a quick
> > proxy (for sure it has to understand svdrP to do that correctly).
> > I'm pretty sure buffer and tuning optimisations are more important to
> > us.
> 
> Its not that easy. Since the svdrp protocol is not not stateless and
> imho broken you cannot just hack something together to act as a proxy.
> 
> What one should really do is switch to ids for timers, recordings and
> stuff like that, but as I understand Klaus opposes this, otherwise I'd
> have done it already.
> 
> Without that multiple svdrp connections are quite error prone.
> 
> Imagine what happens if two svdrp connections both want to delete the
> timer number 13. Most likely timer 13 + 14 will get deleted since you're
> deleting not a timer number but an index in the list of all timers which
> will change after the first delete  ....
> 
> Lots of problems ..

As I've stated in a previous post, there is a rather simple
solution to this. Every SVDRP connection will have to issue an LSTT
command before it may add, modify or delete a timer. The timer list will
have a timestamp marking when the last modification was made. If an SVDRP
connection issues a timer modification command, but the list of timers was
in some way modified after this sessions last LSTT command, it will get
an error message, saying that the timers were modified in the meantime,
and that it should do another LSTT.

Klaus