[mythtv-users] tv_grab_zz_sdjson_sqlite version 1.65

[Stephen Worthington]

On Fri, 21 Dec 2018 11:59:33 -0500, you wrote:

>
>On 12/20/18 6:42 PM, Stephen Worthington wrote:
>> On Thu, 20 Dec 2018 11:53:24 -0500, you wrote:
>>
>>> tv_grab_zz_sdjson_sqlite was very recently updated to version 1.65.  I
>>> noticed that there is an additional parameter question asked about 3rd
>>> party metadata or something like that. I took the default. Everything is
>>> working on my system but I noticed a Mythtv-Frontend display difference
>>> on recorded program lists.
>>>
>>> If I move the arrow down through the list of recordings at the bottom of
>>> the display is the details of that recording. On any new recording since
>>> the update I noticed that TV stations listed as, i.e. WRALDT 5.1
>>> (WRAL-DT).  But on recordings done prior to the update they all have the
>>> TV stations listed as, i.e. #1051#1051. Not a big deal, because those
>>> recorded shows will eventually get watched and deleted.
>>>
>>> Curious though??
>>>
>>> Jim A
>>>
>>> BTW, all the old recording were done using HDHR the internal method.
>>> The new recordings are done with mythhdhrrecorder external recorder.
>> A name like #1051 is displayed when there is no channel for the chanid
>> in the recording.  The 1051 is the chanid that was used to make the
>> recording and is stored in the recorded.chanid field.  I get
>> recordings like that when I use mythexport and mythimport to move
>> recordings to another MythTV system which does not have the same
>> channel setup.  So it looks like your new channels were created as
>> completely new - the old channel was deleted and a new one created,
>> and the new one has a different chanid.  This may have some
>> implications for your recording rules - the "record" table where the
>> recording rules are stored does have a chanid field.  Normally, the
>> record.station field is used for matching channels to EPG data, but
>> there is likely something that will be using the chanid field, and
>> that will now not match.
>> _______________________________________
>
>I was curious about this and used a mySQL browser (SQLyog.exe under 
>wine) to find the new channel numbers. Since I have 2 Video Sources only 
>differing by channel 11-n missing from one of them, I expected something 
>else.  What I saw in channel table was chanid 10000-10021 and 
>20000-20018.  Where the stations were the same from both video sources, 
>the channum, freqid, callsign were identical as well as the xmltvid.
>
>Then I looked at recorded table, chanid was the correct 10000-10021 or 
>20000-20018 for all new recordings, but had the old 1171, 1501, or 1111 
>numbers for the old recordings. I edited the recorded table old numbers 
>with the new chanids and now everything looks correct.
>
>I also had to fix the "this channel" recording rules since the channels 
>are different in the database.
>
>All is good now.
>
>Jim A

Yes, there are still all sorts of complications from having to rescan
the channels.  I do channel updates manually, so I have not done a
rescan for years.  If you use any "power" recording rules, where there
is some SQL code (stored in the subtitle field I think), then they
also need to be checked for use of chanid numbers.