[webif] Web Interface 1.4.x

Status
Not open for further replies.
I have quite a lot of folders and single recordings and it's a pain trying to find last night's Coro for HWMBO.:laugh:
 
Use sweeper to collect them all in the same place, and put the folder at the top of the list by starting the folder name with a space!
 
Trev said:
But will that affect the SUI as that's what I use day to day?
Click to expand...
Yes, the collection folder will appear at the top of the SUI list above your series folders.
So an extra click to get into it but all of your one off's will appear together
All my granddaughters childrens programs are grouped together in the ' Molly' folder

Recordings in progress and newly completed recordings of course won't be in the collected folder until Sweeper next runs.
Moving recordings can cause failures with queued actions such as decrypt and detectads because they are no longer where the queue entries expect them to be.
 
Last edited:
It is and I now see what you are getting at, thanks. But I don't like MM's statement, esp. detectads in chaseget mode.
MymsMan said:
Moving recordings can cause failures with queued actions such as decrypt and detectads because they are no longer where the queue entries expect them to be.
Click to expand...
 
Trev said:
It is and I now see what you are getting at, thanks. But I don't like MM's statement, esp. detectads in chaseget mode.
Click to expand...
It is traditional post-recording mode that could be affected and it isn't fatal the recordings can still be decrypted/ad detected in the new location if the folder is flagged for auto-decryption - it is just that you may see a few failure notifications in the Q display.
Renaming files to remove New prefixes has similar affects
 
MymsMan said:
It is traditional post-recording mode that could be affected and it isn't fatal the recordings can still be decrypted/ad detected in the new location if the folder is flagged for auto-decryption - it is just that you may see a few failure notifications in the Q display.
Renaming files to remove New prefixes has similar affects
Click to expand...
I have auto decrypt flagged at the video root with recuse and run detectads in chaseget mode. Does this make a difference?
 
Trev said:
I have auto decrypt flagged at the video root with recuse and run detectads in chaseget mode. Does this make a difference?
Click to expand...
It should be fine, the order of events within Auto processing was designed to minimize problems with renaming/moving files - it might take a few minute more before decryption happens
 
Will this do what BH suggested. Move all 'loose' files into folder called !Videos (the one at the bottom of the window.)
Code: 
# Remove Title New: prefix
recurse 1 title New: action {settitle {%orig%replace,New: ,,}}
# Remove Filename New: prefix
recurse 1 filename New_ action {renamefile {%orig%replace,New_ ,,}}
# File Datestamp DD MMM YY
recurse 1 filename *20[0-9][0-9][0-9][0-9][0-9][0-9]_* action {renamefile {%title %2digitdate-%2digitmonth-%2digityear %hhmm}}
# Remove "_" in Title
recurse 1 title _ action {settitle %orig%replace,_,,}
# Remove "_" in Filename
recurse 1 filename _ action {renamefile {%orig%replace,_, ,}}
# Remove Title "The " prefix
recurse 1 title {The *} action {settitle {%orig%replace,The ,,}}
# Remove "The " in Filename
recurse 1 filename {The *} action {renamefile {%orig%replace,The ,,}}
# Thumbnails post detectads
recurse 1 and {!fileexists %basename.thm flag Addetection } action {queue {thumb -offset 5}}

#MoveFilesOutOfRoot
filename * action {move !Videos}
in my sweeper rules? Just want to move recordings in video root.
 
The rule I use for putting anything in the root MyVideo into a catch-all folder is:
Code: 
# Move any one-off or flattened recordings into folder [Unclassified]
action {movecreate [Unclassified]}
This was the origins of sweeper, dating back to 2013.
 
af123 said:
Web Interface version 1.4.0 has now been released along with a number of updated plugins to go with it.

I'd like to extend my thanks to MymsMan for being instrumental in inspiring the massive improvement this version brings to automatic processing and for his help with design and testing.

Thanks also to the people who helped with beta testing these changes (Black Hole, jaybr, peterworks, prpr, Trev, Wallace, and anyone else who downloaded and tested the beta)

1.4.0 Release Notes.

New:
  • Complete overhaul of the background auto-processing system thanks to inspiration and help from MymsMan;
    • Its work has been split into two separate tasks - media scanner and queue runner;
    • The media scanner adds jobs to the queue rather than processing them as it runs. This makes its run-time shorter and more predictable. It still performs fairly quick actions such as expire and de-duplication in-line;
    • Rather than scanning the recording tree once for each action (decrypt, dedup, shrink, etc.), the new media scanner scans the recording hierarchy just once per run. This change alone has halved the run-time (although it depends on the directory structure to some extent);
    • The default automatic processing scan interval has been changed from every 20 minutes to every 10;
    • Most existing automatic processing plugins (sweeper,flatten,flatview,newk) will work unchanged with the new system but updates are available so that they can take advantage of the new framework;
    • The badnts,arbookmarks and detectads (if using post-decrypt mode) plugins will not work properly and must be upgraded;
    • The web interface built-in actions (decrypt, shrink, etc.) are now implemented as plugins, just like any other extension package;
    • Background automatic tasks such as decryption and shrink now appear in the queue;
  • The queue diagnostic screen has been updated:
    • Shows more information about tasks;
    • Allow a task to be manually put on hold or re-submitted to the queue;
    • Provide links back to the media browser for each queue entry;
  • A link to the queue screen can be added to the main menu and toolbar (new option in Settings->Auto Processing);
  • Main menu icons now use all available window width;
  • It's now possible to manually specify MP2 or MP3 audio when manually adding files to the queue from the browse screen;
  • Viewing a schedule backup now shows favourites from the backup file too;
  • New hook to allow plugins to take action following the creation of a new directory (used by flatten to mark new folders as noflatten).
Fixes:
  • If a recording fails to decrypt, a system warning will only be generated after three attempts;
  • Restoration of favourite channels has been fixed;
  • The status panel was not correctly reporting MP3 extraction jobs;
  • Fix pkg _load method to handle packages with a missing description;
  • Fix duplicate suppression in system notifications for events with no associated date (such as system crashes);
  • Fix manual event scheduling (was reporting duplicate event).
Other Changes:
  • The . filename used for recursive flags has changed. Recursion is now indicated by the addition of an R (it was previously lower-cased);
  • Detect and report the CFW 3.11 kernel versions;
  • New {ts tsr} method to check if a recording was time-shifted.
Click to expand...
 
Hi, Thanks for all you your hard work. It is appreciated.
I want to report a bug that has existed for some time. I hoped it would be picked up and fixed by now, but it hasn't.

The bug is in the epg. Before you used to be able to see times/details for programs before the current time. Now whatever time you choose it always defaults to the current time.
If you missed or need to check on a past program, the only way to do it by looking at the tv screen and the real epg. :(

Thanks. I hope I described the bug clearly.
 
Agreed, but if you go forward in time it behaves as it should.
Have you ever been able to go back in time on the web interface? I have/had never tried it.
 
That's less of a bug and more of a feature, which you happen not to like. It was once the case that an entire historical record of EPG entries was displayed, but that slowed down the processing enormously hence the pruning.
 
I also would vote to see a limited amount of history if the performance penalty is not too high. If a 24 hour history is too much then perhaps 12 - or 6 or even just 3 would be handy.
 
Wildebeest said:
I also would vote to see a limited amount of history if the performance penalty is not too high. If a 24 hour history is too much then perhaps 12 - or 6 or even just 3 would be handy.
Click to expand...
The Humax software purges old data from its disk copy of the EPG info. just after midnight. The WebIf generates its database from the Humax software's file, so you could get, at most, back to about midnight for today. This is what you see in operation on the SUI.

(Well, mostly the Humax software purges. Like everything they seem to do, they don't do it properly and some turds from the past get left in for ever... or until you manually delete the file.)
 
Status
Not open for further replies.
Back
Top