[webif] Web Interface 1.2.x

What's odd is that I'm seeing something similar, but it recovers by itself.

i.e. the pkg upgrade box comes up, and just sits there indefinitely. But I can manually close it, no errors, and things then seem to be fine. I don't need to reboot, nor restart lighttpd.

Perhaps I'm just seeing what af123 referred to as "the download issue"?
 
It seems that installing, or upgrading packages is causing lighttpd to stop running.
Indeed, but not on any of my boxes : (
Would one of you with the problem try running a full update/upgrade from the command line? That might show something.

Code:
humax# opkg update
humax# opkg upgrade

and try this command please:

Code:
humax# grep lighttpd /mod/var/opkg/info/*.p*

(That's <star><dot>p<star>)

Thanks.
 
Here is the output.
Code:
Humax3# opkg update
Downloading http://hpkg.tv/hdrfoxt2/base/Packages.gz.
Inflating http://hpkg.tv/hdrfoxt2/base/Packages.gz.
Updated list of available packages in /mod/var/opkg/base.
Humax3# opkg upgrade
Configuring lighttpd.
Configuring webif.
SMART: (PASSED)
startstop: 5488
realloc: 0
hours: 7017
spinretry: 0
pending: 0
offline: 0
Configuring libutil.
Configuring webshell.
Humax3# grep lighttpd /mod/var/opkg/info/*.p*
/mod/var/opkg/info/lighttpd.postinst:   /mod/etc/init.d/S01lighttpd stop
/mod/var/opkg/info/lighttpd.postinst:   /mod/etc/init.d/S01lighttpd start
/mod/var/opkg/info/lighttpd.prerm:/mod/etc/init.d/S01lighttpd stop
Humax3#
 
Code:
humax# opkg update
Downloading http://hpkg.tv/hdrfoxt2/base/Packages.gz.
Inflating http://hpkg.tv/hdrfoxt2/base/Packages.gz.
Updated list of available packages in /mod/var/opkg/base.
humax# opkg upgrade
Configuring lighttpd.
Configuring webif.
SMART: (PASSED)
startstop: 11964
realloc: 0
hours: 12964
spinretry: 0
pending: 0
offline: 0
Configuring tunefix.
Configuring bash.
Configuring sweeper.
Current Sweeper schema: 2
humax# grep lighttpd /mod/var/opkg/info/*.p*
/mod/var/opkg/info/lighttpd.postinst:   /mod/etc/init.d/S01lighttpd stop
/mod/var/opkg/info/lighttpd.postinst:   /mod/etc/init.d/S01lighttpd start
/mod/var/opkg/info/lighttpd.prerm:/mod/etc/init.d/S01lighttpd stop
humax#

I have just uninstalled bash and reinstalled it without any problem. So, it seems that update/upgrade may have solved the problem.
In retrospect, I wonder if running the grep first may have revealed something. However, even if it showed a problem, I guess that you still wouldn't know why it was wrong.

Thanks for the cure.
 
It looks like the configuration phase of a previous package upgrade wasn't completing, presumably because the web server that was invoking it was shutting down while it was running. It doesn't look like the grep would have revealed anything interesting.
 
Speculation

The upgrade of lightpd probably required a required a restart of the webserver which would not be good news if you are running the installation from the webserver

Does lightpd need special casing in the install to delay the restart until it is safe to do so?
 
Perhaps I'm just seeing what af123 referred to as "the download issue"?
Yes, I suspect so. The download issue appears to be related to RFC1323 TCP window scaling in the Linux 2.6.18 kernel that the Humax uses.
Certainly with this disabled I have been successfully downloading the web interface package continuously for 30 minutes now whereas previously it would usually hang within a few attempts.
 
Last edited:
cdmackay and anyone else who has noticed slow package downloads - try installing the new tcpfix package. Hopefully this will improve things for you. If so, it will be the default in CFW 3.10!
 
So that I can try the post #222 bits and bobs, can someone please remind me how to telnet into my box. I have the Windows telnet client running on my computer.
 
Yes, thanks. I looked at that but it effectively says use PUTTY. Can't I just use the telnet client.
Had a look at the MAC bit for clues. From the Microsoft Telnet prompt I typed 'telnet 192.168.0.6' and got invalid command.
OK Got into it. I suppose I need the cli option?
 
Last edited:
What Telnet client? Windows 7 Home doesn't have one as standard, although Win98 did, and I don't know about Win10. It is downloadable as an exe though, and I start it by typing "telnet" in the search bar.

Different clients have different mechanisms for opening a connection - some store a directory of connections you have used before. Telnet.exe doesn't, every time you need to open a connection you just type "o" (for "open") followed by the IP address.
 
Could the "Disk Diagnostics" and "Disk Space" utilities on the Diag. page be enabled for the HD please (at least if there is a disk connected)?
They work fine if you try editing the URL directly.
 
cdmackay and anyone else who has noticed slow package downloads - try installing the new tcpfix package. Hopefully this will improve things for you. If so, it will be the default in CFW 3.10!

I've installed this as I had some issues with package installation, but I haven't had to update or install anything yet so can't comment on it's effectiveness.

Browsing the Humax Media Files seems faster though as do searches on the EPG, I don't know if tcpfix could affect these or if it's my imagination.
 
Thanks BH.
What Telnet client? Windows 7 Home doesn't have one as standard, although Win98 did, and I don't know about Win10.
W7 does if you enable it in Control Panel ~ Programs and Features ~ Turn Windows features on or off. Just tick telnet and OK your way out.
It is downloadable as an exe though, and I start it by typing "telnet" in the search bar.
It's already there without a download in W7 Home and W 10 Pro/Home once enabled. Just done itin both my W10 machines;
Anyway, back to fixing my T2:)
Just done post#222. Now fixed. Thanks af:cheers:
 
Sorry, memory glitch. I knew you had to do something to get it, and assumed it was a download. Regardless, I just select telnet.exe by typing "telnet" in the search.
 
Yes. I knew how to get telnet running, it was the "Where do I go from here?" once I have the telnet screen open that I was having the problem with;) And the solution was just 'Open FoxT2' followed by '0000' followed by the 'cli' command. Simples when you know how, ain't it?
 
Yeah, it's the old-school command interface that catches the unwary grown too accustomed to GUI-everything. Before one of AF's magic tweaks it was necessary to issue a command to change the line end handling too.

I've never tried a symbolic name (which has to be resolved somewhere), I just use the IP address raw (my network numbering scheme makes it easy to remember: 192.168.1.x where x is 1- for an HDR and 2- for an HD, then 1,2,3,4 as appropriate).
 
Back
Top