Hello Guest, if you are reading this it means you have not registered yet. Please take a second, Click here to register, and in a few simple steps you will be able to enjoy our community and use our OpenViX support section.
Results 1 to 15 of 25

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

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1
    smallfrak's Avatar
    Title
    Junior Member
    Join Date
    Jan 2015
    Location
    Austria
    Posts
    19
    Thanks
    2
    Thanked 3 Times in 3 Posts

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

    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.
    Attached Files Attached Files

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
This website uses cookies
We use cookies to store session information to facilitate remembering your login information, to allow you to save website preferences, to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners.