EEPG freesat S28E2 funktioniert nicht mit Fehlermeldung: EEPG: Missing table 2 entry

Leider scheint eepg ungepflegt zu sein.

Ich habe versucht das Plugin bei einem Bekannten zu nutzen und mit aktivem eepg regelmäßig VDR-Crashes gehabt.

Erstmal habe ich mich damit abgefunden, dass es für die "Englischen" im VDR kein EPG gibt.

Läuft das Plugin denn bei dir (von den Fehlermeldungen abgesehen) stabil?

Also unter vdr 2.2.0 läuft das Plugin stabil.

Ich habe immer unter 2.4.0 getestet.

Kann schon sein, dass da irgendwas mit "Locking Order" noch nicht ganz sauber ist.

Genutzt habe ich auch die letzte GIT-Version.

Der VDR hat sich immer nach unregelmäßiger Zeit einfach verabschiedet (wenn ich mich richtig erinnere mit "Emergency Exit").

Hi,

habe eben mit vdr-2.4.1 und vdr-plugin-eepg-experimental.tar.bz2

getestest --> geht

Gruss

vdr[594]: [594] switching to channel 1 S28.2E-2-2045-6390 (BBC RB1)
vdr[594]: [603] SVDRP server handler thread started (pid=594, tid=603, prio=low)
vdr[594]: [603] SVDRP baumhaus.home.test opening port 6419/tcp
vdr[594]: [603] SVDRP baumhaus.home.test listening on port 6419/tcp
vdr[594]: [594] OSD size changed to 720x480 @ 1
vdr[594]: [594] ERROR: no OSD provider available - using dummy OSD!
vdr[594]: [594] ERROR: Channel locked (recording)!
vdr[594]: [598] EEPG: setstatus 0
vdr[594]: [598] EEPG: setstatus 1
vdr[594]: [598] EEPG: Filter Pid:0x0,Tid:0x0 added.
vdr[594]: [598] EEPG: PMT scan idle
vdr[594]: [598] EEPG: FreeView Extended EPG detected on pid f02.
vdr[594]: [598] EEPG: Filter Pid:0xf02,Tid:0x4e,Mask:0xfe added.
vdr[594]: [598] EEPG: Filter Pid:0xf02,Tid:0x50,Mask:0xf0 added.
vdr[594]: [598] EEPG: Filter Pid:0xf02,Tid:0x60,Mask:0xf0 added.
vdr[594]: [598] EEPG: Filter Pid:0x39,Tid:0x50,Mask:0xf0 added.
vdr[594]: [598] EEPG: Filter Pid:0x39,Tid:0x60,Mask:0xf0 added.
vdr[594]: [598] creating new channel 'BBC One Lon,;BSkyB' on S28.2E transponder 110773 with id 2-2045-6301-0
vdr[594]: [598] creating new channel 'BBC Two,;BSkyB' on S28.2E transponder 110773 with id 2-2045-6302-0
vdr[594]: [598] creating new channel 'ETV1,;BSkyB' on S28.2E transponder 110773 with id 2-2045-6306-0
vdr[594]: [598] creating new channel 'BBC Four,;BSkyB' on S28.2E transponder 110773 with id 2-2045-6316-0
vdr[594]: [598] creating new channel 'CBeebies,;BSkyB' on S28.2E transponder 110773 with id 2-2045-6318-0
vdr[594]: [598] creating new channel 'BBC One Lon,;BSkyB' on S28.2E transponder 110773 with id 2-2045-6321-0
vdr[594]: [598] changing pids of channel 6 (CBeebies) from 0+0=0:0:0:0 to 5200+5200=2:5202=NAR@3,5201=eng@3:5204=eng:5203

Teste mal über nen längeren Zeitraum. Hat bei mir augenscheinlich auch funktioniert. Die Crashes waren immer erst nach etwas Laufzeit.

Zitat von M-Reimer

Die Crashes waren immer erst nach etwas Laufzeit.

Ich benutze eine ältere GIT-Version (Dez.2018).
Da habe ich den "Emergency Exit" so gut wie immer täglich nachts (01 - 05 Uhr)
Ich dachte das hätte was mit dem "Befüllen" zu tun und achte halt drauf,
das ich in der Zeit möglichst wenig aufnehme.

bin ehrlich gesagt nicht auf die Idee gekommen, das es das Plugin selber ist

Gruß, jo01

Hi,

I provide a solution in the vdr-2.4.0-eepg-lock.patch attached to this bug report. I use it with VDR 2.4.0 and have no further crashes. The patch thus disables some of the repeated logging.

https://projects.vdr-developer.org/issues/2586

The 7-day channel data is up-to-date. VDR to crash with "video data stream broken", presumably due to its being a data stream only nowadays. Forced tuning to the channel for 30 minutes - 1 hour is sufficient.

I have forked the plugin on github and applied the patches there: https://github.com/nickb937/vdr-plugin-eepg

Nice information. I'll definitively try that!

At least in theory you should be able to get commit access to the repository if the original author does not longer want to maintain the plugin.

Best way would be if you try to contact the original author about that.

But forking to github would be OK, too.

What do you mean with this "7-day" thing? So it is not enough to just have the plugin active and configure VDR to do its regular EPG scan?

I thought as a first step, I'd file the bug report and let the author commit the change. I wasn't originally planning to do any more than that until I saw this forum post, then I have been additionally thinking about committing the Genres patch https://projects.vdr-developer.org/issues/1908 and doing some cleanup.

As for the 7-day EPG issue. The problem is that the EPG data is provided in chunks every 2 (i think) minutes. To get the full EPG you have to listen to the channel for 30 minutes. VDR does not stay tuned to the EEPG plugin to recover all the data, so the EPG contains the now-and-next info only.

A related discussion I had with the author on similar lines is here, where he suggests that you have to explicitly tune to the channel to get the data: https://projects.vdr-developer.org/issues/1634. I felt that recording the channel was a sufficient hack but maybe now I need to do an explicit tune request on a cron-job to achieve the same effect:

#!/bin/bash

# 162 is EPG Background channel in my channels.conf

$ echo "CHAN 162" >/dev/tcp/<server>/6419

Wouldn't it be possible to let the plugin tune? On idle or of the regular EPG scan runs?

To fetch the full EPG, the channel I tune to is:

EPG Background Audio.;BSkyB:11778:VC23M2S0:S28.2E:27500:0:648=@4:0:0:4152:2:2004:0

I have used TVheadend in the past and know that it does not need to tune to this channel for long periods of time to get the schedules. I'd like to spend some time figuring out why and see if EEPG can be improved in this respect.

Absolutely fantastic that this plugin in being worked on again! Thank you very much for that!

I just wanted to let you guys know that the channel carrying the EPG data "EPG Background Audio." is being marked as OBSOLETE since some time now which made me delete it. That was a mistake however since despite being marked as OBSOLETE it still carries the EPG data and there seems to be no substitute channel for it. I've had VDR always configured so that the EPG channel is the channel which is being tuned to on bootup, which makes sure that all the EPG-data can be fetched. It would be awesome of course if manually tuning or setting the EPG channel as the startup channel wouldn't be necessary anymore.

Btw I wrote in June that the plugin is stable but I also have some random VDR restarts, so I suspect I was a bit premature when writing that. I see absolutely no pattern in the VDR restarts however.

Zitat von sg75

; BSkyB: 11778: VC23M2S0: S28.2E: 27500: 0: 648 = @ 4: 0: 0: 4152: 2: 2004: 0 I get the following error message after a couple of minutes :

Code

Sep 29 20:50:14 rotorpi vdr [17515]: [17521] EEPG: Error, 262144 titles found more than 262144
Sep 29 20:50:14 rotorpi vdr [17515]: [17521] EEPG: Fatal error reading titles.
Sep 29 20:50:14 rotorpi vdr [17515]: [17521] EEPG: found 127 themes
Sep 29 20:50:14 rotorpi vdr [17515]: [17521] EEPG: found 745 channels
Sep 29 20:50:14 rotorpi vdr [17515]: [17521] EEPG: found 262144 titles
Sep 29 20:50:14 rotorpi vdr [17515]: [17521] EEPG: found 0 summaries
Sep 29 20:50:14 rotorpi vdr [17515]: [17521] EEPG: written 0 titles
Sep 29 20:50:14 rotorpi vdr [17515]: [17521] EEPG: written 0 summaries
Sep 29 20:50:14 rotorpi vdr [17515]: [17521] EEPG: rejected 0 titles / summaries because of higher TableId
Sep 29 20:50:15 rotorpi vdr [17515]: [17521] EEPG: Ended all processing
Sep 29 20:50:15 rotorpi vdr [17515]: [17515] info: EEPG: written 0 summaries

Alles anzeigen

Written 0 titles and 0 summaries does not look so good, does it?

Does it make sense to patch? MAX_TITLES to a higher value?

The number of titles seems significantly higher than anything I've seen, though I have a similar number of channels and summaries.

[root @ tv ~] # journalctl --unit = vdr.service --since = "30 minutes ago" | egrep -e 'found [0-9] * titles'

Oct 11 21:07:38 tv.house vdr [616513]: [616536] EEPG: found 21508 titles

Oct 11 21:07:57 tv.house vdr [616513]: [616536] EEPG: found 20225 titles

Oct 11 21:08:17 tv.house vdr [616513]: [616536] EEPG: found 21668 titles

Oct 11 21:08:38 tv.house vdr [616513]: [616536] EEPG: found 22084 titles

Oct 11 21:08:59 tv.house vdr [616513]: [616536] EEPG: found 22140 titles

Oct 11 21:09:19 tv.house vdr [616513]: [616536] EEPG: found 22097 titles

Oct 11 21:09:39 tv.house vdr [616513]: [616536] EEPG: found 21662 titles

Oct 11 21:09:52 tv.house vdr [616513]: [616536] EEPG: found 5450 titles

Oct 11 21:09:52 tv.house vdr [616513]: [616536] EEPG: found 0 titles

[root @ tv ~] # journalctl --unit = vdr.service --since = "30 minutes ago" | egrep -e 'found [0-9] * channels'

Oct 11 21:07:38 tv.house vdr [616513]: [616536] EEPG: found 744 channels

Oct 11 21:07:57 tv.house vdr [616513]: [616536] EEPG: found 744 channels

Oct 11 21:08:17 tv.house vdr [616513]: [616536] EEPG: found 744 channels

Oct 11 21:08:38 tv.house vdr [616513]: [616536] EEPG: found 744 channels

Oct 11 21:08:59 tv.house vdr [616513]: [616536] EEPG: found 744 channels

Oct 11 21:09:19 tv.house vdr [616513]: [616536] EEPG: found 744 channels

Oct 11 21:09:39 tv.house vdr [616513]: [616536] EEPG: found 744 channels

Oct 11 21:09:52 tv.house vdr [616513]: [616536] EEPG: found 744 channels

Oct 11 21:09:52 tv.house vdr [616513]: [616536] EEPG: found 744 channels

[root @ tv ~] # journalctl --unit = vdr.service --since = "240 minutes ago" | egrep -e 'found [0-9] * summaries'

Oct 11 18:07:37 tv.house vdr [616513]: [616536] EEPG: found 21081 summaries

Oct 11 18:07:58 tv.house vdr [616513]: [616536] EEPG: found 19690 summaries

Oct 11 18:08:18 tv.house vdr [616513]: [616536] EEPG: found 21076 summaries

Oct 11 18:08:39 tv.house vdr [616513]: [616536] EEPG: found 21397 summaries

Oct 11 18:09:00 tv.house vdr [616513]: [616536] EEPG: found 21494 summaries

Oct 11 18:09:21 tv.house vdr [616513]: [616536] EEPG: found 21559 summaries

Oct 11 18:09:38 tv.house vdr [616513]: [616536] EEPG: found 15998 summaries

Oct 11 18:09:55 tv.house vdr [616513]: [616536] EEPG: found 11156 summaries

Oct 11 18:09:55 tv.house vdr [616513]: [616536] EEPG: found 0 summaries

I think that 0 titles and 0 summaries is always to be expected as it marks the end of the batch of EPG data.

Oct 10 00:09:51 tv.house vdr [3278234]: [3278325] EEPG: found 0 titles

Oct 10 03:09:52 tv.house vdr [3278234]: [3278325] EEPG: found 0 titles

Oct 10 06:09:52 tv.house vdr [3278234]: [3278325] EEPG: found 0 titles

Oct 10 09:09:48 tv.house vdr [3278234]: [3278325] EEPG: found 0 titles

Oct 10 12:09:48 tv.house vdr [3278234]: [3278325] EEPG: found 0 titles

Oct 10 15:09:50 tv.house vdr [3278234]: [3278325] EEPG: found 0 titles

Oct 10 18:09:49 tv.house vdr [3278234]: [3278325] EEPG: found 0 titles

Oct 10 21:09:53 tv.house vdr [3278234]: [3278325] EEPG: found 0 titles

Oct 11 00:09:54 tv.house vdr [3278234]: [3278325] EEPG: found 0 titles

Oct 11 03:09:51 tv.house vdr [3278234]: [3278325] EEPG: found 0 titles

Oct 11 06:09:56 tv.house vdr [3278234]: [3278325] EEPG: found 0 titles

Hi,

I also had the problem, that the 7-day epg didn't work for the freeview channels.

I've found the reason: the huffman tables haven't been correctly initialized due to the scanf parameter change (%a no longer works like it use to in new glibc).

Here is the patch:

diff --git a/eepg.c b/eepg.c
index 1b6c9f0..a78819d 100644
--- a/eepg.c
+++ b/eepg.c
@@ -391,7 +391,7 @@ static bool load_freesat_file (int tableid, const char *filename)
 
     while (fgets (buf, sizeof (buf), fp) != NULL) {
       from = binary = to = NULL;
-      int elems = sscanf (buf, "%a[^:]:%a[^:]:%a[^:]:", &from, &binary, &to);
+      int elems = sscanf (buf, "%m[^:]:%m[^:]:%m[^:]:", &from, &binary, &to);
       if (elems == 3) {
         int bin_len = strlen (binary);
         int from_char = resolve_char (from);

Regards,

Martin