Regular freeze after scheduled EPG Refresh, no CrashLog, debug log confusing

[smallfrak]

Hello folks,

this is bugging me a while now. (almost) Every day in the morning, about when the scheduled EPG-refresh might finish, the box freezes all higher function. The clock stops counting, OpenWebIF is unresponsive. No Display and dead remote.

FTP, SSH do work and the Debug Log is still updated with various regular stuff as if nothing had happened. So it's not the entire system that is dead. I can only get it working again by pulling the plug.

If I do a manual EPG-refresh, this finishes without a problem. It seems that only the refresh from normal standby causes this problem. EPG refresh is scheduled around 06:30, clock usually hangs about 06:37. Today I switched it off around that time, as I found it hanging since yesterday morning and the usual EPG refresh started delayed - and did hang the box at 06:54.

I captured the debug log a while later from within this state to determine the cause. I was confident, that this quite short log file would give me a clue. However it does not.

The timestamp obviously is "seconds since last boot" which makes it very uncomfortable to match the events to world time. It's not clear to me how the filename (Enigma2_debug_2017-04-29_06-36-58.log) corresponds with the forst entry timestamp
< 54.693> [Avahi] avahi_timeout_new

Does it imply that 06:36:58 was creation time of the log which corresponds to ~55 seconds power up time? Then I have to add the timestamp values in the log minus 54.693 to "06:36:58" to get the real time?

In this case I get maybe the last good entry like this:

06:54:13 [EPGRefresh] Timer added <EPGRefreshTimerEntry (Sa 29 Apr 2017 06:54:47 CEST, 0, <bound method EPGRefresh.refresh of <Plugins.Extensions.EPGRefresh.EPGRefresh.EPGRefre sh instance at 0x71a59af8>>)>

This corresponds well with the 30 seconds EPG channel time I had set. However this schedule did never start or at least it did not leave any trace in the log. Instead I get the following entry near the expected schedule time:

06:54:19 [gRC] main thread is non-idle! display spinner!

Other than this epgrefresh, I have installed "Serienrecorder" which is scheduled to run a good deal after EPGrefresh and I had set "save EPG to File every 1 hour" with a path to the internal harddisk. I set this to be able to load a reasonable current copy of the EPG after the necessary reboot when the EPG refresh did hang again. I get freezes without this. It just eases the pain a little.

I do not have any Sky channels, but I have an ORF card and I have problems with the EIT EPG on all WDR Sat Channels - as everyone else too.

I have connected both internal receivers to ASTRA 19.2 SAT, no cable.

The usual "delete epg.dat" did not change anything.

I had freezes and crashes when zapping throug graphical EPG lately, which is some new behaviour and might correspond to the WDR EPG problem.

Where else could I look to track this thing down? This is quite nasty.

[smallfrak]

Meanwhile I did a complete Image restore with no Settings and did set up everything fresh.
It did hang again at 06:32 today...

[malcolmp]

I have some problems not unlike yours with EPG

[smallfrak]

I have some problems not unlike yours with EPG

At least I'm not the only one. If I look at the success rate to my problems, I sometimes get the imagination that I have some "ignore me" tag fixed to my account.

Today ist went fine...
< 40231.153> [EPGRefresh] Debug: Refresh finished!

Instead I had a crash when switching to a channel yesterday evening:

< 77.755> Traceback (most recent call last):
< 77.756> File "/usr/lib/enigma2/python/Screens/VideoMode.py", line 486, in VideoChangeDetect
< 77.756> IOError: [Errno 1] Operation not permitted: '/proc/stb/video/videomode_50hz'
< 77.756> [ePyObject] (CallObject(<bound method AutoVideoMode.VideoChangeDetect of <class 'Screens.VideoMode.AutoVideoMode'>>,()) failed)

So well, that's life.

[ccs]

Try this thread...

http://www.world-of-satellite.com/sh...l=1#post438848

[smallfrak]

Try this thread...

http://www.world-of-satellite.com/sh...l=1#post438848

OK, I did. First I did not see any connection to my problem as I do not have any boot problems and I'm using a 5.xx release instead of a 4.xx

At least I found a hint, that the Quad+ might have issues with the "multi" refresh rate - which I indeed have set. Now I have set it for 50Hz fixed 1050p. We will see, whether this might show an improvement.

[ccs]

The connection was the crash you reported 3 posts ago which referred to Operation not permitted: '/proc/stb/video/videomode_50hz'

[smallfrak]

The connection was the crash you reported 3 posts ago which referred to Operation not permitted: '/proc/stb/video/videomode_50hz'

Thanks for the tip. While it probably helps with the spurious crashes when zapping through the EPG, it unfortunately is not related to the daily freeze during EPGrefresh. It was dead again today at 06:32

If it does the same tomorrow morning, I try the

init 4 && enigma2 &> /media/hdd/Enigma2_debug_$(date +%Y-%m-%d_%H-%M-%S).log

[smallfrak]

If it does the same tomorrow morning, I try the

init 4 && enigma2 &> /media/hdd/Enigma2_debug_$(date +%Y-%m-%d_%H-%M-%S).log

So well, it did. I found it hanging again. Issued the above command via SSH and id created a logfile. However, I did not get any picture but a "no free tuner available" and a spinning logo. After the logfile did not grow for a couple of seconds, I cancelled the command and tried a

shutdown -r now

It DID boot but this time it hang during the boot process with the progress bar at "2" on the small display.
Cycling the power switch brought back the box showing the correct start channel - which is ORF2 that must be decoded by CCcam and my ORF card. All functions normal this time.

So once again I issued the INIT command which generated another log file, this time showing the decoded channel and fully responsive. The spinning logo was present too and did not go away. However, it was not possible to watch a different encrypted channel other than the boot channel, so probably there was some communication problem with the CCcam. FTA channels where OK.

I stopped the command again and the two generated log files are in the attachment.

Certainly the picture went away after ^C as enigma was shut down. "shutdown" did again hang with a spinning logo and "2" in the progress bar as before, so the power switch was the next one.

This is not my only LINUX machine, but i never had any problems shutting down before. This one is somehow special or some external hardware it depends on is in a non responsive state that is cleared only by power off.

So if anyone can glimpse at the log files and maybe find something to point at, I would be very glad.

[smallfrak]

Attached Files
Logfiles.zip (28.9 KB, 1 views)

Hmm. As soon as I post some logfiles, the thread is essentially dead. The interest in them is obviously limited. Could the one who DID read them please state his findings? If it's "found nothing, looks OK" then at least I have an answer.

Even a negative result is a valuable information.

Even more useful would be "still not conclusive, can you try this or that to get a more meaningful trace"

[twol]

Hmm. As soon as I post some logfiles, the thread is essentially dead. The interest in them is obviously limited. Could the one who DID read them please state his findings? If it's "found nothing, looks OK" then at least I have an answer.

Even a negative result is a valuable information.

Even more useful would be "still not conclusive, can you try this or that to get a more meaningful trace"

Doesn't solve your issue directly, but why don't you try epgimport, rather than crossepg and see what happens?

[divil_a_bit]

I had freezes and crashes when zapping throug graphical EPG lately, which is some new behaviour and might correspond to the WDR EPG problem.

I'm seeing this crash/hang with the graphical EPG also! I've started a thread on this here
As I mentioned on that thread - I've 2 GB Quad+ receivers, both running 5.0.11. One receiver has never crashed, the other crashes all the time! The major difference between the 2: 1 has an internal 1TB HDD, the other has an 8GB USB

I've applied the 50/60Hz patch already and it hasn't made a difference

[Andy_Hazza]

I don't think the 8GB usb is sufficient for Timeshifting, EPG and whatever else you may use it for.


Sent from my iPhone using Tapatalk

[divil_a_bit]

OK - thanks Andy. I'll try a HDD.

I can cause a crash using timeshift and/or EPG just seconds after reboot though which means the 8GB is not fully used.

[ccs]

OK - thanks Andy. I'll try a HDD.

I can cause a crash using timeshift and/or EPG just seconds after reboot though which means the 8GB is not fully used.

I assume by crash you actually mean hangs, otherwise crash logs would be generated.