Ability to specify a temporary directory.

[dinkypumpkin]

On 19/02/2013 11:53, John G. Dargie wrote:
> On 19 Feb 2013, at 10:49, Shevek wrote:
>> An interim solution would be to use a local download location and then
>> specify a post process script to move the files to your network share
> ...
> That's a possibility I've considered but it would be better (for me :-) anyway!) if it was done by get_iplayer as I've suggested.  In fact, I'm considering modifying get_iplayer code myself to do it there as I've described (even if it's only in my own copy of get_iplayer).
>
> I call get_iplayer from a script that already looks to see if I have the file downloaded.  I also run my script from multiple locations (my Mac, or my Pi which is slower but left on overnight).  I want to reliably check that I haven't already downloaded it somewhere else.  By choice, I have't added extra storage to my Pi because I already have the network storage.
>
> I'm still wondering if anyone else would benefit from it though.  Am I the only one using get_iplayer to download to network storage?

You're not the only one, but I'm not clear why you don't like the 
proffered solution.  It's nothing more than including something like 
this in your options file:

command mv -n "<filename>" "/somewhere/on/network/drive/"

I've done that for a long time and it works fine.  Of course, you can 
use a shell script for more complex post-processing.  And as Kapitano 
pointed out, get_iplayer's download history check prevents you from 
downloading a programme you already have, so need for special measures 
there.

If you decide to hack your copy of get_iplayer, you should flip your 
idea on its head.  Rather than introduce a temp directory, leave 
--output as it is and add an option something like "--postproc-dir". 
Then immediately after run_user_command() is executed, test for that 
option and do the necessary file move/copy if it is set.  This will 
avoid the need to change any existing functionality. But still, that's 
no different than using --command as above.

On 19/02/2013 12:56, John G. Dargie wrote:
> Another answer is to cut out an unnecessary copy process.
>
> My suggestion:
> a) Download FLV to temp location.
> b) Transcode to final location.
>
> Your suggestion:
> a) Download FLV to local location.
> b) Transcode to local location.
> c) Then copy to remote storage.

You're forgetting the metadata tagging.  AtomicParsley writes a 
temporary version of the output file, then copies it over the original. 
  That's going to be slow on a network drive.  You could target AP 
output to the network drive and in effect copy the output file to its 
final location, but you'll then need to clean up the original file.  And 
of course, local radio programmes aren't tagged with AtomicParsley at 
all, so you would need another solution for them if they are part of 
your downloading habits.

It might be "unnecessary", strictly speaking, but I think you're better 
off letting your OS handle file copying - it's made for the job. 
AtomicParsley is fairly reliable with get_iplayer, but not as reliable 
as your OS.  Also, you would need to add additional error checking if 
you want to rely on AP to copy files.  Currently, if AP fails it just 
means you don't have metadata tags.  In your scheme, if AP fails it 
means you don't have an output file at all. It hardly seems worth the 
bother.