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.
_______________________________________________
get_iplayer mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/get_iplayer
