Beta [webif] 1.4.9-6

Status
Not open for further replies.
I tried running it from /mod rather than /mod/webif and it appears to have worked:

H2# cd /mod
H2# wget -O- 'https://git.hpkg.tv/hummypkg/webif/pulls/46.diff' | patch -p1
--2021-06-29 14:30:30-- https://git.hpkg.tv/hummypkg/webif/pulls/46.diff
Resolving git.hpkg.tv... 2a00:5600:1600::50, 89.248.55.75
Connecting to git.hpkg.tv|2a00:5600:1600::50|:443... failed: Address family not supported by protocol.
Connecting to git.hpkg.tv|89.248.55.75|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 779 [text/plain]
Saving to: 'STDOUT'

- 100%[===================>] 779 --.-KB/s in 0s

patching file webif/lib/queue.class
2021-06-29 14:30:32 (9.91 MB/s) - written to stdout [779/779]

H2#
 
Strange, I thought I'd posted amended instructions (as well as amending the original ones), but you got the idea anyway!
 
@/df you had updated the instructions but I did not refer to them after you had done that. I saved the instructions to a text file for future reference.
Still all's well that ends well - thanks again
 
The 'queue' problem has returned on both my boxes. Set to delete after 7 days the queue now has entries going back to 28th July.
Any ideas please ? Anyone else seeing this ?

Edit: I have had a few crashes recently and, rightly or wrongly, run the fix-flash-packages diagnostic. I have a sneaking suspicion that the patch is being overwritten by this.
I will try reinstalling the patch and see what happens.
 
Last edited:
Have you reinstalled anything and thereby lost the patch?
What does the following produce? Different to mine (excluding timestamp)?
Code:
humax ~ # ls -l /mod/webif/lib/queue.class
-rw-r--r-- 1 root root 6363 Sun 30 May 2021 23:07:18 /mod/webif/lib/queue.class
humax ~ # grep "\[list" /mod/webif/lib/queue.class
        return [queue dbqueryl [list { {
        } } [list {
 
Thanks @prpr - I have rerun the patch and it is working fine again. Can only assume the fix-flash-diagnostics did it as I have done nothing else installation wise.
 
do it after a crash (rightly or wrongly) as I don't know what packages have been affected.
Just turn the disabling off: touch /mod/boot/no_plugin_autodisable
It won't stop the stupid message (that's probably worthy of another WebIf patch) but you can safely ignore it.
 
Here's a rollup of fixes since 1.4.9-6 (mostly from @/df and one or maybe two from me), as there seems to be no signs of anything coming down the normal beta channel.

Edit: See here for update.
 
Last edited:
Changelog or it didn't happen :)

It looks like these are the changes.

* Play file in browser or with external helper application

* Fix incorrectly constructed query list, restore purging completed entries

* Fixes and improvements for bookmark viewer

* Improve processing and display of custom encryption key

* Detect RO filesystems in disk check

* Improve translation of last boot reason (link?)

The package includes .orig versions of lib/system.class and lib/ts.class which might not have been intended.
 
Changelog or it didn't happen :)
:D

* Improve translation of last boot reason (link?)
Yes (IMHO). There isn't one.
The package includes .orig versions of lib/system.class and lib/ts.class which might not have been intended.
You're correct of course. I want to curse patch sometimes. I don't really see why it feels the need for trivial cases like this. It's a constant problem.
You missed another one - html/diag/queue/script.js

Updated the links above to make it 1.4.9-6c
 
...
You're correct of course. I want to curse patch sometimes. I don't really see why it feels the need for trivial cases like this. It's a constant problem.
find webif-1.4.9-6b -type f -name '*.orig' -exec rm -f {} \; -print
You missed another one - html/diag/queue/script.js
...
This seems to be in the master branch that I thought was the basis of 1.4.9-6, even though the files are dated May 28 which is a month later than the last commit.
Code:
# git status
On branch master
Your branch is up to date with 'origin/master'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
...
nothing added to commit but untracked files present (use "git add" to track)
humax# ls -l webif/html/diag/queue
total 24
-rwx------ 1 root root 1641 Nov 14  2020 fetch.jim
-rwx------ 1 root root 1658 May 28 15:26 index.jim
-rw------- 1 root root 4669 May 28 15:26 script.js
-rw------- 1 root root  612 May 28 15:20 style.css
-rwx------ 1 root root  341 Nov 14  2020 update.jim
# ls -l webif_1.4.9-6b_mipsel/webif/html/diag/queue
total 32
-rwxr-xr-x 1 root root 1641 Jan 19  2017 fetch.jim
-rwx------ 1 root root 1658 Feb 24  2021 index.jim
-rw-r--r-- 1 root root 4669 Feb 24  2021 script.js
-rw-r--r-- 1 root root 4263 Feb 24  2021 script.js.orig
-rw-r--r-- 1 root root  612 Feb 24  2021 style.css
-rwx------ 1 root root  341 Jan  6  2017 update.jim
#
Am I meant to see "Select Pending" and "Select Failed" buttons (I didn't, even when I had a Pending entry)?
 
find webif-1.4.9-6b -type f -name '*.orig' -exec rm -f {} \; -print
I know, although I used a simpler version :)
This seems to be in the master branch that I thought was the basis of 1.4.9-6,
I guess af123 has the same hassles with patch then.
even though the files are dated May 28 which is a month later than the last commit.
My script.js (in 1.4.9-6c) is dated Feb 24 (like in 1.4.9-6), so that appears to be your problem!
Am I meant to see "Select Pending" and "Select Failed" buttons (I didn't, even when I had a Pending entry)?
Yes.
 
Here's a rollup of fixes since 1.4.9-6 (mostly from @/df and one or maybe two from me), as there seems to be no signs of anything coming down the normal beta channel.
You can install as follows from the command prompt (or Webshell etc.):
Code:
humax# cd /tmp
humax# wget https://dl.dropbox.com/s/l9r7a5xad43nmz9/webif_1.4.9-6c_mipsel.opk
humax# opkg install webif_1.4.9-6c_mipsel.opk
I installed 1.4.9-6c and experienced some strange failures.

While recording and watching live TV picture breaks up with black screen (though sound continues) initially for a couple of seconds, but length of black picture increases until eventually machine lock up requiring rear switch to reboot.
This occurred three times in a row until I backed out to 1.4.9-6 - no problems since them

I have never seen that type of failure before and have no ideas how the webif changes could cause problems with live TV viewing

I will try again but not until I can experiment with test recordings.
 
Last edited:
Unfortunately the most plausible explanation is that the update is DoSing the box, an infinite recursion or similar.
 
Thanks @prpr & @/df for the ongoing development. I installed this webif on my boxes with no problem.

However my main box reported a crash so I ran fix-flash-packages, as I normally would, but also because the queue had failures as unable to find DLNA helper.

The dialogue box showed a not found error installing webif 1.4.9-6d.

Closing the dialogue and clicking on an icon goes to the index of/ screen.

A reboot goes to the install web interface screen.

Installation fails looking for webif 1.4.9-6d

I have managed to reinstall webif from the dropbox version as before.

I am working again, but wonder if a longer term solution is needed. Perhaps fix-flash-packages and install web interface on CF & telnet should default to the last version in the repository, or possibly to the Dropbox version if not found in repository.

If this becomes an ongoing issue, how can I revert back to the repository version?
 
Installation fails looking for webif 1.4.9-6d
It would, for the reasons you've thought.

If this becomes an ongoing issue, how can I revert back to the repository version?
Based on this post, the following restores 1.4.9-6:
Code:
cd /mod/tmp
wget -U '' http://hpkg.tv/hdrfoxt2/base/webif_1.4.9-6_mipsel.opk
opkg --force-downgrade --force-depends install webif_1.4.9-6_mipsel.opk
rm webif_1.4.9-6_mipsel.opk

Perhaps fix-flash-packages and install web interface on CF & telnet should default to the last version in the repository
That sounds like a good idea, but will require more non-repository modifications! Chicken and egg. A work-around would be for you to disable package disabling, making fix-flash-packages redundant:
Run the diagnostic called plugin_autodisable/off
...following which you will still get the WebIF message if there was a crash immediately after boot, but nothing will have been disabled to need fix-flash-packages.
 
Status
Not open for further replies.
Back
Top