OTA DVB EPG Grabber Question

DeltaMikeCharlie

I realise that a definitive answer would need to come from the original developers and that the likelihood of that happening is minuscule, however...

tvheadend/tvheadendblob/653bd0400b4413db96b80c807f0f7524f9248adb/src/epggrab/module/eit.c#L707C1-L715C55

Can anyone think of a reason why when processing OTA DVB EPG entries, TVH tries to match based on channel+start+stop rather than channel+event_id.

The event_id is supposed to be the unique identifier for that event, as the details of the event changes, the event_id remains stable. If the event scheduling changes, the event_id should theoretically stay the same.

With the current system, matching by channel+start+stop, if an existing event is rescheduled, then it will not match the incoming event and will be treated as a new event rather than a changed event. If there is no match, then a new event will be created with the same event_id.

For example, if a scheduled recording is linked to an event_id and that event is deleted (even briefly), what, if any, impact will this have?

The ATSC and OpenTV grabbers both seem to lookup based on channel+event_id. It's just odd that DVB does not.

I have not personally seen any ill effects from this, nor I have not dug very deeply into this yet or know what the practical implications of this may be. There may be a perfectly reasonable explanation.

davep

DeltaMikeCharlie One possibility: if a channel has two services mapped to it, the event_ids may not match. This certainly happens with UK Freeview and Freesat.

DeltaMikeCharlie

davep One possibility: if a channel has two services mapped to it, the event_ids may not match.

Thanks, that sounds very plausible. I wonder if there would be any benefit trying to match on either time or event_id first and then falling back to the other if no match is found?

davep

DeltaMikeCharlie There are already 'fuzzy' matching functions, epg_match_event_fuzzy() in epg.c and dvr_entry_fuzzy_match() in dvr/dvr_db.c.

I went down this rabbit hole a few years ago while trying to make EIT P/F recording more reliable, but eventually gave up. Now, I have recordings set with a 30-second 'warm-up' time; the EPG grabber runs during the warm-up and will adjust the recording times if they have changed.

DeltaMikeCharlie

davep There are already 'fuzzy' matching functions, epg_match_event_fuzzy()

Thanks, I'll have a look at that.

davep I went down this rabbit hole a few years ago

I spent part of today doing something similar before giving myself a good hard slap and getting on with more important things.

At some point in the future, I want to do a controlled test by:

Backing up the epgdb
Identifying an event that has a change in start time
Restore the epgdb and schedule that event to record.
Rerun the EPG grabber.

When the epg grabber is rerun either all will be well or the event_id in the scheduled recording will be broken.

If at that point, the link is broken, then there is a problem that needs to be looked at.