Beta [webif] Web Interface 1.3.4 / Sweeper 2.1.4

Status
Not open for further replies.
I use detectads in in chaseplay mode. That works for me and having not used the new queuing mechanism, I can't comment on that.
 
af123 said:
What's the output of 'opkg list webif'? I would guess you get two lines with 1.3.3-3 on the second.
Click to expand...
Code: 
humax ~ # opkg list webif
webif - 1.3.3-3 - An evolving web interface for the Humax (beta).
webif - 1.3.4-9 - An evolving web interface for the Humax (beta).
 
Auto-processing suppression is working great for the way I use my Humax. I have suppressed it between 18:00 and 03:00 and, when the reminder (to cover the OTA) kicks in at 04:00, it does it's thing.
I have found, however, that the first run of auto-processing does nothing as shown below:
Code: 
4815   23/12/2016 03:58:18 - Auto processing completed in 16.066 seconds.
4814   23/12/2016 03:58:18 - expire scan completed in 2.575 seconds.
4813   23/12/2016 03:58:15 - expire scan starting.
4812   23/12/2016 03:58:15 - mp3 scan completed in 2.482 seconds.
4811   23/12/2016 03:58:13 - mp3 scan starting.
4810   23/12/2016 03:58:13 - mpg scan completed in 2.477 seconds.
4809   23/12/2016 03:58:10 - mpg scan starting.
4808   23/12/2016 03:58:10 - shrink scan completed in 2.509 seconds.
4807   23/12/2016 03:58:08 - shrink scan starting.
4806   23/12/2016 03:58:08 - dedup scan completed in 2.406 seconds.
4805   23/12/2016 03:58:05 - dedup scan starting.
4804   23/12/2016 03:58:05 - decrypt scan completed in 3.456 seconds.
4803   23/12/2016 03:58:02 - decrypt scan starting.
4802   23/12/2016 03:58:02 - Auto processing starting, DLNA server status: 0
4801   23/12/2016 03:58:02 - -------------------------------------------------------
4800   23/12/2016 03:58:02 - Registered ::sweeper::scansingledir for postdecryptsingledir hook with priority 50.
4799   23/12/2016 03:58:02 - Registered ::sweeper::scan for postdecryptscan hook with priority 50.
The second run 20 minutes later is fine.
Is it because the DLNA status is 0 ? I have set mod/boot/pox to turn it on at each boot but perhaps that is too late.
Asking to guild the lily slightly here but would it be possible to delay the initial auto-processing run by a couple of minutes ?
 
I am running the beta WebIf/Sweeper variants and have a question.

I really like that I can now delay the Auto-Processing of the recordings. My other half found it frustrating that the media folder practically ground to a halt as she was trawling through it as a new recording was being processed, so the ability to delay this is a welcome addition.

I have recursive Auto-Decrypt and Shrink set up at the top of the folder tree. Processing is delayed until the HDR turns on at 04:00 for an hour and works well, however, Sweeper no longer appears to be working.

To be honest, I find Sweeper the most complicated package to configure and have not altered it's settings for what seems like years. It's has one rule set and that is to move any 'one off' recordings less than 30 minutes old to the MISC folder. This keeps the base/root media folder relatively uncluttered.

Having just written the above, the 'penny has dropped'. Of course Sweeper hasn't run as the recording will be older than 30 minutes when processing starts as 04:00. DOH.

So, in answer, do you think that if I adjust the Sweeper file age condition of 'one-off' recordings from 30 minutes to, say 23 hours, it will work? I ask because I don't want Sweeper to file SERIES recordings into the Misc folder. They are moved into their own 'auto named' folder which is created when the first episode is recorded.

Ideally, I want Sweeper too run AFTER Auto-Decrypt and Shrink have run.

Merry Christmas!
 
Last edited:
Wallace said:
Ideally, I want Sweeper too run AFTER Auto-Decrypt and Shrink have run.
Click to expand...
Why would it matter? You have recurse switched on, so it will find the new recordings in the Misc folder anyway. Or am I missing something (not unusual for me)
 
To be honest, I'm not sure! My two 'grey-cells' banged together and thought that it might make a difference. :)
 
Update:

I temporarily altered the Auto-Processing time to allow me to experiment in daylight!

Setting the Sweeper rule to <= 23 hours appears to have worked. I set two recordings, one a series, the other a one-off. They both duly recorded, the series recording was filed straight into it's own folder (as expected), the one-off recording sat there waiting for the Auto-Processing window. Then, in that time window, was moved to the MISC folder and both recordings were processed. I.E decrypted and shrunk.

Sorry to answer my own question!
 
af123 said:
I have just uploaded this pair of packages to the beta repository. There are a couple of new features in here that could do with some wider testing before being rolled out.
[...]
Click to expand...

These worked largely as advertised until two days ago. Since then, on two HDRs, alll processing has stopped: nothing happens in folders marked for autodecrypt/autoextract and these options are greyed out in the opt+ menus. I tried queueing decrypt and extract, singly and together - View Queue quickly showed them as "Complete" but nothing was actually done. None of the files recorded sice the 24th shows the green "Dec" icon. In all cases, the recordings are radio or SD TV.

Any ideas?

Update: I do wish this board allowed deletion of posts to prevent me from displaying my ignorance for all to see. Bear in mind that I know almost nothing about *nix, little more about Windows networking, and not much more about the dependencies of the various components of the customised firmware. That's my excuse for turning off file sharing in the HDRs' native menus. I finally remembered that this was the only recent change, turned them on again and both HDRs are now behaving as normal.

DOH!
 
Last edited:
You can't delete, but you can edit to either correct stuff or change the whole post
to read posted in error. Anyway, you have said what your problem was and how you fixed it. Nothing embarrassing and might help others.
 
JoeBloggs911 said:
Update: I do wish this board allowed deletion of posts to prevent me from displaying my ignorance for all to see. Bear in mind that I know almost nothing about *nix, little more about Windows networking, and not much more about the dependencies of the various components of the customised firmware. That's my excuse for turning off file sharing in the HDRs' native menus. I finally remembered that this was the only recent change, turned them on again and both HDRs are now behaving as normal.

DOH!
Click to expand...
IIRC, the WebIF displays a warning if the DLNA server is disabled.
 
Status
Not open for further replies.
Back
Top