[mythtvnz] epgsnoop/xmltv-proc-nz/tv_grab_nz-py

[David Moore]

On 18/10/14 20:55, Aaron Pelly wrote:
> TL;DR Comments requested for a replacement xmltv grabber for NZ
>
> I've been thinking about how to string all this together in an xmltv 
> friendly way.
>
> My thoughts, based on my progress so far:
> 1) Change mhegepgsnoop to invent xmltv channel names based on 
> somehting like trim(name)+'.freeview.nz' and return all channel data, 
> regardless of which channels interest you. We have to decode it all 
> anyway. This means mhegepgsnoop no longer needs configuration. But 
> will probably mean renaming some of your channels in Myth. Can also 
> make it handle utf-8 characters properly.
>
> 2) Process the data as per the xmltv spec, to exclude everything that 
> is not interesting. This should be easy enough to do by modifying an 
> existing grabber. The recommended new grabbers do seem more 
> feature-complete than our current one.
>
> 3) Within the modified grabber, call xmltv-proc-nz to augment any 
> remaining data. This processes the minimum amount of data, which is a 
> good thing.
>
> I'm kind of reluctant to make yet another copy of an mheg reader, 
> knowing that my copy will surely fall into disrepair at some stage. 
> Perhaps the author would care to comment? On the other hand, the code 
> could really do with some comments and a bit of a clean up. Caching 
> would be good too, for testing. And it might be interesting to make it 
> Python 3 as well.
>
> As for utf-8; I haven't had any to work with yet, because they have 
> been missing in the guide data. I am confident this can be made to 
> work properly with only minor changes to existing code.
>
> I feel like I'm very close to something good here. xmltv-proc-nz 
> probably needs more options, but, from where I am, this should be 
> crazy-easy to implement.
>
> Anyway, I'm kind of thinking out loud here, but if anyone has an 
> opinion I'm all ears.
>
Hi Aaron,

I'm the primary author of mhegepgsnoop. Others have made useful 
contributions and I'm happy to accept changes but I have one 
non-negotiable rule. Any changes must be backward compatible. So if you 
want to _extend_ mhegepgsnoop in some way then go for it. Just add 
another command line option and the help for that option. I'm happy to 
help you with this.

I would strongly recommend against forking the project because I won't 
support such a fork. Your comment about not making another mheg reader 
is probably wiser than you think. Getting and parsing the mheg data was 
by far the trickiest part of the code. So if it needs to change in 
future there is quite a steep learning curve to acheive reasonable 
understanding of this part of the code. But, hey, if you're up for the 
challenge then go for it. :) Maybe you'll work out a better way to get 
the data.

BTW if you like C (C++?) then have a look at the rb-download source to 
see how it gets the mheg data.

Offer to clean up code and add more comments (where really useful) 
gratefully accepted. :) Actually I know the code is a bit spaghetti. 
Knowing what I know now I would write it much differently if I started 
now. But it ain't broke so I don't fix it.

BTW I really don't see Python 3 compatibility as something that needs to 
be tackled soon. Fine if you want to do it but it seems to me that 
Python 2 will be around for a while yet. Just check out the number of 
libs available for 2 vs 3. 2 won't go away until 3 has a similar number 
of libs available.

Cheers
David