Owen Smith
Well-Known Member
Is there a way I can get the previous version of webif? I'm updating my parents' box and after this weekend I won't have sight of it until July. I don't really like taking a major new feature like this.
[webif] Web Interface 1.3.4
- Thread starter af123
- Start date
peterworks
Ye Olde Bowler
Unfortunately this has not worked - DLNA status is still 0 when auto processing starts a couple of minutes after the first start up of the day. It is fine for start ups for the rest of the day.
OP
Yes, the defaults should provide pretty much the same experience as before. The only difference is that instead of starting at specific times (5, 25 and 45 minutes past each hour) it will run at three minutes after boot and then every 20 minutes thereafter with the default settings.
That's a bug - I'll fix it in -11, thanks.
OP
It must be taking longer than three minutes for startup then, assuming the box is really fully awake. I'll add some more tests and logging around this to try and get to the bottom of it.
OP
Yes, unfortunately it isn't as straightforward as it should be with the version of opkg we have.
Code:
humax# cd /mod/tmp
humax# wget -Up http://hpkg.tv/hdrfoxt2/base/webif_1.3.3-3_mipsel.opk
humax# opkg install --force-reinstall webif_1.3.3-3_mipsel.opk --force-downgrade
No packages removed.
Downgrading webif on root from 1.3.4-10 to 1.3.3-3...
Removing obsolete file /mod/webif/lib/queue.class.
... elided ...
OP
Version -11 has more debugging around this and will also allow an additional two minutes for the server to start up.
Code:
30/12/2016 11:50:34 - DLNA Server is NOT running.
30/12/2016 11:50:34 - Giving DLNA more time to start...
30/12/2016 11:50:44 - DLNA Server is running.
30/12/2016 11:50:44 - Auto processing starting, DLNA server status: 1Let's see if this tells us anything. It will be available in the repository shortly.
Make sure you set the log level to debug.
Owen Smith
Well-Known Member
That's done the trick, thanks.
Obviously I can't run fix-flash-packages or it will upgrade it again. I'm in the habit of always running fix-flash-packages after a reboot at the end of doing any updates, because to be honest I've never understood when it is required and when not.
OP
You can lock the package version:
which should prevent it being updated.
Not sure if it will help with fix-flash-packages though and can't easily test here at the moment.
fix-flash-packages is only needed if a flash-based package has been disabled due to two crashes in quick succession or if you've formatted the flash in some way (such as installing the system flush update file). It shouldn't be generally needed.
Code:
humax# opkg flag hold webifwhich should prevent it being updated.
Not sure if it will help with fix-flash-packages though and can't easily test here at the moment.
fix-flash-packages is only needed if a flash-based package has been disabled due to two crashes in quick succession or if you've formatted the flash in some way (such as installing the system flush update file). It shouldn't be generally needed.
peterworks
Ye Olde Bowler
Tks af - worked as I had hoped overnight...
peterworks
Ye Olde Bowler
I'm with Trev here.
As far as I can ascertain it is an integral part of WebIf rather than an installable package, though, of course, I could be wrong. As this means that anyone with the latest version of WebIf has it I think it should be left so that there is no difference between the 'before' and 'after' excepting that it runs every 20 minutes after start up rather than a fixed time (5/25/45 minutes past the hour). Should someone want to use it then they would need to access settings. They would then see and, if desired, change the options.
As far as I can ascertain it is an integral part of WebIf rather than an installable package, though, of course, I could be wrong. As this means that anyone with the latest version of WebIf has it I think it should be left so that there is no difference between the 'before' and 'after' excepting that it runs every 20 minutes after start up rather than a fixed time (5/25/45 minutes past the hour). Should someone want to use it then they would need to access settings. They would then see and, if desired, change the options.
Last edited:
Last.To.Know
Member
Is there a way to turn this pop-up off?The second feature is a new background processing queue. Things can be added to the queue through a new pop-up overlay in the file browser screen:
I'm mouseover-ing to see which episodes I wish to delete and it keeps getting in the way!
peterworks
Ye Olde Bowler
You can drag it out of the way...
Last.To.Know
Member
Or it could not get in the way in the first place.
It gets a bit tedious after the 8th time.
There are Delete buttons at the foot of the page as it is.
Why not make changes there?
MymsMan
Ad detector
It does seem inconsistent to have the Delete button in the new pop up but not the Cut/Copy/Join buttons.
It would be better if it floated above the file just selected and a bit to the right since most people work down lists rather that up and that way it wouldn't cover up the next files to be selected.
However I would be quite happy with a static Queue button at the bottom of the list with the existing buttons, I don't think Dequeue is needed since that can be accomplished from the queue view.
MymsMan
Ad detector
Normally I favour maintaining the status quo but it could be argued that suspending auto processing during recording is the safer option and those that want to 'risk' possible interference with active recording should have to actively choose to allow auto processing during recordings.
I don't have strong feelings either way.
prpr
Well-Known Member
Because it (potentially) improves the operational reliability of recordings, which is the fundamental purpose of the box.
The 'addition' is the auto-processing itself, which is currently enabled all the time by default. Compare this with the non-CF box which obviously never does any auto processing.
I was thinking the middle ground (auto processing when not recording or about to) would be the more preferable default.
I think you've actually just agreed with me, although you probably thought you were disagreeing!
Trev
The Dumb One
I think that you are right
I'll expand on my "Why". Although I have been trying to follow the reasons for delaying the start of some functions, and obviously failed, what is actually wrong with the current method. What problems does it create? As I have not noticed anything wrong with the way that it works at the moment apart from the occasional big "Failed to decrypt" red banners on the WebIF, which has been mentioned previously along with a possible fix. I suppose that the delay will take some loading off the box, but is this a problem anyway? How will that affect detectads in chaseget?