vdrpylib-devel — Discussion about vdrpylib

Re: [vdrpylib-devel] pending patches?

[Sebastien L. <seb...@gm...>]

On Thu, 06 Jan 2005 12:48:40 -0400, Rob Shortt <ro...@in...> wrote:
> Dominic Morris wrote:
> > On Thu, 6 Jan 2005, Rob Shortt wrote:
> >
> >
> >>Hi, welcome to the list.  Sorry for the late reply.
> >
> > 
> > No worries, I'm still on hols, so I've got time on my hands to hack, if
> > only I could decide on one thing to do at a time!
> 
> LOL, I have the same problem.

Same problem here ;)
 
> >>There is a patch from Vlad here which contains some changes which I may
> >>include.  I haven't gone through it all yet because on my vacation
> >>(which just ended) I decided to goof off instead of hack.  What issues
> >>are you having?
> >
> > 
> > I can't read the EPG in - I'm using DVB-T and the channel ids don't match
> > up with what the code expects! Timers are also unreadable, probably due to
> > the same issue, rather than digging in and re-solving it I thought I'd ask
> > to see if someone else already has.
> 
> Ok, I don't think this lib has ever been developed or tested with DVB-T
> and I was afraid this would be a problem.  Can you followup with a few
> examples of the DVB-T channel ids?  I will also look at the man page for
> them.  Do you know of any other differences between DVB S/C/T as far as
> the VDR config is concerned?  I will update the code for this asap.

My patch should fix this (the channel ID was badly build in some
cases). I had the same isssue (problem reading EPG) with my DVB-S. My
fixed vdrpylib at least works with DVB-S and DVB-C here in France.
Maybe DVB-T is different but I don't think so.

> >>It sounds like you should build a server process which is the single
> >>point of communication to VDR.  In my other project, Freevo
> >>(http://freevo.sf.net), we are working on an EPG library (pyepg) which
> >>can use vdrpylib to fill its database.  You may be interested in that
> >>sort of thing.  I have also been working on a client-server
> >>implimentation of pyepg but that part is specific to Freevo so far.
> >
> > 
> > I always like the idea of leveraging 3rd party code, it seems the
> > client-server implementation might be the most appropriate idea for my
> > project (vdr-mediamvp) whereby the database resides in one process and the
> > rest of the server in another. I suppose the obvious question regarding
> > that is why couldn't the database be just another vdr module to avoid
> > holding two sets of the same data (apart from having to write the code
> > myself of course!)
> 
> I've read up on vdr-mediamvp a few times as I would like to get an MVP
> myself - cool project.  BTW how much python does it use?
> 
> I can see how in this case you wouldn't want to have redundant sets of
> data.  If you think about it though, reading the whole EPG with each MVP
> client is kinda doing the same thing.  How much memory does the MVP
> have, 30-40 megs to keep the EPG around on each client does seem like a lot.
> 
> Perhaps by only reading small parts of the EPG as you need it would work
> better, not that vdrpylib supports that atm.  You could also acheive
> this by writing vdrpylib-aware code on the server side with a custom
> client-server interface for vdr-mediamvp (with or without pyepg) to
> request EPG data in small chunks.  Either way you'll have a redundant
> pool of data but its best to have only two, both on the server, I think.
> 
> Maybe Vlad (Sebastien Lucas) can add his 2 cents, I think he's doing
> something similar for the xbox (XBMC?).

Yes I work with XBMC. 
The script is currently only alpha so not really tested by a lot of
users (only 2 or 3 guys from a french forum).
For the EPG, I only read EPG when needed and only what is needed. I
also have a thread running each 10 minutes wich remove old EPG events
(it was mainly for the fun, it was my first with thread and python).
With that I never had any problem with EPG even if the Xbox has only
64Mo of memory. Once again the has only been tested by 3 guys.

Hope I'll got more time this year (that's my new Year wish :D).

Re: [vdrpylib-devel] pending patches?

[Dominic M. <do...@su...>]

On Thu, 6 Jan 2005, Rob Shortt wrote:

> Ok, I don't think this lib has ever been developed or tested with DVB-T 
> and I was afraid this would be a problem.  Can you followup with a few 
> examples of the DVB-T channel ids?  I will also look at the man page for 
> them.  Do you know of any other differences between DVB S/C/T as far as 
> the VDR config is concerned?  I will update the code for this asap.

Sure, here's the entries from epg.data:

C T-9018-4100-4351 BBC THREE;BBC
C T-9018-20480-22272 UKTV History;UKTV
C C-0-109-62007 UKTV Gold
C C-0-111-62009 UKTV G2

[there's some analog TV ones in there as well just to be comprehensive,
they're mapped through as Cable channels], the corresponding channels.conf
entries are:

BBC THREE;BBC:505833330:I0C34D34M16B8T2G32Y0:T:27500:0:0:0:0:4351:9018:4100:0
UKTV History;UKTV:578166670:I0C34D34M16B8T2G32Y0:T:27500:401:402=eng,404=eng:0:0:22272:9018:20480:0
UKTV Gold:109:C0:C:0:100:101:0:A0:62007:0:0:0
UKTV G2:111:C0:C:0:100:101:0:A0:62009:0:0:0

The following bit of code generates the correct id for use with streamdev
from data in channels.conf (sid is the appropriate channel id):

def channel_parse(string,num):
    tokens = string.strip().split(':')
    namtoks = tokens[0].strip().split(';')
    name = namtoks[0]
    freq = int(tokens[1])
    source = tokens[3]
    vpid = tokens[5]
    apids = tokens[6]
    ca = tokens[8]
    id = int(tokens[9])
    nid = int(tokens[10])
    tid = int(tokens[11])
    radio = 0
    if vpid == '0' or vpid == '1':
        radio = 1
        if apids == '0':
            radio = 2
    if source == 'T':
        freq = freq / 1000
    if nid == 0:
        m = map(str,[source, nid, freq, id])
        sid = '-'.join(m)
    else:
        m = map(str,[source, nid, tid, id ])
        sid = '-'.join(m)
    return ( num, name, sid, ca,radio)


> I've read up on vdr-mediamvp a few times as I would like to get an MVP 
> myself - cool project.  BTW how much python does it use?

Python is used to generate the ui and handle the user interaction. Each 
connected MVP causes a new interpreter to be spawned in an individual 
thread. The main thread consists of an event driven C library handling the
network connections. All that's running on the MVP is a dumb client 
displaying a pushed screen and pushed media stream.

The MVP has only got 16MB of memory so I'd like to keep most of that for 
buffering the streams rather than using it up generating the ui etc.

> Perhaps by only reading small parts of the EPG as you need it would work 
> better, not that vdrpylib supports that atm.  You could also acheive 
> this by writing vdrpylib-aware code on the server side with a custom 
> client-server interface for vdr-mediamvp (with or without pyepg) to 
> request EPG data in small chunks.  Either way you'll have a redundant 
> pool of data but its best to have only two, both on the server, I think.

That's where my original question comes from, there's no chance of sending 
the raw epg data to the MVP, but keeping a separate copy for each thread 
seems a little ott as well. I'm favouring the querying a database 
approach, I just need to do a bit of investigation into a pyepg based 
solution.

> Maybe Vlad (Sebastien Lucas) can add his 2 cents, I think he's doing 
> something similar for the xbox (XBMC?).

That would be good to hear how someone else is tackling the problem.

cheers,

d.

Re: [vdrpylib-devel] pending patches?

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

Dominic Morris wrote:
> On Thu, 6 Jan 2005, Rob Shortt wrote:
> 
> 
>>Hi, welcome to the list.  Sorry for the late reply.
> 
> 
> No worries, I'm still on hols, so I've got time on my hands to hack, if 
> only I could decide on one thing to do at a time!

LOL, I have the same problem.


>>There is a patch from Vlad here which contains some changes which I may 
>>include.  I haven't gone through it all yet because on my vacation 
>>(which just ended) I decided to goof off instead of hack.  What issues 
>>are you having?
> 
> 
> I can't read the EPG in - I'm using DVB-T and the channel ids don't match 
> up with what the code expects! Timers are also unreadable, probably due to 
> the same issue, rather than digging in and re-solving it I thought I'd ask 
> to see if someone else already has.

Ok, I don't think this lib has ever been developed or tested with DVB-T 
and I was afraid this would be a problem.  Can you followup with a few 
examples of the DVB-T channel ids?  I will also look at the man page for 
them.  Do you know of any other differences between DVB S/C/T as far as 
the VDR config is concerned?  I will update the code for this asap.


>>It sounds like you should build a server process which is the single 
>>point of communication to VDR.  In my other project, Freevo 
>>(http://freevo.sf.net), we are working on an EPG library (pyepg) which 
>>can use vdrpylib to fill its database.  You may be interested in that 
>>sort of thing.  I have also been working on a client-server 
>>implimentation of pyepg but that part is specific to Freevo so far.
> 
> 
> I always like the idea of leveraging 3rd party code, it seems the
> client-server implementation might be the most appropriate idea for my
> project (vdr-mediamvp) whereby the database resides in one process and the
> rest of the server in another. I suppose the obvious question regarding
> that is why couldn't the database be just another vdr module to avoid
> holding two sets of the same data (apart from having to write the code
> myself of course!)

I've read up on vdr-mediamvp a few times as I would like to get an MVP 
myself - cool project.  BTW how much python does it use?

I can see how in this case you wouldn't want to have redundant sets of 
data.  If you think about it though, reading the whole EPG with each MVP 
client is kinda doing the same thing.  How much memory does the MVP 
have, 30-40 megs to keep the EPG around on each client does seem like a lot.

Perhaps by only reading small parts of the EPG as you need it would work 
better, not that vdrpylib supports that atm.  You could also acheive 
this by writing vdrpylib-aware code on the server side with a custom 
client-server interface for vdr-mediamvp (with or without pyepg) to 
request EPG data in small chunks.  Either way you'll have a redundant 
pool of data but its best to have only two, both on the server, I think.

Maybe Vlad (Sebastien Lucas) can add his 2 cents, I think he's doing 
something similar for the xbox (XBMC?).


-Rob

Re: [vdrpylib-devel] pending patches?

[Dominic M. <do...@su...>]

On Thu, 6 Jan 2005, Rob Shortt wrote:

> Hi, welcome to the list.  Sorry for the late reply.

No worries, I'm still on hols, so I've got time on my hands to hack, if 
only I could decide on one thing to do at a time!

> There is a patch from Vlad here which contains some changes which I may 
> include.  I haven't gone through it all yet because on my vacation 
> (which just ended) I decided to goof off instead of hack.  What issues 
> are you having?

I can't read the EPG in - I'm using DVB-T and the channel ids don't match 
up with what the code expects! Timers are also unreadable, probably due to 
the same issue, rather than digging in and re-solving it I thought I'd ask 
to see if someone else already has.

> It sounds like you should build a server process which is the single 
> point of communication to VDR.  In my other project, Freevo 
> (http://freevo.sf.net), we are working on an EPG library (pyepg) which 
> can use vdrpylib to fill its database.  You may be interested in that 
> sort of thing.  I have also been working on a client-server 
> implimentation of pyepg but that part is specific to Freevo so far.

I always like the idea of leveraging 3rd party code, it seems the
client-server implementation might be the most appropriate idea for my
project (vdr-mediamvp) whereby the database resides in one process and the
rest of the server in another. I suppose the obvious question regarding
that is why couldn't the database be just another vdr module to avoid
holding two sets of the same data (apart from having to write the code
myself of course!)

cheers,

d.

Re: [vdrpylib-devel] pending patches?

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

Dominic Morris wrote:
> Hey, 

Hi, welcome to the list.  Sorry for the late reply.


> I hadn't noticed, until today, that this project was under new 
> maintainership.

Yep, I'm working on another project that I've been using it for and 
decided it would be easier to maintain vdrpylib than to send patches to 
a dead project. ;)


> I was wondering if there are any outstanding patches that have been on the 
> list but can't be accessed via the sf interface that might fix a few 
> things that break with my setup.

There is a patch from Vlad here which contains some changes which I may 
include.  I haven't gone through it all yet because on my vacation 
(which just ended) I decided to goof off instead of hack.  What issues 
are you having?


> Also, whilst I'm thinking about it, does anyone have a cunning idea how to
> share a vdr object amongst multiple python interpreters? I got the
> previous version running a few months ago and reading in all the epg data
> took up about 30-40MB of memory which multipled by however many clients 
> are connected doesn't scale too well!

It sounds like you should build a server process which is the single 
point of communication to VDR.  In my other project, Freevo 
(http://freevo.sf.net), we are working on an EPG library (pyepg) which 
can use vdrpylib to fill its database.  You may be interested in that 
sort of thing.  I have also been working on a client-server 
implimentation of pyepg but that part is specific to Freevo so far.

-Rob

[vdrpylib-devel] pending patches?

[Dominic M. <do...@su...>]

Hey, 

I hadn't noticed, until today, that this project was under new 
maintainership.

I was wondering if there are any outstanding patches that have been on the 
list but can't be accessed via the sf interface that might fix a few 
things that break with my setup.

Also, whilst I'm thinking about it, does anyone have a cunning idea how to
share a vdr object amongst multiple python interpreters? I got the
previous version running a few months ago and reading in all the epg data
took up about 30-40MB of memory which multipled by however many clients 
are connected doesn't scale too well!

cheers,

d.

[vdrpylib-devel] A little patch

[Sebastien L. <seb...@gm...>]

Hi all,

Here is attached a patch against my own modified checkout. I tried to
reduce a lot the differences between CVS and my code, but some
differences remain.

I've not included vsdrp.py in the patch because I had not the time to
test the CVS version. Si I just modified my code to looks like yours
(for the parameters, most of methods). I'll work on it soon.

The rest of the patch could be usefull. There is especially a fix in
the construction of channel.id : the rid should only by appended if is
not 0 (at least with my VDR 1.3.17, I own a DVB-S maybe it's different
with DVB-C or DVB-T).In the attached patch, I update self.id but as
the construction of the channel id is also used in vdr.addchannel, I'd
prefer having a channel.getChannelID method, It would be cleaner in my
opinion. I can provide a patch if you're interested.
  
I also included the code to replace indexes by index (list -> to
normal integer), cStringIO by StringIO to make the code more portable
(at least on Xbox).

I also changed parseepg to prevent from creating new channels if an
unlnown channel ID is in the epg.data. I don't find any interesting
advantage to create a new channel in this case.

Waiting for your opinion.

Bye

Vlad

[vdrpylib-devel] a little patch

[Sebastien L. <seb...@gm...>]

Hi all,

Here is attached a patch against my own modified checkout. I tried to
reduce a lot the differences between CVS and my code, but some
differences remain.

in the patch svdrp.py is completely different because I don't had the
time to test the CVS version. Si I just modified my code to looks like
yours (for the parameters, most of methods). I'll work on it soon.

There is also some modification made to event.py, but it's not finished yet.

The rest of the patch could be usefull. There is especially a fix in
the construction of channel.id : the rid should only by appended if is
not 0 (at least with my VDR 1.3.17, I also own a DVB-S maybe it's
different with DVB-C oi DVB-T).
I also included the code to replace indexes by index (list -> to
normal integer), cStringIO by StringIO to make the code more portable
(at least on Xbox).

I also changed parseepg to prevent from creating new channels if a new
channel ID is in the epg.data.

Waiting for your opinion.

Bye

Vlad

[vdrpylib-devel] Confused with lstc

[Sebastien L. <seb...@gm...>]

Hi,

I had enought free time to have a look to the modifications you made
to svdrp.lstc and vdr.retrievechannels() and I found some differences
(And as I'm currently away from home because of my work, I can't test
accurately).

svdrp.lstc no longer return a hashtable (indexes by channel ID), that
must break vdr.parseepg() wich use channels.has_key() ...... should
not work with plain list. I think you've done that to have an sorted
list. I've done that :

self.listeChainesTriees = self.channels.values()
self.listeChainesTriees.sort()

and I added a __cmp__ method to Channel.py.

EDIT : I'm stupid i should have read retrievechannels till the end.
There is still a hashtable. Sorry. But I still find the use of sort
prettier ;), anyway no big deal.

In svdrp.lstc you use :
c = channel.Channel(tokens[-1], counter)
to create a new channel object. I personnally use :
c = channel.Channel(tokens[-1], int (tokens[0]))
With that the index of the channel represent exactly the channel
number in VDR and it still allow to sort the channel list

in vdr.parseepg, I changed a little the code to skip lines without
correct channels (self.channel.has_key(ch_id) -> false). I don't see
any interest in creating a new channel in this case. What do you think
?

More news to come ...

Bye

Vlad

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

[vdrpylib-devel] Some of my code modifications

[Sebastien L. <seb...@gm...>]

Hi,

I ran out of time yesterday to check everything.

So I'll start with my modifications to channels.py and svdrp.py :

Channels.py :
I've added the same variables : provider, nid, rid, tid. Changed some
integer variables to string. No problems here. You've done the same.
You used a new variable id to store the channel ID, I used a new
method getChannelID() returning the same thing with almost the same
code.
I've also added a check un addevent to prevent events already finished
to be added (I don't remember why I added that).

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.

Svdrp.py :
I kept the original TelnetLib method.
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.

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

Other explained changes will come (probably this weekend).

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

Vlad

Re: [vdrpylib-devel] Same work here

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

Thomas Weber wrote:
> No worries. I'm pretty sure there are some things we can reuse and merge.

No doubt.


> Also it's great to have another user/developer.

Sure is!


> Btw, did you use the "original" telnetlib approach or plain socket 
> communication?
> I'm curious because i have some trouble with the telnet stuff from time 
> to time.
> This is especially true when i fetch larger amounts of data like the 
> whole EPG, for example.

The recent changes in PyEPG might make this more tolerable as our EPG is 
filled using VDR's periodicly using tv_grab -s vdr, therefore the guide 
is as fast as usual (heh, which still needs speedup work).


> @Rob: sorry about the latest "out-of-time" phase here
> I'm pretty sure you know those issues which are common to all open 
> source developers. :-)

Yeah, sure do!  Just take it easy though, your contributions are 
certainly appreciated.

-Rob

Re: [vdrpylib-devel] Same work here

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

Sebastien Lucas wrote:
> On Wed, 15 Dec 2004 11:34:14 -0400, Rob Shortt <ro...@in...> wrote:
>>Thanks for your interest.  BTW, what kind of application are you using /
>>writing to use vdrpylib?  Just curious here.
> 
> I started a VDR client on my Xbox with XBMC (via Streamdev). Currently
> it can show live TV and EPG. But it's not ready to be shown ;).

That's kindof the same thing we've been doing with Freevo.  Right now 
for live-tv I've been using vdr-xine or mplayer with streamdev.  For 
recording I've been streaming from streamdev and soon to have a real 
interface with timers to get VDR doinf the recordings and compare the 
results.

For the EPG I've added support to PyEPG 
(http://freevo.sourceforge.net/cgi-bin/freevo-2.0/SourceDoc/PyEPG - also 
maintained with Freevo but is a seperate library) for importing the VDR 
EPG.  I can give some examples of its usage is you're interested.

-Rob

Re: [vdrpylib-devel] Same work here

[Sebastien L. <seb...@gm...>]

On Wed, 15 Dec 2004 17:24:19 +0100, Thomas Weber <tw...@us...> wrote:
> 
> Hi,
> 
> Sebastien Lucas schrieb:
> 
> >>>Well I should have looked at vdrpylib.sf.net before ...... the package
> >>>here is almost like mine.
> >>>
> >>>
> >>DOH!  Oh well.
> >>
> >>
> >>
> >
> >Yes....... not very proud of it :D
> >
> >
> No worries. I'm pretty sure there are some things we can reuse and merge.
> Also it's great to have another user/developer.
> Btw, did you use the "original" telnetlib approach or plain socket
> communication?
> I'm curious because i have some trouble with the telnet stuff from time
> to time.
> This is especially true when i fetch larger amounts of data like the
> whole EPG, for example.


Yes I used the original Telnetlib approach. But I've had the same
problems you have and I finally found a fix. I'll send svdrp.py
tomorrow.

Bye.

Re: [vdrpylib-devel] Same work here

[Thomas W. <tw...@us...>]

Hi,

Sebastien Lucas schrieb:

>>>Well I should have looked at vdrpylib.sf.net before ...... the package
>>>here is almost like mine.
>>>      
>>>
>>DOH!  Oh well.
>>
>>    
>>
>
>Yes....... not very proud of it :D
>  
>
No worries. I'm pretty sure there are some things we can reuse and merge.
Also it's great to have another user/developer.
Btw, did you use the "original" telnetlib approach or plain socket 
communication?
I'm curious because i have some trouble with the telnet stuff from time 
to time.
This is especially true when i fetch larger amounts of data like the 
whole EPG, for example.

> 
>  
>
>>>I'll check the difference between the cvs and my code and I'll post on
>>>this list.
>>>      
>>>
>>That would be great!  I have some uncommited code but its mostly
>>indentation cleanups.  I am currently also looking at timers and adding
>>to the interface there.
>>    
>>
Great!
@Rob: sorry about the latest "out-of-time" phase here
I'm pretty sure you know those issues which are common to all open 
source developers. :-)

Greetings,

-- 
Thomas Weber

Re: [vdrpylib-devel] Same work here

[Sebastien L. <seb...@gm...>]

On Wed, 15 Dec 2004 11:34:14 -0400, Rob Shortt <ro...@in...> wrote:
> Sebastien Lucas wrote:
> > Hi all,
> 
> Hi!
> 
> 
> > Just a little mail to say that I've done almost the same job as you :
> > make vdrpylib work with VDR1.3.x. I was updating all the headers to
> > write all the changes I've done wher I had a look on vdrpylib.sf.net.
> >
> > Well I should have looked at vdrpylib.sf.net before ...... the package
> > here is almost like mine.
> 
> DOH!  Oh well.
> 

Yes....... not very proud of it :D
 
> > I'll check the difference between the cvs and my code and I'll post on
> > this list.
> 
> That would be great!  I have some uncommited code but its mostly
> indentation cleanups.  I am currently also looking at timers and adding
> to the interface there.

I have enought motivation to work on it tonight, I'll post tomorrow.
 
> > Bye and thanks for the job.
> 
> Thanks for your interest.  BTW, what kind of application are you using /
> writing to use vdrpylib?  Just curious here.

I started a VDR client on my Xbox with XBMC (via Streamdev). Currently
it can show live TV and EPG. But it's not ready to be shown ;).

Vlad

Re: [vdrpylib-devel] Same work here

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

Sebastien Lucas wrote:
> Hi all,

Hi!


> Just a little mail to say that I've done almost the same job as you :
> make vdrpylib work with VDR1.3.x. I was updating all the headers to
> write all the changes I've done wher I had a look on vdrpylib.sf.net.
> 
> Well I should have looked at vdrpylib.sf.net before ...... the package
> here is almost like mine.

DOH!  Oh well.


> I'll check the difference between the cvs and my code and I'll post on
> this list.

That would be great!  I have some uncommited code but its mostly 
indentation cleanups.  I am currently also looking at timers and adding 
to the interface there.


> Bye and thanks for the job.

Thanks for your interest.  BTW, what kind of application are you using / 
writing to use vdrpylib?  Just curious here.

-Rob

[vdrpylib-devel] Same work here

[Sebastien L. <seb...@gm...>]

Hi all,

Just a little mail to say that I've done almost the same job as you :
make vdrpylib work with VDR1.3.x. I was updating all the headers to
write all the changes I've done wher I had a look on vdrpylib.sf.net.

Well I should have looked at vdrpylib.sf.net before ...... the package
here is almost like mine.

I should have been lazy this time.

I'll check the difference between the cvs and my code and I'll post on
this list.

Bye and thanks for the job.

Vlad

[vdrpylib-devel] state of CVS

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

I've just committed all of the changes from Thomas' last release (maybe 
some stuff from Ove in there too).  In addition to these I've added some 
more myself and smoothed over some of the differences.

I won't have time to test the actual commits until later this evening. 
Also I may change some of the python install (vdr vs vdrpylib 
namespaces), but will have to play around there and see what feels right.

Also anonymous CVS is having some troubles.  From the sourceforge status 
page:

(  2004-11-23 08:07:38 - Project CVS Service )   On 2004-11-23 a disk 
failure on the anonymous CVS server for projects starting with the 
letters: e, h, i, j, o and v is causing anonymous CVS, ViewCVS and 
tarballs for these projects to be unavailable. We are currently working 
on this issue and do not have an ETA for resolution.

-Rob