On Tue, Jul 08, 2003 at 03:25:53AM -0300, James Oakley wrote: > Fair enough. It *did* screw me up as well. I let out a curse when I noticed my > load_listings script fail.
Exactly... I knew you were human :) > The lastest version is always at > http://www.funktronics.ca:86/svn/python-xmltv/ Looks like only minor changes (based on a diff) We have a 'date_format_notz' for people who don't have a zone in their listings, Only other changes is that we seem to have an 'open' except (which isn't cool, but I don't want to change it now) where you have a valueerror, and we fudge the stop times for missing stop data rather than passing through. > Actually, I should probably explain that a bit more, as you may find it > interesting. Basically, I have a ZODB database accessable through ZEO > running. That's neat because it stores native Python objects and allows you > to access them as if they were all in memory. In reality, ZEO/ZODB only loads > objects from it's storage as you access them. It's pretty seamless and it > really cuts down on the memory use. Interesting; currently, we pickle (actually, cPickle into a binary pickle file) the data so it's pretty quick. But I want to move it to sqlite. sqlite blows me away every time I use it. The Python API is very lightweight, and adding sqlite support (including all third-party things) involves about 200kb. It's not object oriented, because it is married to SQL, but I suppose it could be. > I'm using a package called IndexedCatalog to provide an indexing system for > the objects. It's seriously cool, easy to use, and incredibly fast. It uses a > simple query language so you can do something like in the following scripts: > There are all kinds of other objects that I've defined or am planning to > define: Looks very cool; though do you have to run a seperate database process? One of our goals (constraints :) is the aim of keeping everything as simple as possible, hence our avoidance of a database until sqlite, which is basically not unlike using berkelydb or an indexed flat file, except that it's 90% of SQL92 compliant. > - - Event - This object, upon creation, schedules a run of 'OpenPVR_eventwrapper > some_unique_id' upon initialisation via at and is placed in a dictionary in > the ZODB. OpenPVR_eventwrapper gets the object and calls it's run() method, > which would generally call some method. I use this to schedule recordings > from a GUI interface I wrote in PyQt. I also see this as being useful for > sending Jabber messages: "Your favorite show is coming on in one minute!" That's really cool. You seem to have a lot of the stuff we had in mind. It might be a good idea to see what can be merged. > - - Preference - Implemented, but I haven't used it yet. This allows you to set > preferences so that a PVR can figure out what it should record. So far there > are 'Title', 'Category', and 'Channel' preferences. Each preference has > thumbsUp() and thumbsDown() methods that increment and decrement the score That's cool; definitely something we're going to do eventually. One of our developers (Rob) has been working on a variety of "higher" level PVR functionality and I'm anxiously awaited his commiting it. > wget -r http://www.funktronics.ca:86/svn > and delete all of the 'index.html' files that come down. I'll give it a shot... > I'll have a new xmltv.py by the time it's released, but like the current one, > it will provide raw access to the data. This means that there will be > refactoring needed. I'll probably make a compatibility mode though so that > you can take your time converting. If you want to see what's in store, check > out > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/xmltv/xmltv/todo/xmltv-0.6.dtd > > for the latest revision. There will probably be more modifications before > release, though. It's being discussed fairly heavily on xmltv-devel. I did check it out... I think your module will help us a lot, because as much as it's needed, I really don't want to write an XML parser. > channelOverrides = { 'Channel 44 COMEDC': "Comedy Network", > ... > } > > Whenever you use display-name, check to see if it's in channelOverrides. If > it's there, use that, otherwise, leave it as it is. That way you can have the > best of both worlds. Good idea. I agree that we should just use the channels in xmltv, because the user already had to choose which channels to watch there, so it's somewhat duplicated effort. > Yeah, that's a pain, especially with the current DTD. Fortunately for me, > IndexedCatalog will happily index member instances in newer versions. I just > changed my Program object to use a Channel object instead of the id. After > that I needed to add one line to my load_listings script to set it before > indexing. I'll never have to worry about the id again. After I get through some of the items on my TODO, I'll look into your solution. We should just read the XMLTV file and go with those channels. The only thing is that we need to split up the "display name" field to figure out the tuner channel; it doesn't appear to exist anywhere. Aubin ------------------------------------------------------- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
