Possible extension to newk?

It's more trouble than it's worth.
I don't agree. It's causing a lot of extra processing on each pass and is filling up the log file. It makes sense to check whether it needs doing and skip the recording early if not.
 
updated in-place.
What does that mean?

Have incorporated your mod in sweeper. Its just come up with this one (rather than the shedloads that I was getting) entry in the auto.log and I can't see why it would be trying to rename it.
22/06/2015 11:25:05 - ... ERROR Target already exists
1 22/06/2015 11:25:05 - Renaming /media/My Video/Dogs_ Their Secret Lives/Dogs_ Their Secret Lives 18-06-15 1958.ts to Dogs_ Their Secret Lives 18-06-15 1958.

My full rule set is now:
# Remove New: prefix
title New: action {settitle {%orig%replace,New: ,,}}
# filenam clean
filename New_ action {renamefile {%orig%replace,New_ ,,}}
# File Datestamp DD MMM YY
filename *20[0-9][0-9][0-9][0-9][0-9][0-9]-* action {renamefile {%title %2digitdate-%2digitmonth-%2digityear %hhmm}}

PS. Just updated sweeper after running that rule set.
Run sweeper again and got the same ERROR Target already exists

Just ran sweeper on my F1 series folder. It didn't rename:
Formula 1_ Austrian Grand Prix____20150620_1730.ts
 
Last edited:
I meant that I updated my original post following BH's note.

I'm not sure why you're getting that error - if you run a test from the sweeper screen it will provide more output that should help.

You have a -* at the end of the last rule instead of _* which is why it isn't matching that new recording.
 
You could explicitly look for the right pattern of numbers - this should be enough (for the next 85 years at least!):

Code:
filename {*20[0-9][0-9][0-9][0-9][0-9][0-9]-*}
I just copy/pasted the above;)
I'll correct it and try again
That worked:)
Changed it in the root rules as well and it has stopped it trying to rename the Dogs files.:)
 
Last edited:
There is something a bit odd about the handling of the \s in the regsub.
It seems to be present on the text edit page, but the \ seems to vanish from the interactive page; both in the interactive rule and its raw text equivalent.
Thanks - will be fixed in the next version, which I'm just preparing now.
 
I know this ought to be in the sweeper thread, but the above reminded me: would you please consider some sort of "global" flag to allow the creation of rules that shoudl apply equally to folders, and to standalone files, so that the repetition above isn't required?
Yep - sweeper 2.0.8-5 adds a global rule type, just put the keyword global at the start of the rule or in the GUI select the 'process files & folders' option when creating a rule.
One limitation is that a global rule can only use conditions and actions that can be used for both file and folder rules. So, for example, you couldn't use the series condition in a global rule whereas you can in a folder rule because series isn't a relevant test for files.

Code:
# Remove New: prefix.
global title New:* action {settitle {%orig%regsub,New:\s*,,}}
 
Another change in 2.0.8-5 is that it will pick the newest usable recording in a folder when testing the conditions rather than a random one.
 
The name 'global' implies more, but I presume that we are still talking about folders as just one level, not fully recursive.
 
Both "Test config" and "Run now" options produce a dialog box which has a title of "Test current ruleset". This is rather confusing.

The pre-defined ruleset for removing the "New:" prefix can now be simplified in the Webif as well.
 
I don't agree. It's causing a lot of extra processing on each pass and is filling up the log file. It makes sense to check whether it needs doing and skip the recording early if not.
What I meant was that the whole thing is more trouble than it's worth. Trev doesn't like having a system time string in the file name - when actually it doesn't really matter. When it was processed is of no real interest, it can just be ignored.
 
If when it was processed is of no real interest then why is included in the first place? That sounds a bit like the answer to the question "Why doesn't my Freesat work?" being "Then get a Freeview box.". Totally irrelevant as far as solving the questioner's problem is concerned.
Or as an alternative, just give the filename a number that is totally meaningless as far as looking at the filing system is concerned, as the box doesn't use the filename.
 
It matters to the auto-processing - it doesn't matter to me, or appear in the media list. Call it administrative.
 
Is the Global rule processing working as intended?

When processing a sub-folder Sweeper only checks the newest recording to see if it matches the conditions but applies the action to every recording in the folder without checking whether they meet the criteria.

So using the DetectAds sample rule when a new unprocessed recording is added to the series folder every other, already processed, episode is requeued for ad detection.
This is not what is wanted! :(
I think it is the reason that ribrob ended up with 20K entries in the queue
An example using a test rule
Code:
23/12/2015 15:39 - ==== folder /media/My Video/Border Security_ Canada's___ ==== 
23/12/2015 15:39 - 
23/12/2015 15:39 - --- Considering /media/My Video/Border Security_ Canada's___/Border Security_ Canada's____20151219_0015.ts 
23/12/2015 15:39 - Processing [!flag New foldername Border action {setguidance {Global rule applied}}] 
23/12/2015 15:39 - !flag(New)
23/12/2015 15:39 - MATCH 
23/12/2015 15:39 - foldername(Border) 
23/12/2015 15:39 - MATCH 
23/12/2015 15:39 - action(setguidance {Global rule applied}) 
23/12/2015 15:39 - ACTION: setguidance(Global rule applied) [1] 
23/12/2015 15:39 - Applying action to recordings in /media/My Video/Border Security_ Canada's___ 
23/12/2015 15:39 - + folder_apply processing /media/My Video/Border Security_ Canada's___/Border Security_ Canada's____20151219_0015.ts 
23/12/2015 15:39 - Setting guidance for /media/My Video/Border Security_ Canada's___/Border Security_ Canada's____20151219_0015.ts to Global rule applied 
23/12/2015 15:39 - + folder_apply processing /media/My Video/Border Security_ Canada's___/Border Security_ Canada's____20151218_2345.ts 
23/12/2015 15:39 - Setting guidance for /media/My Video/Border Security_ Canada's___/Border Security_ Canada's____20151218_2345.ts to Global rule applied 
23/12/2015 15:39 -

I can't think of any circumstances where the current processing is desirable.

Either every recording in the folder should have the tests applied which is what I would expect from recursive processing or the action should only be applied to the newest recording on the basis that older episodes will have been processed when they were first added to the folder.
 
I just made a rule to remove the New_ prefix on the filenames and much to my surprise it worked.

Nice - I'll have to add that to the template too.
The syntax for doing the string replacements is a bit clunky but I think that's the only really non-intuitive part.

I'm late to the party for removing 'New:' prefixes via Sweeper .... but very glad to have finally arrived :)

And was happy to discover the rule for renaming the Media List titles can be added from a drop-down list, 'ready-to-use' - as the details of this one are less intuitive and need to be really precise.

Then I realised I needed a rule for taking 'New_ ' off the filenames too, so came searching here in the forums, hoping that someone else had already formulated the correct ruleset - and lo ... Trev and af123 had got it all worked out.

So, I popped the following into the sweeper file and it works luverly. Thank you to all concerned!

# Remove 'New:' prefix in Media List title.
global title New:* action {settitle {%orig%regsub,New:\s*,,}}
# Remove 'New:' prefix in filename.
global filename New_ action {renamefile {%orig%replace,New_ ,,}}

Suggestion ... Perhaps the ruleset for disappearing the "New_" in filenames might be added to the Sweeper drop-down option also?

(I imagine that most people would want to zap the filename as well as the Media List title. However if someone doesn't want both rules - they can always delete one or the other - it's easier to delete than to create from scratch)
 
Apart from all that stuff. Welcome back DelftBlue. Long time no hear.
Hi there! Much longer time, no hear .... 8 years this time :)

I'm very happy to find the forums still active.
Thank you to all the wonderful people who customised the firmware AND shared it with the world - I'm still using it daily and grateful for it.
 
Back
Top