EPG not populating

prpr · Jan 25, 2013

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

af123 · Jan 25, 2013

prpr said:
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
------------------------------------------------------------------------

Black Hole · Jan 25, 2013

Working here. Does the problem only manifest within a certain time of boot?

prpr · Jan 25, 2013

af123 said:
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.

af123 · Jan 25, 2013

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

prpr · Jan 25, 2013

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?

af123 · Jan 25, 2013

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?

prpr · Jan 25, 2013

af123 said:
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

prpr · Jan 25, 2013

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

Ezra Pound · Jan 25, 2013

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

prpr · Jan 25, 2013

Yes, I was merely using it to illustrate the point.

sooty83 · Jan 26, 2013

af123 said:
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.

Ezra Pound · Jan 26, 2013

af123 has posted that he found the cause of the EPG Problem and has a fix in mind (Post #771)

prpr · Jan 26, 2013

sooty83 said:
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.

af123 · Jan 26, 2013

I've published webif 0.11.0-1 with an amended S60parseepg.

EPG not populating

prpr

Well-Known Member

af123

Administrator

Black Hole

May contain traces of nut

prpr

Well-Known Member

af123

Administrator

prpr

Well-Known Member

af123

Administrator

prpr

Well-Known Member

prpr

Well-Known Member

Ezra Pound

Well-Known Member

prpr

Well-Known Member

sooty83

Member

Ezra Pound

Well-Known Member

prpr

Well-Known Member

af123

Administrator