missing epg data - opentv

[satteliter]

update:

yesterday morning(7th) ran fine with no crash.
this morning(8th) - i had ABM set to run(& wake from deep standby) at ~03.30. There was a crash at that time.

There was also a later crash near when EPGRefresh(not set to wake up from deep standby) ran at ~07.40.


03.30 crash:

< 38.4470> 03:29:53.0296 [eDVBLocalTimerHandler] remove channel 0x1027468
< 38.4474> 03:29:53.0299 [eEPGTransponderDataReader] remove channel 0x1027468
< 38.4510> 03:29:53.0335 PC: 00553308
< 38.4510> 03:29:53.0336 Fault Address: 00553308
< 38.4511> 03:29:53.0336 Error Code: 2147484175
< 38.4512> 03:29:53.0338 Backtrace:
< 38.4514> 03:29:53.0340 /usr/bin/enigma2(_Z17handleFatalSignaliP9siginfo_tPv) [0x889D4]
< 38.4516> 03:29:53.0341 /lib/libc.so.6(__default_rt_sa_restorer) [0xB5B511D0]
< 38.4516> 03:29:53.0342 -------FATAL SIGNAL (11)

07.37 crash:

< 39.3109> 07:37:53.2914 [eDVBLocalTimerHandler] remove channel 0x1024d50
< 39.3113> 07:37:53.2918 [eEPGTransponderDataReader] remove channel 0x1024d50
< 39.3143> 07:37:53.2948 PC: 17b4aecc
< 39.3144> 07:37:53.2949 Fault Address: 17b4aecc
< 39.3144> 07:37:53.2949 Error Code: 2147484166
< 39.3146> 07:37:53.2951 Backtrace:
< 39.3148> 07:37:53.2953 /usr/bin/enigma2(_Z17handleFatalSignaliP9siginfo_tPv) [0x889D4]
< 39.3150> 07:37:53.2955 /lib/libc.so.6(__default_rt_sa_restorer) [0xB5BA11D0]
< 39.3151> 07:37:53.2955 -------FATAL SIGNAL (11)

View attachment Enigma2_crash_2023-03-08_03-29-53.log
View attachment Enigma2_debug_2023-03-08_03-29-38.log
View attachment Enigma2_debug_2023-03-08_03-30-03.log

View attachment Enigma2_debug_2023-03-08_07-37-38.log
View attachment Enigma2_crash_2023-03-08_07-37-53.log
View attachment Enigma2_debug_2023-03-08_07-38-03.log

What's interesting to note is ABM did not put box back to deep standby. i think this is because i had hdmi-cec settings which took tv out of standby when box came out of standby (which ABM (i think) did)). The TV then must have been sending the wakeup hdmi-cec signal such that the box never went back to standby(judging from log entries)

I've since moved ABM to run after the scheduled auto power timer turns box on(~07.30) and turned off 'wake/return to standby' settings for ABM.
Also disabled HDMI-CEC turn on tv settings for the time being.

I've attached log from the successful run yesterday just for the record:

View attachment Enigma2_debug_2023-03-07_07-30-39.log

Will monitor and update.

 

[satteliter]

I think you also may have the OpenTV Zapper enabled as I can see entries in the log for it. I suggest that you use either OpenTV zapper or EPGRefresh - not both. .

It was disabled when I installed EPGRefresh. I think those entries will be present regardless of status.

[OpentvZapper] < 1066.1597> 07:55:00.1402 [OpentvZapper] next wake up due -1
....
< 34.5017> 07:37:48.4822 [OpentvZapper-Scheduler][Scheduleautostart] AutoStart Enabled
< 34.5019> 07:37:48.4824 [OpentvZapper-Scheduler][AutoScheduleTimer] Schedule Disabled at Wed 08 Mar 2023 07:37:48 GMT

 

[satteliter]

So just to close this issue off, the days since the last post have been trouble free. No crashes, no huffman errors & most importantly - no empty EPGs.

The following are the settings that were in play. The brief version is ABM and EPGRefresh no longer handled wake up or shutdown. They ran within the power timer scheduled on/off.


Here are the logs for the morning run logs for the last few days in case it provides any historical/future troubleshooting use:


9th View attachment Enigma2_debug_2023-03-09_07-30-41.log
10th View attachment Enigma2_debug_2023-03-10_07-30-37.log
11th View attachment Enigma2_debug_2023-03-11_07-30-38.log
12th View attachment Enigma2_debug_2023-03-12_07-30-44.log

If any crashes/errors discussed in this thread appear again I'll open new thread.

Thank you all for your assistance!

 

[BrianG61UK]

On my Zgemma H7S I get the same effect sometimes where it's like the text is missing from the EPG so that multiple EPG entries look blank on the EPG.

I've been experimenting to try and figure out what's going on but I haven't really got very far yet.
I'm hindered by knowing C pretty well but not C++.

I find one thing that makes it go wrong on my Zgemma H7S is if I happen to be flicking through the channels at a time when the EPG is being read (by either OpenTV Zapper or by EPG Refresh).

I should add. For me this is not a new problem. I have always found the EPG would occasionally corrupt in this way (lots of blank entries).

I've been trying to make everything that's involved with reading the OpenTV EPG run at a high priority, but it doesn't seem to make any difference. But I may have missed something.
Weirdly, it looks like the current code actually runs (or is intended to run - it looks wrong to me) the EPG reading stuff at a low priority!?

Do no other people find that flicking from channel to channel (satellite channels) while OpenTV EPG download starts doesn't cause a problem?

I'm wondering if it's some weird bug that's specific to Zgemma or to the Zgemma H7.

 

[abu baniaz]

Sky UK changes are normally Tuesday/Thursday. Consider changing your days to Wednesday/Friday.

 

[urie]

@abu baniaz, with reguards to OpenTV zapper do you think it could be ported to openatv, I use epg refresh I select a few channels only for freeview bbc one and E4 but with reguards to IEPG data 1 when I select that in epgrefresh obviously no signal as to speak in autobouqets maker I don't want to have bouquet sky info shown and in epg main setting i have nothing enabled
I know I can just select a channel on freeview and epg will be pulled in but would be good to have epg there without having to zap to a channel if possible

 

[abu baniaz]

You will have to ask ATV, but it is just a zapper. You can select iepg from service list instead of bouquet.

 

[Joe_90]

Do no other people find that flicking from channel to channel (satellite channels) while OpenTV EPG download starts doesn't cause a problem?

I'm wondering if it's some weird bug that's specific to Zgemma or to the Zgemma H7.

Definitely causes an issue (sometimes!). I can't pin it down. I know if I don't disturb the download, then I have no issues with the EPG.

 

[LraiZer]

So this huffman issue only happens when a user zapperdy zap zap zaps on multi-tuner box... eg. zapping tuner 1 while opentv zapper has also initiated an epg download on tuner 2?

Many..

< 438.7103> 17:45:54.2754 [huffman] Error. Cannot decode Huffman data

huffman_root is being reset to NULL each zap prior to the check for valid epg transpoder in the call to the huffman_read_dictionary() function.

I think moving the code in huffman.cpp for the epg transponder validation check so that it is above the huffman_root NULL should stop those huffman decode errors.

diff --git a/lib/base/huffman.cpp b/lib/base/huffman.cpp
index 70ef87c8a8..a8e6be661c 100644
--- a/lib/base/huffman.cpp
+++ b/lib/base/huffman.cpp
@@ -12,6 +12,13 @@ type_huffman_node huffman_root;
 bool huffman_read_dictionary (char *file)
 {
 	FILE *fd;
+	fd = fopen (file, "r");
+
+	if (!fd)
+		return false;
+	else
+		eDebug("[huffman] read.. '%s'", file);
+
 	char line[512];
 	char value[256];
 	char code[256];
@@ -24,15 +31,6 @@ bool huffman_read_dictionary (char *file)
 	huffman_root.p0 = NULL;
 	huffman_root.p1 = NULL;
 
-	eDebug("[huffman] read.. '%s'", file);
-
-	fd = fopen (file, "r");
-	if (!fd)
-	{
-		//eDebug("[huffman] Cannot open dictionary file");
-		return false;
-	}
-
 	while (fgets (line, sizeof(line), fd))
 	{
 		memset (value, 0, sizeof (value));

 

[Joe_90]

So this huffman issue only happens when a user zapperdy zap zap zaps on multi-tuner box... eg. zapping tuner 1 while opentv zapper has also initiated an epg download on tuner 2?

Many..


huffman_root is being reset to NULL each zap prior to the check for valid epg transpoder in the call to the huffman_read_dictionary() function.

I think moving the code in huffman.cpp for the epg transponder validation check so that it is above the huffman_root NULL should stop those huffman decode errors.

...

Yep - I think that about describes the error situation - zapping while the OpenTVzapper is running seems to trigger the runaway error messages. It would be great if a code change could be made. Happy to test.

 

[abu baniaz]

I have submitted a pull request here: https://github.com/OpenViX/enigma2/pull/849
A build will need to be run for it to be tested

 

[LraiZer]

patch missing this line from above...

-	eDebug("[huffman] read.. '%s'", file);

 

[abu baniaz]

@joe_90
Any update on the change. If OK, we can submit pull request to other images.

 

[Joe_90]

Waiting on dev build 6.3.004.013 - the 011 and 012 builds did not work for me as there was a bug in menu.py which surfaced in my sorted menu. I did run the 012 build for a couple of days unattended on my single tuner HD61and the scheduled run of OpenTVzapper worked fine, but I didn't try to provoke the huffman error. Once 013 is available I will download later tonight on my Quad Plus and test.

 

[Joe_90]

Dev build 013 does not seem to have completed for ax61HD. I did flash the 013 build for the QuadPlus early this morning and will test it.

 

[Joe_90]

Dev build 014 has completed for the AX61HD. Have downloaded and flashed ok. Looks good so far. My AX61HD has only a single DVB-S tuner, so can't verify huffman issue on it. I am testing that on the Quad Plus.

 

[Joe_90]

Dev build 014 for Quad Plus tested for the "huffman error" bug. I can't provoke the runaway log error, despite switching DVB-S and DVB-T channels and starting recordings etc. while the OpenTVZapper is running. Problem seems fixed on the development/test image. Should be good for Release. Thanks @LraiZer and @abu baniaz!

 

[BrianG61UK]

I just built myself a 6.3.004.015 developer image for my Zgemma H7S and I too am unable to provoke it into showing blank EPG entries by doing things like channel zapping while OpenTV EPG download is occurring.

This is most excellent news.

Thank you @LraiZer. :thumbsup: