[mythtv-users] tv_grab_zz_sdjson_sqlite version 1.65
stephen_agent at jsw.gen.nz
Sat Dec 22 08:20:31 UTC 2018
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.
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.
More information about the mythtv-users