[mythtv] Status of Schedules Direct SD-JSON grabbers

[Gary Buhrmaster]

On Wed, Jul 27, 2016 at 4:46 PM, Peter Bennett <pgbennett at comcast.net> wrote:
> Gary
>
> I have been using your grabber for almost a week now, and it is working
> well. I am getting 20 days worth of listings. Thank you!
>
> If I update the mythtv wiki for xmltv are you OK with me adding this
> grabber to the documentation?

The xmltv project is in the middle of accepting (and renaming)
both grabbers to reflect the multi-national capability. Perhaps
one should wait just a little bit longer?

On the other hand, if you have free time now, it is better to
get that something started now.  It can always be updated
later with the changes.

> Since Paul has been using this for some time from the UK, you could
> remove references to it being for North America.

 ^ ^ ^ ^ ^ see above ^ ^ ^ ^ ^

> One Observation: If I do channel selection on a new setup, the channels
> are presented in random order without channel numbers. If I do --days 0
> after initializing the database, the channels are presented in channel
> number order with channel numbers, names and call signs, which is a lot
> better.

I will have to think a bit.  Stations have no specific order in
xmltv, but humans seem to have this habit of wanting the
derived channel number to be in order (but, note, it is not
a simple sort order, but a "channel" order (as a channel,
channel 2.4 is before 2.10, but not as a number sort,
as 2.10 is lower than 2.4), and not as a character sort
where you get into issues where channels such as
1 2 3 10 11 20 turn into 1 10 11 2 20 3, which is not what
you want either).  Adding in a custom parse and sort will
require some thought, and whether it can even be done
efficiently in the current code constructs is unknown.

It should be noted that xmltv deals with station selections,
and it, too, has no useful order (as the xmltv ids from
Schedules Direct have no order than makes a lot of
sense to humans).

btw, as I recall (I am not in a position to easily check
at the moment) the MythTV channel editor does not
sort channels "correctly" either (where "correctly" means
the human expectation, not the program implementation).

> To save memory I am creating files with 3 days at a time for reading
> into mythfilldatabase. This reduces the resident memory requirement for
> mythfilldatabase to 400 MB instead of up to 5 GB.

Or review and propose getting ticket #12758 committed?

Yes, it is the wrong fix, but it is also a quick fix that
does not require reworking the current mfdb approach
(although I keep hoping someone with copious free time
will consider doing the better fix).  And it does have
the current benefit of working (or at least it did last
time I used it).  I should note that you do not need to
run the mfdb load directly on an under-resourced MBE
(although some care and feeding of the config files
do need to be dealt with).  So there are a couple of
viable solutions.

Completely off topic, but I have some higher priority
tasks that need to get accomplished RSN, so some
responses may get delayed.