Re: [vdrpylib-devel] Some of my code modifications

[Rob S. <ro...@in...>]

Sebastien Lucas wrote:
> I ran out of time yesterday to check everything.

No prob, we all need more hours in the day for hacking. :)


> Channels.py :
> I've also added a check un addevent to prevent events already finished
> to be added (I don't remember why I added that).

It might be a good failsafe.  I can't remember how long VDR keeps EPG 
data around for.


> The most important change was to remove the indexes list as I never
> understood what it was for !! I replaced it by a unique index
> representing the real channel number in VDR.
> Maybe you can enlight me here.

Actually I was thinking of removing those indexes because I can't see a 
good use for them.  Maybe there was a quirk in VDR 1.1.x that this took 
care of.  At least my copy of VDR doesn't keep duplicate channels, 
instead it will modify an existing one if it's there.


> Svdrp.py :
> I kept the original TelnetLib method.

A coleague of mine has a non-blocking implimentation of SVDRP controll 
in python.  I may take a look at that for improvements too.


> But to prevent some errors (the same you had with EPG) I modified
> especially read_reply to wait (sleep) between each read_very_eager.
> I attached svdrp.py, it's not my latest one (too crappy to be shown)
> but it shows my modifications.

Funny thing... when I started to work on svdrp.py I had similar problems 
and solved them by adding time.sleep() calls in various places, see this 
diff, there's lots of them commented out:

http://cvs.sourceforge.net/viewcvs.py/vdrpylib/vdrpylib/vdr/svdrp.py?r1=1.4&r2=1.5

However, I think the important thing was actually _removing_ a sleep 
that was there before, in read_reply().

Maybe you can try the CVS version and see if your problem is gone, 
lessened, the same, or worse (I hope not!).  Beware there is also now a 
close_connection parameter that will use a new svdrp connection for 
every command if set... this will slow down consecutive commands but 
makes things more stable.


> I've also modified lstc  but I had no more time yesterday to check it.

Ok, I'll take a look.


> Other explained changes will come (probably this weekend).

Great.


> WARNING : It was my first try writing python code so don't be too
> pedantic about my code ;).

No prob, glad you can contribute. :)

-Rob