[mythtv-users] DVB re-scan and XMLTV EPG?

[John Pilkington]

On 29/01/15 10:12, Mike Perkins wrote:
> On 29/01/15 09:39, Alistair Grant wrote:
>> Hi Hika,
>>
>> On Thu, Jan 29, 2015 at 4:18 AM, Hika van den Hoven
>> <hikavdh at gmail.com> wrote:
>>> I've been thinking a bit about this thing. As you might have seen I am
>>> currently developing on the Dutch XMLTV grabber.
>>>
>>> There are several identifiers for a channel. Of which several in
>>> essence are free for the user to choose/define. What such a script
>>> should do is save the linking between the three identifiers BEFORE you
>>> delete the old lineup and then afterwards restore on the basis of the
>>> saved info. So you need a two step script. (three if you include the
>>> scan)
>>>
>>> You have
>>> - chanid    Internal MythTV identifier, which you on first setup are
>>>              free to choose and which links to all kind of other
>>>              tables.
>>
>> chanid is the primary key for the channel table.  The user shouldn't
>> have to know about it, and I have a hard time believing that it is OK
>> to  change it.
>>
> chanid is also the first part of the generated filename for the
> recording, the rest being the date and time. It will be the only way to
> link older recordings back to the channel they came from, so changing it
> should be a last resort.

Hmm.  I see that programmes recorded earlier from cbbc (was 70, now 120) 
are now shown in 'Previously Recorded' as from '70 CBS Action.'
I doubt that you can future-proof everything...

>
> Personally, I would have steered clear of that format, since it is
> putting metadata in the filename. A simple unique integer,with perhaps
> an alpha prefix, could link the file back to the appropriate database
> records and avoid the problem I mention above.
>>
>>
>>> - sourceid  The MythTV internal ID of the source of your EPG-data
>>>              (confusingly called video-source)
>>> - xmltvid   EPG-id defined by the XMLTV grabber/EPG-source.
>>> - channum   Is the identifier from your provider/cable company, but I
>>>              think only relevant during a scan and afterwards free to
>>>              choose/change. Unless you use Schedules Direct, where it
>>>              doubles as EPG-id.
>>> - callsign  Is I think the naming of the channel by your provider/cable
>>>              company, but again I think in essence free to choose/change
>>>              afterwards.
> Be aware that Callsign in the US is a short jumble of letters. In UK
> Freeview, it can be a long descriptive string, such as 'BBC ONE South'.
> This usually gets truncated, meaning matching can be a problem, even by
> eye.
>
>>> - name      Is your name of choice
>>
>>
>>> - freqid    On analog the frequency in kHz or the channel-number
>>> - mplexid   and
>>> - serviceid The identifiers of the actual digital channel
>>> - iptvid    The identifier of an iptv channel
>>
>> The user shouldn't have to know about any of these, hopefully :-)
>> (I'm not sure about setting up iptvid).
>>
> In the UK, freqid is the number of the digital channel as supplied by
> Freeview. This will be used by the tuner to locate and tune the channel.
>
> It is possible that the other values are used instead, but if I type in
> '11' then the channel having freqid '11' is what is tuned.
>
>>> What the script needs to do is to relink chanid, xmltvid, name and
>>> maybe sourceid back to the found channels as identified by channum. A
>>> problem comes if your provider changes channums, so you always will
>>> need a personal check afterwards.
>>
>> I assumed that the script would:
>>
>> * Use the CallSign to link the tv_grab_xxx (EPG data) output to the
>> MythTV channel data.
>> ** This is where the fuzzy logic would be used to match callsigns.
>> * Update the xmltvid's in the MythTV channel table.
>> * Allow the user to:
>> ** Modify the CallSign in MythTV (to match the EPG data)
>> ** Provide mapping between EPG callsign and MythTV callsign (if they
>> don't want to modify the CallSign for some reason).
>> ** Modify ChanNum in MythTV
>> ** Modify ChannelName in MythTV
>>
>> The script configuration will be in a file that will allow it to be
>> re-run as a single step in the event that a re-scan is necessary.
>>
>> I'm not aware of the design decisions behind the structure of the
>> Channel table, so some of the above may be incorrect.
>>
>
>