[webif] Web Interface 1.3.4

af123

Administrator
Staff member
Web Interface 1.3.4 has now been released (it has been available for beta testing for a while and undergone several revisions so this first released version is 1.3.4-10).

There are two main changes in this version. The first is more control over when background auto-processing runs; this is configured through a new section in the settings screen.

Screenshot%202016-12-28%2008.30.01.png


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:

Screenshot%202016-12-28%2008.34.59.png


or through sweeper rules:

Screenshot%202016-12-17%2023.52.53.png


There are also new sweeper conditions for detecting whether something is already queued.

The queue itself can be viewed through Diagnostics -> Queued Tasks.
 
I've been watching this, but not participated in the beta due to constraints of time. I think it's another great improvement.

I have been thinking it would be nice to choose whether audio extraction is performed "Quick (MP3 Layer 2)" or "Full (MP3 Layer 3)" at the time of running the task (and now adding to the queue). The setting in Settings would remain as the default for auto-processing.
 
Loaded up new Webif this morning but although I have detectads package installed it doesn't appear in the background processing pop-up list (as Ad-Detection) and queued actions don't appear in Diagnostics -> Queued Tasks. Any thoughts as to why? I'm running firmware 3.03 not 3.10 at the moment.
 
I have been running the beta for a while now. I used 'update package list from the internet'. However, I am not being offered WebIf 1.3.4-10 or Sweeper 2.1.4-2. I did get epg 1.2.5 okay.
 
I suspect that because you were running the beta that you already have v 1.3.4-10 and 2.1.4-2.

Since it's now out of beta, I have removed the 'opkg-beta' package from my devices too.
 
I suspect that because you were running the beta that you already have v 1.3.4-10 and 2.1.4-2.
Since it's now out of beta, I have removed the 'opkg-beta' package from my devices too.
Tks but unfortunately that is not the case - I still have 1.3.4-9 and 2.1.4-1 respectively.
Would removing 'opkg-beta' help ? I presume should any new beta packages become available then we would be advised to install it again as necessary ?
 
I removed it as I was getting 'conflicting' package versions. For example, it said WebIf version 1.3.4-9 was available when I already had v1.3.4-10 installed.
This, I believe is normal as my boxes will be 'pointing' to the release repository as well as the beta repository. As the packages are out of beta, I decided to remove 'opkg-beta'.
 
Loaded up new Webif this morning but although I have detectads package installed it doesn't appear in the background processing pop-up list (as Ad-Detection) and queued actions don't appear in Diagnostics -> Queued Tasks. Any thoughts as to why? I'm running firmware 3.03 not 3.10 at the moment.
Af123 made some changes to DetectAds to test support for the new queueing mechanism but I haven't yet had time to look at them or update the package to incorporate them for everyone
 
Loaded up new Webif this morning but although I have detectads package installed it doesn't appear in the background processing pop-up list (as Ad-Detection) and queued actions don't appear in Diagnostics -> Queued Tasks. Any thoughts as to why? I'm running firmware 3.03 not 3.10 at the moment.

Sorry, my fault for causing confusion, I should have used different screenshots. DetectAds uses its own queuing system and I kind of dropped this new similar feature on MymsMan without much warning. I've updated my own local installation of DetectAds to integrate with the new queuing system alongside its own (hence the screenshots) but I don't know if that's what MymsMan wants to do long-term.

Af123 made some changes to DetectAds to test support for the new queueing mechanism but I haven't yet had time to look at them or update the package to incorporate them for everyone
 
Sorry, my fault for causing confusion, I should have used different screenshots. DetectAds uses its own queuing system and I kind of dropped this new similar feature on MymsMan without much warning. I've updated my own local installation of DetectAds to integrate with the new queuing system alongside its own (hence the screenshots) but I don't know if that's what MymsMan wants to do long-term.
I liked the idea of having just one processing queue for both detectads plus decrypt (for BBC channels), furthermore, the new queue seems to offer the type of job control that I was looking for; which would finally get me away from having to run the detectads rule manually when I know that the unit will have nothing else to do.
 
Following on from the Beta thread...
Quote from AF: Yes - it's running too early, before the DLNA server has started up. I've added a delay to wait until at least 3 minutes after boot which will be in the next version Unquote
Unfortunately DLNA is still not starting after the built in delay:

activity log:
4674 29/12/2016 03:57:27 - System booted (Scheduled event).

auto log:
920 29/12/2016 04:00:03 - decrypt scan starting.
4919 29/12/2016 04:00:03 - Auto processing starting, DLNA server status: 0
4918 29/12/2016 04:00:03 - -------------------------------------------------------
4917 29/12/2016 04:00:03 - Registered ::sweeper::scansingledir for postdecryptsingledir hook with priority 50.
4916 29/12/2016 04:00:03 - Registered ::sweeper::scan for postdecryptscan hook with priority 50.
4915 29/12/2016 04:00:03 - Registered ::newk::scan for postexpirescan hook with priority 50.
 
Following on from the Beta thread...
Quote from AF: Yes - it's running too early, before the DLNA server has started up. I've added a delay to wait until at least 3 minutes after boot which will be in the next version Unquote
Unfortunately DLNA is still not starting after the built in delay:

activity log:
4674 29/12/2016 03:57:27 - System booted (Scheduled event).

auto log:
920 29/12/2016 04:00:03 - decrypt scan starting.
4919 29/12/2016 04:00:03 - Auto processing starting, DLNA server status: 0
4918 29/12/2016 04:00:03 - -------------------------------------------------------
4917 29/12/2016 04:00:03 - Registered ::sweeper::scansingledir for postdecryptsingledir hook with priority 50.
4916 29/12/2016 04:00:03 - Registered ::sweeper::scan for postdecryptscan hook with priority 50.
4915 29/12/2016 04:00:03 - Registered ::newk::scan for postexpirescan hook with priority 50.
The DLNA server only starts up if the box is fully awake - it does not start if the box is only half-awake for a scheduled recording.

If you are deferring processing to an idle time it is best to schedule a Reminder to ensure the box is fully awake whilst processing.

Chaseget has some processing to wake the box fully up whilst recording and put it back to sleep again but I am not sure that would be appropriate for Auto processing.
 
Thanks MymsMan. I have set a reminder (for 1 hour) to cover the OTA and auto processing kicks off. However no processing is done as DLNA is 0. The next run after 20 minutes works fine.
af123 put in a 3 minute delay to allow DLNA to start but this seems to not be quite enough...
 
Thanks MymsMan. I have set a reminder (for 1 hour) to cover the OTA and auto processing kicks off. However no processing is done as DLNA is 0. The next run after 20 minutes works fine.
af123 put in a 3 minute delay to allow DLNA to start but this seems to not be quite enough...
That is strange, it is usually much faster than that (less than 1 minute) though af123's other half may not have forgiven me for putting their machine into a continuous Power off loop when it did take longer on one occasion ;)

You could try resetting the DLNA database in case something is slowing it down or perhaps move the Reminder to quarterf an hour before the OTA window starts in case there is any special case processing going on
 
I have reset the DLNA database (folders changed from 63 to 49) so fingers crossed. Will see how it gets on at start up of the day.
Not sure what you mean by move the Reminder. It is set from 04:00 to 05:00. If I set it 15 minutes earlier the auto process will surely start 3 minutes after the new time (?)
 
So if I've been happy with the previous scheduling behaviour, how do I continue to get that? Do the new defaults provide the same settings?
 
Back
Top