[sweeper] Custom rules to manage recordings

[prpr]

This seems to work but as the decrypt and auto-audio are processed in the background queue and Sweeper seems to be an aynchronous background task, I'm worried that Sweeper will try to delete the original recording before the mp3 file creation is completed.

I was speculating whether adding a "Queue for deletion" option to the Queue processing would be a good idea.
You can already do "Queue for Decrypt" and "Queue for MP3", so you could serialise an asynchronous process with 3 rules (you don't seem to be able to add more than 1 action per rule) - Decrypt, MP3, Delete - in a guaranteed order.

I've added the Age condition which I assume relates to the original .ts recording age.

Yes.

Does anyone know if Sweeper checks whether the original file is in use before deleting or is this a lower level operating system check?

It appears to, yes. The Linux OS doesn't care if one process tries to delete a file that is already in use - it remains accessible to processes that already have the file open, but not to subsequent ones, and the file is then actually deleted when the usage count drops to 0.
What you really need to worry about is it being deleted before the conversion has started. 2 hours seem a bit on the mean side. I would make it a day.

 

[Luke]

What you really need to worry about is it being deleted before the conversion has started. 2 hours seem a bit on the mean side. I would make it a day.

Doesn’t the condition "File exists %basename.mp3" being true mean that the conversion has at least started?

 

[prpr]

Doesn’t the condition "File exists %basename.mp3" being true mean that the conversion has at least started?

I guess so!

 

[MymsMan]

Doesn’t the condition "File exists %basename.mp3" being true mean that the conversion has at least started?

But not necesarily completed, while the OS system will protect against deletion of file in use it won't protect against shutdowns whilst in prcocess. The queue system will restart incomplete operations on restart - providing the input file still exists!

You can check in sweeper whether a recording is queued for processing so you could defer deletion until it is no longer queued.

I was speculating whether adding a "Queue for deletion" option to the Queue processing would be a good idea.
You can already do "Queue for Decrypt" and "Queue for MP3", so you could serialise an asynchronous process with 3 rules (you don't seem to be able to add more than 1 action per rule) - Decrypt, MP3, Delete - in a guaranteed order.

One of my many started, but never completed, ideas was to create a package of additional queue actions including Queue for Copy, and Queue for Move, and Queue for Command
Archiving to an external storage medium can be slow but the current Sweeper actions run sychronously, and Queue for command would allow execution of an arbitrary command.
This would require Browse to have a text entry box for queue options to specify the destination/command options. Ideally you could use %values as in sweeper rules

 

[prpr]

OK, a bit more thought and I've come up with this:

humax /mnt/hd2/My Video/Tom # cat .sweeper
# Decrypt
action {queue decrypt}
# Audio extract and delete
action {queue {mp3 -del}}

Seems to work well. The original recording files end up in the bin (if the undelete package is installed) and the .mp3 is left in the folder.
It will be in the next WebIf release, so don't try it yet as it won't work.

 

[Black Hole]

Great! I have an immediate use for that. I've been copying .mp3 to USB (for car listening) and then deleting both manually for years.