Beta [webif] Web Interface 1.3.4 / Sweeper 2.1.4

Status
Not open for further replies.
I've restructured the way that auto processing runs in webif 1.3.4-6.
It now kicks off every minute and quickly decides if it should do anything. Everything possible is deferred until after it makes that decision so it's very quick and doesn't even initialise the plugins if there's nothing to do (which will stop the log messages that Peterworks is seeing with log level 1).

Subject to the constraints configured in settings (whether to run while recording or about to record or within certain hours), it will always run if there is something in the queue that needs processing and otherwise if it has been X minutes since the end of the last run, where X is configurable in the settings panel.

Screenshot%202016-12-21%2013.04.46.png
 
I have updated WebIf to 1.3.4-6 and set the Auto-processing options in settings. I then turned off the Humax for 10 minutes using the remote. I am now getting the following every minute in the auto.log. Have I missed something ?

Code:
5000 21/12/2016 15:15:23 - Auto processing completed in 21.211 seconds.
4999 21/12/2016 15:15:23 - expire scan completed in 2.925 seconds.
4998 21/12/2016 15:15:20 - expire scan starting.
4997 21/12/2016 15:15:20 - mp3 scan completed in 2.702 seconds.
4996 21/12/2016 15:15:17 - mp3 scan starting.
4995 21/12/2016 15:15:17 - mpg scan completed in 2.834 seconds.
4994 21/12/2016 15:15:14 - mpg scan starting.
4993 21/12/2016 15:15:14 - shrink scan completed in 2.843 seconds.
4992 21/12/2016 15:15:11 - shrink scan starting.
4991 21/12/2016 15:15:11 - dedup scan completed in 2.651 seconds.
4990 21/12/2016 15:15:09 - dedup scan starting.
4989 21/12/2016 15:15:09 - decrypt scan completed in 7.114 seconds.
4988 21/12/2016 15:15:02 - decrypt scan starting.
4987 21/12/2016 15:15:02 - Auto processing starting, DLNA server status: 1
4986 21/12/2016 15:15:02 - -------------------------------------------------------
4985 21/12/2016 15:15:02 - Registered ::sweeper::scansingledir for postdecryptsingledir hook with priority 50.
4984 21/12/2016 15:15:02 - Registered ::sweeper::scan for postdecryptscan hook with priority 50.
4983 21/12/2016 15:15:01 - Registered ::newk::scan for postexpirescan hook with priority 50.
4982 21/12/2016 15:15:01 - Registered do_arbookmarks for postdecrypt hook with priority 50.
4981 21/12/2016 15:14:22 - Auto processing completed in 20.783 seconds.
4980 21/12/2016 15:14:22 - expire scan completed in 2.798 seconds.
4979 21/12/2016 15:14:19 - expire scan starting.
4978 21/12/2016 15:14:19 - mp3 scan completed in 2.64 seconds.
4977 21/12/2016 15:14:17 - mp3 scan starting.
4976 21/12/2016 15:14:17 - mpg scan completed in 2.838 seconds.
4975 21/12/2016 15:14:14 - mpg scan starting.
4974 21/12/2016 15:14:14 - shrink scan completed in 2.692 seconds.
4973 21/12/2016 15:14:11 - shrink scan starting.
4972 21/12/2016 15:14:11 - dedup scan completed in 2.669 seconds.
4971 21/12/2016 15:14:09 - dedup scan starting.
4970 21/12/2016 15:14:09 - decrypt scan completed in 7.021 seconds.
4969 21/12/2016 15:14:02 - decrypt scan starting.
4968 21/12/2016 15:14:02 - Auto processing starting, DLNA server status: 1
4967 21/12/2016 15:14:01 - -------------------------------------------------------
4966 21/12/2016 15:14:01 - Registered ::sweeper::scansingledir for postdecryptsingledir hook with priority 50.
4965 21/12/2016 15:14:01 - Registered ::sweeper::scan for postdecryptscan hook with priority 50.
4964 21/12/2016 15:14:01 - Registered ::newk::scan for postexpirescan hook with priority 50.
4963 21/12/2016 15:14:01 - Registered do_arbookmarks for postdecrypt hook with priority 50.
4962 21/12/2016 15:13:23 - Auto processing completed in 21.796 seconds.
4961 21/12/2016 15:13:23 - expire scan completed in 2.933 seconds.
4960 21/12/2016 15:13:20 - expire scan starting.
4959 21/12/2016 15:13:20 - mp3 scan completed in 2.764 seconds.
4958 21/12/2016 15:13:18 - mp3 scan starting.
4957 21/12/2016 15:13:18 - mpg scan completed in 2.828 seconds.
4956 21/12/2016 15:13:15 - mpg scan starting.
4955 21/12/2016 15:13:15 - shrink scan completed in 2.885 seconds.
4954 21/12/2016 15:13:12 - shrink scan starting.
4953 21/12/2016 15:13:12 - dedup scan completed in 2.813 seconds.
4952 21/12/2016 15:13:09 - dedup scan starting.
4951 21/12/2016 15:13:09 - decrypt scan completed in 7.413 seconds.
4950 21/12/2016 15:13:02 - decrypt scan starting.
4949 21/12/2016 15:13:02 - Auto processing starting, DLNA server status: 1
4948 21/12/2016 15:13:01 - -------------------------------------------------------
4947 21/12/2016 15:13:01 - Registered ::sweeper::scansingledir for postdecryptsingledir hook with priority 50.
4946 21/12/2016 15:13:01 - Registered ::sweeper::scan for postdecryptscan hook with priority 50.
4945 21/12/2016 15:13:01 - Registered ::newk::scan for postexpirescan hook with priority 50.
4944 21/12/2016 15:13:01 - Registered do_arbookmarks for postdecrypt hook with priority 50.

This has put my cpu usage to over 50 pct permanently
 
Last edited:
I've restructured the way that auto processing runs in webif 1.3.4-6.
It now kicks off every minute and quickly decides if it should do anything. Everything possible is deferred until after it makes that decision so it's very quick and doesn't even initialise the plugins if there's nothing to do (which will stop the log messages that Peterworks is seeing with log level 1).
Rather than a frequent chron job in DetectAds I decided to kick of a queue processing task at the the same time as adding to the queue and the infrequent chron task is only there as a fall back

Perhaps auto might need more restructuring to further separate the things triggered by the end of a recording from those that need to be done every so often
 
I have updated WebIf to 1.3.4-6 and set the Auto-processing options in settings. I then turned off the Humax for 10 minutes using the remote. I am now getting the following every minute in the auto.log. Have I missed something ?

Try clicking on the set button next to the process time interval. It might be reading it as zero until explicitly set.
 
I did try that but response was 'auto-processing frequency unchanged'
I changed it to 5 minutes and set it. That has worked fine.
Have now reset to 20 minutes and set it. Will monitor but I think you have answered this one...
 
Try clicking on the set button next to the process time interval. It might be reading it as zero until explicitly set.

I had the same experience as the OP on two T2s and also disabled processing. I tried your suggestion and it worked: CPU usage went back to normal even when processing was re-enabled.

However, all this farfing about seems to have broken something: all attempts to use the webif's "Browse" function produces a "500 - Internal Server Error" on both machines. Neither rebooting them nor restarting Firefox has helped. I Can still access native browsing with the remote, and also from the computerusing a file manager. All other webif functions work normally.
 
WebIf error log:
6 at file "/mod/webif/lib/setup", line 8
5 in procedure 'require' called at file "/mod/webif/html/browse/index.jim", line 5
4 /mod/webif/lib/setup:8: Error: couldn't read file "/mod/webif/lib/escape": No such file or directory
3 at file "/mod/webif/lib/setup", line 8
2 in procedure 'require' called at file "/mod/webif/html/browse/index.jim", line 5
1 /mod/webif/lib/setup:8: Error: couldn't read file "/mod/webif/lib/escape": No such file or directory
Page:
first.png
prev.png
Showing 1 - 6 / 6
next.png
last.png

lines
Rendered in: 0.046 seconds
 
What's in your webif-error.log?

at file "/mod/webif/lib/setup", line 8
19 in procedure 'require' called at file "/mod/webif/html/browse/index.jim", line 5
18 /mod/webif/lib/setup:8: Error: couldn't read file "/mod/webif/lib/escape": No such file or directory

Repeated for every attempt to use "Browse".
 
I did try that but response was 'auto-processing frequency unchanged'
I changed it to 5 minutes and set it. That has worked fine.
Have now reset to 20 minutes and set it. Will monitor but I think you have answered this one...
Working perfectly now
 
webif 1.3.4-8 now in the beta repository - fixes both problems (browse page and running too often).
 
The updated version of Webif - 1.3.4-8, it has solved the issue of "Browse" on my machines showing Error 500.

However the error is also found when using Flexview. From the webif log
Code:
3   at file "/mod/webif/lib/setup", line 8
2   in procedure 'require' called at file "/mod/webif/plugin/flexview/index.jim", line 4
1   /mod/webif/lib/setup:8: Error: couldn't read file "/mod/webif/lib/escape": No such file or directory

Which appears to be simlar to the problem with Browse.

Hopefully it will be easy to clear up.

Jay
 
I have auto update running and the activity log shows:
4581 22/12/2016 04:03:12 - Automatically upgraded package webif from 1.3.4-8 to 1.3.3-3
WebIf shows I am on 1.3.4-9
 
I have auto update running and the activity log shows:
4581 22/12/2016 04:03:12 - Automatically upgraded package webif from 1.3.4-8 to 1.3.3-3
WebIf shows I am on 1.3.4-9
It's just because you have two repositories at the moment - base and beta.
What's the output of 'opkg list webif'? I would guess you get two lines with 1.3.3-3 on the second.

I'll fix this in the package class for the future but you'll need two webif updates for it to work properly.
 
Thanks for testing this everyone. I've fixed all of the bugs I'm aware of now and plan to push it out to the main repository sometime tomorrow, all being well.

Nobody responded to one of MymsMan's queries:

One option available with DeteactAds that I don't see in the new support is a start time for processing. I felt it would be useful when queueing to be processed later to be able to say when later should be.
This is less important with Sweeper since you can use current time rules to control when items are added to the queue, but from Browse it would be nice to select a group of files and say process them after 01:00AM without having to go to settings to alter the Auto process time ranges first. DetectAds offers a choice of ASAP or a start time.
What do others think?

Any thoughts? This isn't something I would use but if it would be useful to others then I'll consider adding it.
 
Status
Not open for further replies.
Back
Top