Possible extension to newk?

Trev

Trev

The Dumb One
Having noticed that some of my single recordings have the New: prefix. Would it be possible to remove the New: for existing single recordings?
 
Fair enough, but wouldn't it be just as straight-forward to define a sweeper rule to do it post-recording?
 
Ok Trev - are these single recordings generally left at the top level once recorded?

If so, go to the sweeper screen (brush icon on main web interface menu).
Click on 'Add Rule' and give it a name, leaving 'process files' selected.
At this point the rule will appear and look like:
Screenshot%202015-06-18%2019.16.17.png

Click on the green + at the left hand side.
In the box that pops up, choose Recording Title contains and click on Add Condition.

Screenshot%202015-06-18%2019.17.10.png


Click on the pen and paper icon to the right of where it now says "Enter text here..." and in the pop-up box, put 'New:*'
Now click on the pen and paper to the right of 'Continue to next rule' and make it look like this:

Screenshot%202015-06-18%2019.19.24.png


When you save that, the whole rule should look like this:

Screenshot%202015-06-18%2019.20.22.png


You can then use the Test Config button to see if it works or the Run Now to run it - don't forget to save to have it run automatically in the background. An alternative to all of this clicking around is to switch the text editor and paste this into there:

Code: 
# Remove New: prefix.
title {New:*} action {settitle {%orig%replace,New: ,,}}

A rule I think I'm going to leave in, and for recordings within folders too.
 
I'll add this as one of the pre-defined rule-sets that can be quickly added.
Code: 
18/06/2015 19:32 - ==== folder /media/My Video/Brooklyn Nine-Nine ====
18/06/2015 19:32 -
18/06/2015 19:32 -  --- Considering /media/My Video/Brooklyn Nine-Nine/New_ Brooklyn Nine-Nine_20150528_2059.ts
18/06/2015 19:32 - Processing [folder title New:* action {settitle {%orig%replace,New: ,,}}]
18/06/2015 19:32 -  title(New:*)
18/06/2015 19:32 -  MATCH
18/06/2015 19:32 - Applying action to recordings in /media/My Video/Brooklyn Nine-Nine
18/06/2015 19:32 - + folder_apply processing /media/My Video/Brooklyn Nine-Nine/New_ Brooklyn Nine-Nine_20150528_2059.ts
18/06/2015 19:32 -  - Calling expand_replace({New: } {})
18/06/2015 19:32 - Setting title for /media/My Video/Brooklyn Nine-Nine/New_ Brooklyn Nine-Nine_20150528_2059.ts to Brooklyn Nine-Nine
 
Thanks for that guys. I'll try it later, as actually watching TV at the mo. I'll report back on this one later.

Later.
I did that OK thanks to your text and pictures af123, and the New: has gone on the hummy UI. Result! Thanks so much.:)
1 Will this rule autorun?
2 If not, how do I get it to?
3 and will newk look after future series recordings OK?
I obviously need to explore this sweeper thing more so I can become nearly the expert like wot you are.:)
 
Last edited:
Sweeper version 2.0.8-3 lets you add the two rules needed for this nice and easily via the drop-down at the bottom:

Screenshot%202015-06-18%2023.48.34.png
 
Trev said:
1 Will this rule autorun?
2 If not, how do I get it to?
3 and will newk look after future series recordings OK?
Click to expand...

1. Yes - at least every 20 minutes but it may also be triggered when any recording ends - I'd need to look into that to remind myself!
2. n/a
3. newk will sort out the folders so that they don't have the prefix but the recordings inside those folders will still have it unless you add a second rule to sweeper in order to handle folders. You can do that by using the drop-down mentioned in the last post on the sweeper screen and then removing the duplicate rule (as you have already added that one).
 
Hi af123
Still seem to have a problem: Or my understanding of what's supposed to happen is faulty.
Although the New: prefix has gone from the media list on the Hummy, When I look at the media list in the web I/F three recordings (files in the video folder not in series folder) have a "New_{space}" prefix. Also, if I explore the video folder on my W7 machine, the same three files, and of course their sidecar files, also have the "New_" prefix.
Here is an extract from the the output from my sweeper rule that I ran this morning listing only the 'problem' files.
All three files originally had the "New: " prefix on the Hummy media list before I ran sweeper the first time last night, which, as I said above, no longer have the prefix after the first run.

Code: 
19/06/2015 08:48 - + Sweeper processing /media/My Video/New_ Ram Raid Britain_ Caught____20150603_2100.ts
19/06/2015 08:48 - Processing [title New: action {settitle %orig%replace,New:,,}]
19/06/2015 08:48 -  title(New:)
19/06/2015 08:48 -  Nomatch

19/06/2015 08:48 - + Sweeper processing /media/My Video/New_ Pets Make You Laugh Out____20150617_2000.ts
19/06/2015 08:48 - Processing [title New: action {settitle %orig%replace,New:,,}]
19/06/2015 08:48 -  title(New:)
19/06/2015 08:48 -  Nomatch
19/06/2015 08:48 - + Sweeper processing /media/My Video/New_ Secrets of Rome's Colosseum_20150205_2000.ts
19/06/2015 08:48 - Processing [title New: action {settitle %orig%replace,New:,,}]
19/06/2015 08:48 -  title(New:)
19/06/2015 08:48 -  Nomatch

What's going on? Is this normal?
Just noticed that I have left out the {space} in my replace rule, would this make any difference other than to leave a space at the front of the filename?
I did have a couple of crashes last night.
Code: 
Humax crashed at Thu Jun 18 21:41:20 UTC 2015 - Uptime: 9777
Humax crashed at Thu Jun 18 18:39:41 UTC 2015 - Uptime: 19673
 
The media list title and the file name are two different things. The WebIF media browser displays the file name, and the title is accessible in the media details or in the rename dialogue. The SUI media list displays the title, not the file name.

The file name is usually the title with a time stamp added, but disallowed characters (eg ":") are replaced by underscores.
 
Thanks for that BH. I now 'get the drift' of what's going on. I assumed, obviously incorrectly, that the sweeper rule would change the filename of the recording, along with its sidecar files.:oops:
Must read thoroughly the sweeper thread.:rolleyes:
 
This is great. Thanks for the instant heads up af123. I just made a rule to remove the New_ prefix on the filenames and much to my surprise it worked. To coin that old and not very PC phrase "White man's magic":)
Must now explore what else I can do.
 
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 had a quick look at creating a rule to do what newk does, but it's not obvious that it is possible. A few more extensions to sweeper perhaps?
 
Trev said:
This is great. Thanks for the instant heads up af123. I just made a rule to remove the New_ prefix on the filenames and much to my surprise it worked. To coin that old and not very PC phrase "White man's magic":)
Must now explore what else I can do.
Click to expand...
Welcome to the Dark Side. All that is required is the encouragement to dip a toe in the water. You'll be writing shell scripts and C code next!
 
Black Hole said:
I had a quick look at creating a rule to do what newk does, but it's not obvious that it is possible. A few more extensions to sweeper perhaps?
Click to expand...
Newk directly modifies the recording schedule during boot (before the database is locked) so that series recording folders are created without the prefix. Sweeper would have to move them after the fact and I'm not sure it has the ability to rename folders yet.
 
Black Hole said:
Welcome to the Dark Side. All that is required is the encouragement to dip a toe in the water. You'll be writing shell scripts and C code next!
Click to expand...
Well, I got that encouragement well and truly from af123 yesterday thanks. Not sure about your second sentence though.
Whilst having a look at stuff from DelftBlue in another topic re. dating the file as in"22 Jun 15" I found two or three recordings (Web I/F) with a number at the end that I don't understand, perhaps someone can enlighten me.
" Weird or What__20150322_2200-1433256688.ts (890.94 MiB)"
What's the number 1433256688 all about? Also all my filenames seem to start with a leading space in the WIF, is this normal?
 
The number is a timestamp which was added by one of the options in the web interface when you manually decrypted, shrunk, cropped or similar. That timestamp corresponds with Tue Jun 2 14:51:28 2015.

The leading space is because you must have missed a space in the %replace action, just after the colon so it only replaced the initial New: leaving the space after the colon. %replace doesn't yet support expressions so unfortunately there isn't an easy way to fix that just now, but I'll add support in the next update!
 
You must log in or register to reply here.
Back
Top