EPG not populating

prpr

Well-Known Member
The WebIF EPG doesn't populate after a reboot on my HDR.
The Process list shows:
/mod/bin/epg -f /media/drive1/epgsavedata sqlitedumpd /media/drive1/epg.db
Obvious that is the wrong path.
With a bit of detective work I find it's started by /mod/etc/init.d/S60parseepg which contains:
Code:
if [ -f /mnt/hd1/dvbepg/epg.dat ]; then
  epg=/mnt/hd1/dvbepg/epg.dat
  epgdb=/mnt/hd1/epg.db
else
  epg=/media/drive1/epgsavedata
  epgdb=/media/drive1/epg.db
fi
Looking at /mnt/hd1/dvbepg immediately after boot, I find it is empty. The epg.dat file appears after about a minute.
This is obviously the cause, so it would seem a better test needs devising. Why not use the /etc/model string?

This used to work until whatever changed in that file on Jan 5 at 02:21.
This now works for me:
Code:
if [ `cat /etc/model` == 'HDR' ]; then
 
Looking at /mnt/hd1/dvbepg immediately after boot, I find it is empty. The epg.dat file appears after about a minute.
This is obviously the cause, so it would seem a better test needs devising. Why not use the /etc/model string?

The /etc/model file would be a better check, yes, and I'll update that for the next version. It didn't exist in early versions of the CFW hence the existing check.
You might want to investigate why that directory is empty following a boot, that isn't normal and nobody else has reported problems with EPG population.

This used to work until whatever changed in that file on Jan 5 at 02:21.

That file hasn't changed for over a year...

Code:
% svn log S60parseepg
------------------------------------------------------------------------
r599 | af123 | 2011-10-20 23:24:25 +0000 (Thu, 20 Oct 2011) | 1 line

update epg extraction
------------------------------------------------------------------------
r569 | af123 | 2011-09-29 22:58:13 +0000 (Thu, 29 Sep 2011) | 1 line

add epg parser
------------------------------------------------------------------------
 
That file hasn't changed for over a year...
Bizarre, but let's see:
Code:
humax# opkg search *S60parseepg
webif - 0.11.0
humax# opkg download webif
Downloading http://hummypkg.org.uk/hdrfoxt2/base/webif_0.11.0_mipsel.opk.
Downloaded webif as ./webif_0.11.0_mipsel.opk.
humax# opkg-unpack  webif_0.11.0_mipsel.opk
Unpacked  to webif_0.11.0_mipsel
humax# cd webif_0.11.0_mipsel/etc/init.d
humax# ls -l
-rwxr-xr-x    1 root     root           318 Jan  5 02:21 S60parseepg

Someone or something has changed that file in your repository, that is clear.
I'm not sure how to, or even if I can, get at the previous version of webif to compare.
 
The previous versions are all still downloadable from the repository. The timestamp of the file has changed but the contents has not.

Code:
% for f in webif_0.10.0_mipsel.opk webif_0.11.0_mipsel.opk; do
for> ls -l $f
for> mkdir t
for> (cd t; ar -x ../$f; gzip -dc data.tar.gz | tar -xf -
for subsh> ls -l etc/init.d/S60parseepg
for subsh> digest -a sha256 etc/init.d/S60parseepg
for subsh> )
for> echo
for> rm -rf t
for> done
-rw-r--r--  1 1002    root      1016K Nov  5 23:20 webif_0.10.0_mipsel.opk
-rwxr-xr-x  1 root    root        318 Oct 20  2011 etc/init.d/S60parseepg*
b5a229d51674760a87d03cb7d14007dd7a7037033310849db35f403914587d3c
 
-rw-r--r--  1 1002    root        1.1M Jan 18 22:48 webif_0.11.0_mipsel.opk
-rwxr-xr-x  1 root    root        318 Jan  5 02:21 etc/init.d/S60parseepg*
b5a229d51674760a87d03cb7d14007dd7a7037033310849db35f403914587d3c
 
OK, the timestamp's changed. It doesn't change the fundamental problem that the file being testing for to determine the path to use doesn't exist at the time of the test and therefore selects the wrong path.
I don't know why the file doesn't exist, but like I said before, there seems to be a better way of doing the test, so why not adopt it?
 
I've already said I will change the test in the next version to use /etc/model (Post 2). I agree with you, it is a better test.

It does seem to be only your box that doesn't have the file after a boot - are you running a standard version?
 
I've already said I will change the test in the next version to use /etc/model (Post 2). I agree with you, it is a better test.
Missed that bit in all the excitement.

It does seem to be only your box that doesn't have the file after a boot - are you running a standard version?
It does it on both boxes, both currently running 2.14 although I'll put 2.15 back on the one here in a minute.
It's as standard as anything, those changes to browse.jim notwithstanding.
Was repeatable last night - the file had disappeared immediately after reboot. I'll check again with 2.15
 
Took 4 minutes this time...
Code:
humax# ls -lR /mnt/hd1
/mnt/hd1:
drwxr-xr-x    2 root     root          4096 Jan 25 16:41 dvbepg
-rw-------    1 root     root       3822592 Jan 25 15:45 epg.db
-rw-r--r--    1 root     root          1036 Jan 25 15:19 filebglastop.dat

/mnt/hd1/dvbepg:
humax# diag epgrange
Running: epgrange
/mnt/hd1/dvbepg/epg.dat: No such file or directory
Thu Jan  1 00:00:00 GMT 1970
/mnt/hd1/dvbepg/epg.dat: No such file or directory
Thu Jan  1 00:00:00 GMT 1970
humax# ls -lR /mnt/hd1
/mnt/hd1:
drwxr-xr-x    2 root     root          4096 Jan 25 16:45 dvbepg
-rw-------    1 root     root       3822592 Jan 25 15:45 epg.db
-rw-r--r--    1 root     root          1036 Jan 25 15:19 filebglastop.dat

/mnt/hd1/dvbepg:
-rw-r--r--    1 root     root       3001288 Jan 25 16:45 epg.dat
humax# uptime
 16:45:26 up 4 min,  0 users,  load average: 0.46, 0.24, 0.09
 
I'm sure you've already spotted this but, epgrange is returning time stamps of Zero e.g. epoch time of 0000000000 because it can't find the data
 
You might want to investigate why that directory is empty following a boot, that isn't normal and nobody else has reported problems with EPG population.
This morning did a search for a programme on the webif epg and noticed the output was missing entries. Still on the 2.14 firmware but all packages are up to date.
Code:
humax# ls -l /mnt/hd1
drwxr-xr-x    2 root    root          4096 Jan 26 12:53 dvbepg
-rw-r--r--    1 root    root      4776960 Jan 24 11:22 epg.db
 
humax# ps w | grep epg
  548 root      1652 S <  /mod/bin/epg -f /media/drive1/epgsavedata sqlitedumpd /media/drive1/epg.db
  943 root      1344 S    grep epg
So it looks like epg.db hasn't been updated for the last couple of days and the symptoms look similar to prpr's.
 
Code:
  548 root      1652 S <  /mod/bin/epg -f /media/drive1/epgsavedata sqlitedumpd /media/drive1/epg.db
So it looks like epg.db hasn't been updated for the last couple of days and the symptoms look similar to prpr's.
Yes, your path is wrong like mine was, presumably for the same reason.
See the top of the thread for which file to edit, until af123 pushes out the next update to Webif.
 
Back
Top