[mythtv] Status of Schedules Direct SD-JSON grabbers

[Carleton Daniels]

O


Sent from my MetroPCS 4G LTE Android device-------- Original message --------From: Gary Buhrmaster <gary.buhrmaster at gmail.com> Date: 7/27/2016  5:26 PM  (GMT-08:00) To: Peter Bennett <pgbennett at comcast.net> Cc: Robert Eden <rmeden at gmail.com>, Development of MythTV <mythtv-dev at mythtv.org> Subject: Re: [mythtv] Status of Schedules Direct SD-JSON grabbers 

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.

_______________________________________________

mythtv-dev mailing list

mythtv-dev at mythtv.org

http://lists.mythtv.org/mailman/listinfo/mythtv-dev

http://wiki.mythtv.org/Mailing_List_etiquette

MythTV Forums: https://forum.mythtv.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20160727/044be309/attachment.html>