Project

General

Profile

Bug #3952

"gaps" in epg

Added by Kai Sommerfeld about 8 years ago. Updated about 8 years ago.

Status:
Fixed
Priority:
Normal
Category:
EPG
Target version:
Start date:
2016-08-25
Due date:
% Done:

0%

Estimated time:
Found in version:
4.1.2190 (but observered since months)
Affected Versions:

Description

I'm observing "gaps" in my epg which are definetely wrong as other epg sources, for instance the website of the broadcaster and even older tvheadend 4.1.x (January 2016) prove.

I'm just guessing, but could it be the case that https://github.com/tvheadend/tvheadend/commit/d4384a5e9b4a45faf3502f5392924fb9c9ab56fe causes this trouble?

Please see my code comments there:

https://github.com/tvheadend/tvheadend/commit/d4384a5e9b4a45faf3502f5392924fb9c9ab56fe#commitcomment-18772525
and
https://github.com/tvheadend/tvheadend/commit/d4384a5e9b4a45faf3502f5392924fb9c9ab56fe#commitcomment-18772548

History

#1

Updated by Jaroslav Kysela about 8 years ago

If you know the gaps, you can probably check why the event import fails. Do you use only one EPG grabber ?

If it's only EIT grabber: --trace epg,tbl-eit (with latest).

To convert times (start/stop) use this python code:

import time
time.strftime('%Y-%m-%d %H:%M:%S', time.localtime(1472133077))

Where 1472133077 is UTC time from epg/eit log you'd like to convert to the local time.

#2

Updated by Kai Sommerfeld about 8 years ago

Unfortunately it is very difficult to catch the right data (although i'm currently trying). But it is sure that the gaps "appear" if existing timeline of events gets changed afterwards, for instance if a special news report is inserted in between the existing events timeline.

#3

Updated by Kai Sommerfeld about 8 years ago

I use only eit grabber, yes.

From the logs I see that for me, _epg_object_can_remove quite often returns zero because ngrab == 0. Is zero ngrab okay? TBH, I don't get the logic...

#4

Updated by Jaroslav Kysela about 8 years ago

It looks suspicious. Could you try this patch?

diff --git a/src/epg.c b/src/epg.c
index ecb2648..1c985f1 100644
--- a/src/epg.c
+++ b/src/epg.c
@@ -1642,6 +1642,7 @@ static epg_broadcast_t *_epg_channel_add_broadcast
       _epg_object_create(ret);
       // Note: sets updated
       _epg_object_getref(ret);
+      ret->grabber = src;
       tvhtrace(LS_EPG, "added event %u (%s) on %s @ %"PRItime_t " to %"PRItime_t,
                ret->id, epg_broadcast_get_title(ret, NULL),
                channel_get_name(ch), ret->start, ret->stop);
#5

Updated by Jaroslav Kysela about 8 years ago

I put this fix to v4.1-2196-gedcd83b, because I believe that it's the culprit. Also, I added check for the NULL grabber check there, so wrong events without the grabber are no longer tracked (they can be saved with buggy code). Please, test.

#6

Updated by Kai Sommerfeld about 8 years ago

Thanks. I will update to 2196 tonight and keep an I on the "gaps", hoping there are no more, then.

What makes me wonder is this peace of code, which implies that zerp grabber is fine?!

...
static int _epg_object_set_grabber ( void *o, epggrab_module_t *ngrab ) {
epggrab_module_t *ograb;
if (!ngrab) return 1; // grab=NULL is override
...

#7

Updated by Kai Sommerfeld about 8 years ago

No more "gaps" where no gaps should be. I think we can call the problem solved.

#8

Updated by Jaroslav Kysela about 8 years ago

  • Status changed from New to Fixed

Also available in: Atom PDF