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

[Stephen Worthington]

On Tue, 14 Oct 2014 00:31:27 +1300, you wrote:

>On 07/07/14 11:14, Aaron Pelly wrote:
>> There are also a couple of things I'd like to tweak.
>TL;DR If you want/know/care you can give advice about NZ EPG data 
>enhancement.
>
>So, I've made significant progress on this front, but I'm no Python 
>programmer. I'd like some advice from the list.
>
>The short story is that I've updated xmltv-proc-nz to use tmdb api v3 
>and to use tvdb. I also cloned tv_grab_nz-py and changed it to use 
>mhegepgsnoop and xmltv-proc-nz. It's a bit band-aids and string at the 
>moment, but over the next couple of weeks I'll make it look acceptable 
>and work nicely. It will appear on github. (Assuming the BSD licence 
>allows credited, derivative works; I am presume it does but haven't 
>checked yet.)
>
>Data storage advice:
>I do not know why Hads wrote xmltv-proc-nz (but I wouldn't have got this 
>far if he hadn't!) but it has some config that it attempts to get from 
>the web. This makes sense, but I have no interest in maintaning a web 
>service for it. The things that you might want to change, like 
>categories, show names etc. I have currently coded in the script. This 
>is plain wrong. I have three ideas about where to put these, but I'm not 
>sure what's best.
>
>MySQL: Easy to implement, but less easy to edit. Requires multiple 
>tables. Not sure if user tables are allowed in mythconverg
>.mythtv/config.xml: Easy to implement and fairly easy to edit, not sure 
>if user data is allowed. User hints can be stored in the XML
>.xmltv/some_other_file: Sounds cleanest, but it's another file to setup 
>during installation, which is already a painful time.

I am not sure if user tables are "allowed" either, but they work just
fine without causing MythTV any problems.  But doing it that way would
require people to have some method of doing SQL on the tables to edit
them, which is beyond the skill level that is aimed at for MythTV
users.  And is discouraged by the devs.  Personally, I think I would
prefer to use extra database tables, but for quite a few people, they
would be much happier with a text file they can edit.

Making changes in the existing config.xml is definitely not a good
idea.  It gets updated by MythTV upgrades sometimes, and that would
probably lose any extra things stored there.

>xmltv grabber / mythfilldatabase advice:
>Will mythfilldatabase run automatically during a recording? Preliminary 
>testing indicates that mhegepgsnoop trashes an in-progress recording, 
>but that could be a coincidence. More testing is required.

My experience is that mhegepgsnoop is fine with a recording that is
already running.  It attempts to tune the tuner, but if that does not
work because mythbackend has control of the tuner, it grabs using the
current tuning and that does not disturb an in-progress recording. But
if you happen to run mhegepgsnoop just before a recording starts, it
is possible that mhegepgsnoop may have control of the tuner and that
may prevent mythbackend from using it, which will probably mess up one
or more recordings.  But I have never actually had this happen as I
normally only run mhegepgsnoop manually when I am unable to get
downloaded EPG.

mythfilldatabase runs whenever it is scheduled to - it does not try to
avoid recordings.  I run mine as cron job at the same time each day
rather than have mythbackend schedule it.  The heavy database access
it causes can potentially cause recordings on the same drive to have
gaps in them.  And in my case, it definitely can affect my Sky
recordings, due to problems with the drivers used for that.  As well,
I need to use a DVB-S tuner for epgsnoop to get my Sky EPG, so I
schedule mythfilldatabase runs for when no Sky recordings are
happening.

>xmltv grabber / mhegepgsnoop advice:
>There's a chicken and egg thing going on with channel configuration 
>here: mhegepgsnoop cunningly looks in mythconverg/channel for configured 
>channels, but xmltv expects you to choose your channels then myth seems 
>to insert them in the channel table for you, if it can. This insertion 
>appears to be broken for me at the moment, but that is a feature to 
>address another day anyway. The question really is, is it acceptable for 
>a new grabber to only return data for channels it finds already in the 
>channel table, or should it use an external config file like 
>tv_grab_nz-py does?

Automatic creation of channels has always been a fraught business -
allowing it to happen can cause serious problems unless the channel
updates come from a carefully controlled source such as the US
DataDirect.  There is often not enough information available from
normal EPG sources to create a full channel setup in the database. The
channel number is not usually available, for example.  I run
mythfilldatabase with the --only-update-guide option to prevent it
from doing any channel updates.  I do all my channel updates manually.

>I'll finish doing this for myself anyway, but if anyone else is 
>interested in the results of my small effort, now is a good time to 
>speak up.
>
>Aaron.

BTW Have you converted to Python 3?  Python 2 is deprecated and going
away eventually in Ubuntu.