Old / redundant EPG data

B

BlackCat3000

Member
I've just noticed something odd about the EPG data in my WebIf display: the EPG data goes all the way back to 6th October and many of the old entries have channel number zero, probably because of the channel re-tune that was necessary a few weeks ago. The Webif EPG is very slow to respond, too, presumably because of this. The Humax UI seems to be perfectly normal. Is there a way to to reset the EPG data to fix this? I'm using custom firmware 2.13 on a an HDR.
Thanks for any advice.
 
I believe this has been mentioned before. The EPG data accumulates, but I thought af123 had fixed it so only current data gets extracted.
 
Yes, the EPG database that the Humax firmware maintains sometimes seems to accumulate old data. That isn't anything to do with the custom firmware.

You can find out what range of data is in your current database by running the epgrange diagnostic:

Code: 
Running: epgrange
Wed Nov  7 08:30:00 GMT 2012
Sun Nov 18 23:50:00 GMT 2012

I should probably make the EPG extractor ignore old records but it doesn't currently.

To clear the data, you need to boot the box into maintenance mode (run the diagmode diagnostic then turn off/on using the remote control), then remove the /mnt/hd1/dvbepg/epg.dat file by telnetting in and using the rm command followed by reboot.

Code: 
humax# rm /mnt/hd1/dvbepg/epg.dat
humax# reboot
 
af123 said:
You can find out what range of data is in your current database by running the epgrange diagnostic:
Click to expand...

I don't get any data when running, epgrange. I think it must be missing a dependency, from WebIf >> Diagnostics I get :-
Code: 
>>> Beginning diagnostic epgrange
Running: epgrange
 
>>> Ending diagnostic epgrange

From Telnet I get :-
Code: 
humax# diag epgrange
Running: epgrange
date: invalid option -- 'D'
Try `date --help' for more information.
date: invalid option -- 'D'
Try `date --help' for more information.
humax#

It looks like it doesn't like date -D
 
The busybox command 'date' supports the -D option but I suspect that the date command from the binutils package does not. The binutils package will take precedence. A more universal way to convert from epoch time would be to use the @ format, even if it is somewhat buried deep in the documentation ;)

Code: 
date -d @<epoch-time>
 
Thanks for the suggestions, everyone. I ran epgrange and got the following, somewhat surprising, output:

Running: epgrange
Fri Mar 30 14:55:00 GMT 2012
Sun Nov 18 23:50:00 GMT 2012

I was under the impression that the oldest EPG data dated from 6th October, not 30th March. :eek:
The box is currently recording so I'll try clearing out the EPG data when the box goes quiet.
 
This may be at least partly my own fault. :rolleyes: I checked the channel group for the EPG in the WebIf settings and it seems the channel group is an old one that existed before the recent channel shake-up, containing channels that no longer exist. Changing it to a new group, where all the channels do exist, has speeded up things considerably.

Would it make sense for WebIF to delete or ignore anything to do with channel zero?

I'm still going to tidy up that EPG data, though. :)
 
I updated the diagnostic to use an explicit date binary between your two runs.
 
Ah, that explains it, is it possible to access the scripts called up when using [Telnet] diag 'script' or Web-If >> Diagnostics >> 'script' >> Run Diagnostic?. I guess they are on the Hummy server somewhere
 
I finally got round to clearing out the old EPG data:
Running: epgrange
Fri Nov 16 00:00:00 GMT 2012
Fri Nov 23 23:55:00 GMT 2012
The EPG display in WebIf is much faster now. Thanks to everyone for helping me to sort it out.
 
Ages ago
af123 said:
Yes, the EPG database that the Humax firmware maintains sometimes seems to accumulate old data. That isn't anything to do with the custom firmware.
...
To clear the data, you need to boot the box into maintenance mode (run the diagmode diagnostic then turn off/on using the remote
Click to expand...

It's possible to automate the EPG data clean-up.
  1. Define a flag file, say .epgclr in the EPG directory.
  2. Create a script to live in /mod/boot/xinit.d that spawns a process to poll for the discovery of the EPG filesystem and delete the EPG file and the flag file if the flag file is found, like this xepg:
    Code: 
    #!/bin/sh

log() {
      printf "XEPG: %s\n" "$*"
}

if [ "$(cat /etc/model)" = "HD" ]; then
        epg=/media/drive1/epgsavedata
else
        epg=/mnt/hd1/dvbepg/epg.dat
fi

( 
  step=2
  epgflg="${epg%/*}"
  while [ ${ii:=200} -gt 0 ]; do
      sleep "$step"
      # "df dir" may not be enough to ensure that "dir" is mounted, so
      # check that "dir" is actually mentioned in the df output
      df "$epgflg" 2>/dev/null | grep -q "$epgflg" && break
      ii=$((ii-step))
  done

  epgflg="${epgflg}/.epgclr"
  log "Checking flag $epgflg"
  if [ -e "$epgflg" ]; then
      log "About to clear EPG file $epg ..."
      rm -f "$epg" && 
              log "... cleared." &&
              rm -f "${epgflg}"
  fi
) &
  3. Now after creating the flag file and restarting, BANG the old data is gone; there may be an AV glitch shortly after the picture appears as the deletion happens.
There could be a diagnostic epgclear to set the flag so that the whole process can be run from the Webif.

Or is there now already a better solution?

Update: modify script for HD Fox compatibility.
 
Last edited:
You must log in or register to reply here.
Back
Top