• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Web-IF not loading

Aaron-B

Aaron-B

Member
Hi chums,

I've just tried to get into Web-IF (on one of my two boxes) today to download some recordings, but find it's not loading properly. A hard shut down cycle via the power button on the rear of the unit has not made any difference.

I get only the static header - without any of its hover/dropdown functionality - on a blank page.

Have tried other browsers and experience the same issue. Navigating directly to /browse/ returns 500 Internal Server Error.

Both CFW and Web-IF are up to date. Obviously cannot get any other information at this point though... Any ideas?!

1648467081918.png
 
Last edited:
There are a few ideas in this thread

HDR-FOX T2 Web Interface problem

After not using my PVR with the customised FW for close to 12 months , (it was still powered up and working), I've run into a problem with the web interface, when I attempt to connect to it all I get is the top banner displayed with the disk chart and VFR display and nothing else the actual page...
hummy.tv hummy.tv

If you try them please post back with each result then others will know what does not work for you and hopefully which one did work.
 
Oh dear! It looks like the whole base database might have become corrupted.

Humax1# cat /var/log/webif-error.log
/mod/webif/lib/settings.class:63: Error: no such table: settings
in procedure 'header' called at file "/mod/webif/html/index.jim", line 8
at file "/mod/webif/lib/setup", line 96
at file "/mod/webif/html/lib/header.jim", line 44
at file "/mod/webif/html/lib/topbar.jim", line 35
in procedure '<reference.<setting>.00000000000000000002>' called at file "/mod/webif/include/toolbar.jim", line 5
in procedure 'settings notoolbar' called at file "/mod/lib/jim/oo.tcl", line 52 at file "/mod/lib/jim/oo.tcl", line 73
in procedure '<reference.<setting>.00000000000000000002>' called at file "/mod/webif/lib/settings.class", line 210
in procedure 'settings _nval_setting' called at file "/mod/lib/jim/oo.tcl", line 52 at file "/mod/lib/jim/oo.tcl", line 73
in procedure 'settings' called at file "/mod/webif/lib/settings.class", line 133 at file "/mod/webif/lib/settings.class", line 63
 
I guess you're on a back-level WebIf - what does opkg list-installed webif say?
Try this:
Code: 
humax# opkg update
humax# opkg upgrade webif
and see whether that helps.
 
I guess you'll have to rename the database and let it create a new one:
Code: 
humax# cd /mod/etc
humax# mv webif.db webif-old.db
Aaron-B said:
It looks like the whole base database might have become corrupted.
Click to expand...
@/df I thought you had code implemented to stop this crashing? Or was that just the queue database?
 
Thanks @prpr, the database rename has worked.

Once I access it, I get a disk diagnostic fault I don't think had been there previously. Might explain it?

1648488840438.png
 
Aaron-B said:
Once I access it, I get a disk diagnostic fault I don't think had been there previously.
Click to expand...
That will only happen if you've gone through a fixdisk procedure in maintenance mode. There should be a log in /mnt/hd3 but it probably won't tell you much of use. Have you got any Pending/Uncorrectable sectors (197 and 198)?
Aaron-B said:
Might explain it?
Click to expand...
Dunno.
Can you zip and post/PM the corrupt .db file?
 
prpr said:
That will only happen if you've gone through a fixdisk procedure in maintenance mode. There should be a log in /mnt/hd3 but it probably won't tell you much of use. Have you got any Pending/Uncorrectable sectors (197 and 198)?

Dunno.
Can you zip and post/PM the corrupt .db file?
Click to expand...
1648489785737.png
 

Attachments

That appears to be a copy of the /mod/etc/rsck.db from the Remote Scheduling package. How it got turned into webif.db I have no idea.
It's still not very elegant to fail like that - the database existed, but the expected table didn't.
 
That's super strange! Well. Uh. Thanks for all your help @prpr, it's much appreciated. I'm currently running okay but will report back if anything further occurs!
 
As the needed table wasn't in the DB, the new retry code didn't really help. I hope that webif.db suddenly becoming linked to rsck.db is sufficiently rare failure mode that it doesn't need to be handled specially. The diagnostic was absolutely correct.
 
It would be nice if it could recreate the table if it doesn't exist though (in the same way it (re-)creates the database if it doesn't exist), rather than just abending. It's a bit of a brutal state to leave a hapless user in, wouldn't you say?
 
Last edited:
That ought to be possible. It was hard to imagine that the routine in settings.class would be presented with a valid DB that didn't contain the required table.

For instance, like this:
Code: 
diff --git a/webif/lib/settings.class b/webif/lib/settings.class
index 59b35ef..c900909 100644
--- a/webif/lib/settings.class
+++ b/webif/lib/settings.class
@@ -2,18 +2,31 @@
 if {![exists -command class]} { package require oo }
 if {![exists -command sqlite3.open]} { package require sqlite3 }
 
-if {![file exists /mod/etc/webif.db]} {
-     set ::settingsdb [sqlite3.open /mod/etc/webif.db]
+proc {settings _create} {} {
+     global settingsdb
      catch {
-             $::settingsdb query {
+             $settingsdb query {
                      CREATE TABLE settings(name text, nval int, tval text);
              }
-             $::settingsdb query {
+             $settingsdb query {
                      CREATE UNIQUE INDEX key on settings(name);
              }
      }
+}
+
+if {![file exists /mod/etc/webif.db]} {
+     set ::settingsdb [sqlite3.open /mod/etc/webif.db]
+     settings _create
 } else {
      set ::settingsdb [sqlite3.open /mod/etc/webif.db]
+     try {
+             # force use of index (SQLite3 extension) for validation
+             $::settingsdb query {
+                     select name, nval, tval from settings indexed by key where name = '';
+             }
+     } on error {msg opts} {
+             settings _create
+     }
 }
 
 class settings {
 
Last edited:
Hi

I have the exact same problem as Aaron-B.
I tried the 'fixweb' option from Telnet Menu and got this:

Removing package webif from root...
Installing webif (1.4.9-6) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/webif_1.4.9-6_mipsel.opk.
Configuring webif.
/mod/bin/jimsh: can't load library 'libcrypto.so.1.1'
/mod/bin/jimsh: can't load library 'libcrypto.so.1.1'

Should I rename the the database? This shouldn't cause any issues I presume?

Steve
 
Black Hole said:
The missing libcrypto indicates you have a worse corruption. You can try fiddling around to reinstate it as per /df's post above, or go straight for the n
Click to expand...

I tried the various fixes in /df's post but not sure I did them all and in the right order!
Unfortunately I still get the fixweb libcrypto error and now even 'stat' gives me '/mod/bin/jimsh: can't load library 'libcrypto.so.1.1''.
Also cannot get any webif access now, so I seem to have made matters worse!

What does the nuclear option do?

Is it 'https://wiki.hummy.tv/wiki/Remove_Modified_Firmware' > 'Reset the Custom Firmware Environment when the Web Interface is broken'?
 
Last edited:
You must log in or register to reply here.
Back
Top