[webif] Web Interface 1.2.x

[af123]

webif 1.2.8-1 delivers a significant speed improvement to the package management screen - on my box the load time for each tab has dropped from 15 seconds to 1.

 

[cdmackay]

webif 1.2.8-1 delivers a significant speed improvement to the package management screen - on my box the load time for each tab has dropped from 15 seconds to 1.

blimey! yes it does, that's marvellous, thanks.

 

[prpr]

That's a mega-improvement. Why/how was it so inefficient before?

 

[Stummery]

Yep, in EXTRA.css you can reduce the icon sizes if you wish:

img.button { height: 50px; }

CSS is new to me. I have tried as you suggest but have found that though I can vary the width the height remains the same.

For example:

img.button {
    height: 50px;
    width: 50px; }

Would it also be possible to customise the webif front page layout to give a 5 column table instead of the 4 using the EXTRA.css file ?

 

[Ezra Pound]

af123 : webshell 1.0.2 should fix that although a reboot (or web server restart) will be required following installation..

Installed, rebooted, checked and removed using Web-If - Thanks webshell 1.0.2 works for me

 

[Black Hole]

CSS is new to me. I have tried as you suggest but have found that though I can vary the width the height remains the same.

For example:

img.button {
    height: 50px;
    width: 50px; }

Would it also be possible to customise the webif front page layout to give a 5 column table instead of the 4 using the EXTRA.css file ?

http://hummy.tv/forum/threads/extra-css-please-post-tweaks-here-with-screengrabs.6183/

 

[af123]

CSS is new to me. I have tried as you suggest but have found that though I can vary the width the height remains the same.

Try marking the height as important which should make it override the default. I'm not a fan of littering !important around but in this case it make sense.

img.button
{
        height: 50px !important;
        width: 50px;
}

Would it also be possible to customise the webif front page layout to give a 5 column table instead of the 4 using the EXTRA.css file ?

Unfortunately that would require a code change.

 

[af123]

That's a mega-improvement. Why/how was it so inefficient before?

The old version was written in a clean OO way using the pkg class so that the package display page didn't need to understand the packaging system internals. Once a list of packages was obtained it looped through and loaded an instance of the class for that package, so for example:

set pkg [pkg load webif]
puts "Package Description: [$pkg get descr]"
puts "Installed? [$pkg is installed]"

Good practice but increasingly slow as the number of packages increased, particularly since the class invokes the opkg utility to retrieve the information which results in a lot of fork/exec overhead. I don't generally use the web interface for package management so I haven't really noticed this before - it was fast enough at the start when there were only a few packages!

I've also optimised the way that the list of relevant packages is built and a few other bits and pieces. The time command in Jim is very useful for testing this. For example here's how it checks for the list of upgradable packages, old and new code (the initial population of the pkgdata list is done once per page anyway so I've excluded that from the time calculations).

#!/mod/bin/jimsh

source /mod/webif/lib/setup

require pkg.class

set pkgdata [pkg getall]

# Old method
puts [time {
        set upgr_pkgs {}
        foreach pkg [split [exec /bin/opkg list-upgradable] "\n"] {
                if {[regexp {^([^ ]+)} $pkg name] == 0} { continue }
                lappend upgr_pkgs $name
        }
    } 100]

# New method
puts [time {
        set upgr_pkgs {}
        foreach {pkg data} $pkgdata {
                if {$data(installed) ne "0" && \
                    $data(installed) ne $data(version) && \
                    [pkg vercompare $data(version) $data(installed)] == 1} {
                        lappend upgr_pkgs $pkg
                }
        }
    } 100]

Which gives:

552900 microseconds per iteration
15377 microseconds per iteration

 

[prpr]

I don't generally use the web interface for package management so I haven't really noticed this before

Me neither, because it was soooo damned slow.

Thanks for the comprehensive answer.

 

[Black Hole]

Okay, so previously it was implemented in a clean OO manner - what is it now: dirty? Or have you found a more efficient clean method?

 

[af123]

Okay, so previously it was implemented in a clean OO manner - what is it now: dirty? Or have you found a more efficient clean method?

It isn't bad but there is no longer the same clean API line between the screen code and the library, and there is now Jim code that has to understand the on-disk format used by the opkg toolset. The speed improvement is definitely worth is and there is only a very slim chance that I'd ever change the packaging system anyway...

 

[prpr]

The Maintenance mode page has a superfluous word: "Maintenance Mode allows you to start up your Humax into a mode where the neither the standard...". Strike the first "the". Not wild about "into" either. Just "in" reads better to my mind.

 

[Stummery]

Try marking the height as important which should make it override the default. I'm not a fan of littering !important around but in this case it make sense.

Thank you, adding the !important does exactly as I want and it no longer needs width.

img.button { height: 30px !important; }

 

[ian_j]

Just trying to update Webif from 1.2.8-2 to 1.2.8-3 via WebIF but it's been sat for around 5 minutes with the following screen:

 

[hairy_mutley]

I have been seeing just the same for all the updates of the last few days. Normally it finally brings up a plain white popup dialog saying "Internal Server Error"/"OK" over the dimmed web-page. Pressing OK just returns to the hung "Package Management Results" shown by ian_j. Any attempt to reconnect to the box returns a browser error page "Unable to connect". The box is still working normally, but only a reboot will bring the webif back.

Should have said... I can still ping it and access My Video over the network.

 

[MymsMan]

Updating the Webif package always seems very slow compared to other packages, and not just using the webif update screens.
I just updated via command line and it seemed to take forever - about 10 minutes since I wasn't watching closely but it did eventually complete

 

[Trev]

Same her. I close the results page, then cannot use the WI until I reboot the box. It's been like it for several days now since a previous WI update broke it.

 

[af123]

I know about the slow download issue (which we still can't pinpoint : () but nobody should be getting server errors any more.

 

[Trev]

Wrong.
Had three updates this morning. Updated to WI 1.2.8-3. After 90 sec, got 404 server error and no box access.
Reboot
Check. 1.2.8-3 installed. OK
Upgrade tunefix to 1.0.8-1. After 10 sec got 404
Reboot
Check 1.0.8-1. OK
So I got server error twice, with associated reboots.

 

[AJones]

1.2.8 appears to have fixed all of the issues I have had recently.

Many thanks af123

I'm still getting the internal server error problem post 1.2.8 - the latest when updating from 1.2.8-2 to 1.2.8-3. As described in #163, the web interface then doesn't work until I reboot the Humax, but then the update appears to have completed. I'm not sure, but I think it's been doing this since the lightpd update and was wondering if I'd corrupted something.

Is there something I can do to fix this? I'm using Microsoft Edge on Windows 10 if it makes a difference.

Thanks.