[flatten] Automatically Removing Programmes from Series Folders

[Black Hole]

I disagree, unless we want to combine flatten and auto-filer. Flatten has no need to recurse lower-level folders. At the moment auto-filer looks for a duplicate folder name, but it could be directed to move files to an arbitrary folder.

The concept of combining them has been brought up before and dismissed on the "do one job simply" philosophy, which is fair enough in its place but now we have a situation of interacting events which would be better handled in a one-stop-shop. Flatten and auto-filer both have to act on a new recording that has been placed in a series folder. Flatten desires to move it to the top level, auto-filer desires to move it somewhere else. It's still a move operation on a new recording, so what's the bother with streamlining the two into one general purpose utility?

What if the .folder_name flag file contained the desired destination of any files which arrived in a first-level folder with a matching name? I'll think about it.

 

[neilleeds]

I disagree, unless we want to combine flatten and auto-filer. Flatten has no need to recurse lower-level folders. At the moment auto-filer looks for a duplicate folder name, but it could be directed to move files to an arbitrary folder.

The concept of combining them has been brought up before and dismissed on the "do one job simply" philosophy, which is fair enough in its place but now we have a situation of interacting events which would be better handled in a one-stop-shop. Flatten and auto-filer both have to act on a new recording that has been placed in a series folder. Flatten desires to move it to the top level, auto-filer desires to move it somewhere else. It's still a move operation on a new recording, so what's the bother with streamlining the two into one general purpose utility?

What if the .folder_name flag file contained the desired destination of any files which arrived in a first-level folder with a matching name? I'll think about it.

I agree the best solution would be to combine the two applications into one solution which handles both flattening, filing and imho flattening filed stuff.

 

[Black Hole]

OK, here's what I think (sorry if any posts have crossed, I've had this edit window open while I crystalise a design). I don't know what to call it, but this will replace the existing flatten and auto-filer - how about "relocator" as a working title.

Pre-requisites:

.folder_name - a flag file in the root directory (My Video) that can be either zero byte, or contains a path to the desired redirected programme folder.
.autoflatten - a flag file in the root directory which controls the default behaviour for new recordings.
.noflatten, [folder_name] - flags which over-ride the action of relocator.

Some kind of WebIF control panel will manage the flag settings.

Modus Operandi:

relocator fires up periodically (to clear any backlog) and when it detects a completed recording (it might also then pass control on to other processes - such as decrypt-in-place). It scans first-level folders only.

IF the folder contains the .noflatten flag file, or the folder name begins "[", it shall be ignored.

IF the folder has no corresponding .folder_name flag file AND .autoflatten does not exist, it shall be ignored.

IF the folder has no corresponding .folder_name flag file AND .autoflatten exists, move its contents to the top level and delete the folder.

IF the folder has a corresponding .folder_name flag file, parse the contents of the flag file.

IF the flag file is blank, move the folder contents to the top level and delete the folder.​

IF the flag file contains a valid path, create the path if necessary, move the folder contents to the path, and delete the source folder.​

IF the flag file contains an invalid path, do nothing.​

________________________

I think that addresses everything. Just up to the genius that is af123 to come up with a nice front-end for the WebIF!

 

[Black Hole]

I agree the best solution would be to combine the two applications into one solution which handles both flattening, filing and imho flattening filed stuff.

The above wouldn't flatten existing filed stuff, you would have to take care of that yourself, but any new material that came along could be automatically directed to any folder you like - not just one with a matching name.

 

[neilleeds]

The above wouldn't flatten existing filed stuff, you would have to take care of that yourself, but any new material that came along could be automatically directed to any folder you like - not just one with a matching name.

I like that solution, a grid view in webif would be ideal for the series specific actions. This approach looks very powerful, the only slight problem I can think of is that series filer auto moves files depending on where you moved them before, thus requiring no input from the user where as this would require configuration. I'm not sure I can think of a way to combine the two approaches though because filer relies on the series support file which wouldn't be there if you had dropped the program into a different folder. The filer can continue to be available alongside any new solution anyway but I would certainly switch to this.

 

[Black Hole]

the only slight problem I can think of is that series filer auto moves files depending on where you moved them before, thus requiring no input from the user where as this would require configuration.

Is that because you move the whole folder rather than the individual files, to start with? Interesting point. We could have a helper activity which scans for .series files and creates the appropriate .folder_name pointer content in the background. We could even make this operable from the SUI - create a "magic" directory called [Flatten], and any series folders dropped in there get flattened and marked for future flattening.

Hell-fire! This is a completely alternative approach - instead of flag files in the top directory, they could be actual folders in a magic directory and then flatten becomes and extension of auto-filer completely operable by SUI. Not sure how to auto-flatten (could keep the .autoflatten flag) or flatten subfolders though.

 

[Black Hole]

Done a bit more thinking, and I reckon the magic folder option is probably going too far. It's not like anybody running this stuff hasn't got access to the WebIF.

auto-filer and flatten would still be available for the simple modes, but if the BYTs gave us relocator as well I guess the tech-heads would be very happy. For my purposes, flatten is probably all I need.

 

[neilleeds]

Done a bit more thinking, and I reckon the magic folder option is probably going too far. It's not like anybody running this stuff hasn't got access to the WebIF.

auto-filer and flatten would still be available for the simple modes, but if the BYTs gave us relocator as well I guess the tech-heads would be very happy. For my purposes, flatten is probably all I need.

I agree, it was starting to sound quite complicated.

 

[Black Hole]

flatten could benefit from the magic folder option though!

 

[MarkP]

Thanks guys - particularly af123. I have installed custom firmware and WebIF just so that I could have 'flatten'. Just what I wanted (for exactly the same reasons as brian). Great work.

 

[Brian]

Thanks guys - particularly af123. I have installed custom firmware and WebIF just so that I could have 'flatten'. Just what I wanted (for exactly the same reasons as brian). Great work.

So I'm Not the only one then.

 

[Wallace]

I used it once, hated it. It took me ages to rebuild my directory structure. Each to their own.

 

[Brian]

I used it once, hated it. It took me ages to rebuild my directory structure. Each to their own.

I suppose it all depends on how you use your box, I just like to record, watch, then delete my programmes in the order that I record them, and very rarely keep anything, so flatten is perfect for me.

 

[Wallace]

Don't get me wrong. I really appreciate all the hard work that goes into Customised Firmware and associated packages. It would be a sad world if everyone liked the same things.

I want Cameron Diaz all to myself!!!

 

[Black Hole]

Had another idea about relocator (the joys of thinking aloud - but if I didn't nobody would know I'm thinking at all!). Actually, it's more like a souped-up auto-filer, so I'm going to continue the conversation in that topic.

 

[Black Hole]

I used it once, hated it. It took me ages to rebuild my directory structure. Each to their own.

You mean you enabled flatten without first marking what you didn't want flattening?

 

[Brian]

I have discovered a bug in flatten, and will try to describe what happened.

I was recording "Dancing on Ice", and about an hour into the programme I decided to start watching it by selecting the recording from the Dancing on Ice folder within the Media - Video list. After the recording finished playing, I was returned to the DoI folder which by then appeared to be empty as the programme had been moved by flatten whilst I was watching it (should this happen whilst the file is still in use?).

Checking via webif, it seems that the .hmt file is still remaining in the DoI folder preventing it from being flattened, and resulting in what appears to be an empty folder which should have been deleted.

 

[Sam Widges]

I came across that behaviour when I was writing seriesfiler - if you move a programme while it is being watched, a new hmt file gets recreated when you stop. I avoided that issue by ignoring files that are open by any other process.

 

[Brian]

Hopefully this should be able to be fixed then.

 

[Sam Widges]

If you look at the logic in flatten

if {[$ts get end] > [clock seconds]} {
    puts "    Recording has not yet ended."
    continue
}
 
set sz [file size "$rec.ts"]
sleep 2
set nsz [file size "$rec.ts"]
if {$sz != $nsz} {
    puts "    File size is still changing."
    continue
}
 
puts "    Moving recording."
<etc>

This checks for the file being recorded, e.g. by checking if the file is getting bigger. It can, however, be replaced by the following code from seriesfiler:

inuse=`lsof | grep "$episode".ts`
if [ -n "$inuse" ]; then
        echo "$episodefile is in use - skipping"
else
        echo "Moving $episode to $location"
        <etc>
fi

All the above snippet does is that it checks that the ts file is not in use by any other process. Checking that the file size is growing is fine if the file is being recorded, but it doesn't account for the fact that the file could be being watched or tweaked by something like nicesplice. Checking for the file being open by any process should cover all eventualities.