The check for updates immediately before the update took the usual couple of seconds. Just timed it and it's now 190 seconds.You're right, it does seem slow - but that could be at the server end.
8 at file "/mod/webif/lib/pkg.class", line 228
7 in procedure 'pkg' called at file "/mod/webif/lib/pkg.class", line 248
6 in procedure 'pkg' called at file "/mod/webif/cgi-bin/opkg.jim", line 73
5 /mod/webif/lib/pkg.class:228: Error: hpkg.tv:http: connect: Connection timed out
4 at file "/mod/webif/lib/pkg.class", line 228
3 in procedure 'pkg' called at file "/mod/webif/lib/pkg.class", line 248
2 in procedure 'pkg' called at file "/mod/webif/cgi-bin/opkg.jim", line 73
1 /mod/webif/lib/pkg.class:228: Error: hpkg.tv:http: connect: Connection timed out
Same as here. And I'm off to bed.Yes, Timesouts
Interesting.Any messages in webif-error.log?
1 /mod/webif/lib/pkg.class:228: Error: hpkg.tv:http: connect: Connection timed out[/CODE]
humax ~ # jimsh
Welcome to Jim version 0.80
. socket stream hpkg.tv:80
Not a valid address: hpkg.tv:80
[error] . socket stream hpkg.tv:http
::aio.sock4
.
HDRFOX1# jimsh
Welcome to Jim version 0.79
. socket stream hpkg.tv:80
::aio.sock4
. socket stream hpkg.tv:http
A bit of hand-holding here please - what does one do with that and what effect does it have?Here's how to fix it...
Enterwhat does one do with that and what effect does it have?
sed -i "s/:http/:80/" /mod/webif/lib/pkg.class
on the command line, obtained via Telnet or (with webshell installed) WebIf >> Diagnostics >> Command Line.Yes, I figured that out once I'd woken up. I'm not a Linux person but the 's/this/that' construction has been used on Cix for as long as I can remember to correct a posting.Enter...
Funny thing is I had an 'Is this a good idea?' moment before updating last night. Crippling updates would be a bad thing.I've got four machines to do - I'll wait for the movie to come out... or is there a Catch 22 here - has this crippled updates?
The whole point of being beta testers is to catch things like this. We have to be willing to take risks, and report what we find (even if some of us poke it less than others). WebIF 1.4.9-1 is only available to those signed up as beta package testers (by installing opkg-beta - see https://hummy.tv/forum/threads/beta-participation.7785/).Funny thing is I had an 'Is this a good idea?' moment before updating last night.
Yes, I realise this - I used to be a beta tester on some OLR software many years back.The whole point of being beta testers is to catch things like this.
Because I'm running a new build. Something is different between 0.79 and 0.80 (or the builds thereof) which has upset this. I can't see what it is looking at the source code, but 0.79 definitely seems broken somehow to me as using the :http version should generate an error earlier in the process - it doesn't and tries to connect to port 0 on the web server anyway, which is what eventually causes the timeout error.Why am I showing a different Jim version?
It's copy once and paste four times. Do them all in less than a minute. Even easier if you use ssh (from a Linux or W10 machine) rather than telnet as you can put it all on the command line (you need to have set up dropbear properly first though, but well worth doing) and repeat for each machine.I've got four machines to do
I don't think so. Even so, you could dohas this crippled updates?
opkg update
from the command line, followed by the GUI Upgrades tab, avoiding the "Check for updates" button. But if you were doing the former, you might as well do opkg upgrade
whilst you were there.Yes, no doubt, but somebody needs to test the roll-out which corrects the bug. If it's no major inconvenience, there's no emergency.It's copy once and paste four times. Do them all in less than a minute.
I have used this command to fix both boxes that had the issue.Here's how to fix it:
Sorry. That one's my fault.Code:humax# sed -i "s/:http/:80/" /mod/webif/lib/pkg.class