Seeking advice on transfer to new computer

[Jeremy Nicoll - ml get_iplayer]

"Dave Liquorice" <allsorts at howhill.com> wrote:

>On Sun, 28 Dec 2014 23:36:27 +0000, Roger Bell_West wrote:
>
>>> As the download_history is in the current users space what happens on a 
>>> multi user system when more than one user requests the same programme? 
>>> Does it get downloaded for each individual user request?
>> 
>> Tempted as I am to say "try it and see", the answer is yes.
>> 
>> You could get clever with a group-writeable history file and multiple
>> links to it, I suppose, but I don't think anyone's complained about
>> the current system. It's what a program on a multi-user machine is
>> expected to do: the actions of user A don't affect user B.
>
>True enough, I guess it comes from being on the 'net since the early '90's 
>via dialup and paying for every second of online time. Even these days I 
>only normally buy 100 GB/month and that can get a bit tight.
>
>Implimenting a single file store and maintianing inter-user "privacy" would

>be too complicated. A file store that was open and avoided duplicate 
>downloads should be a lot easier, the various cache files could usefully 
>come into this as well. Programme file owned rw by whoever downloaded it, 
>group readable, an option to turn it on with a given path (defaults to no 
>path - off), cache files rw by group.
>
>Just an idea, I don't expect to see anything unless the itch I have gets to

>great and I scratch it.  B-)

I run G_ip on Windows PCs, but have it set up so that the cache and history
and settings files are all in a Dropbox folder (of course I do understand
that all machines have their own copy of that, but the principle is one of a
common set of files).   


I use a wrapper for G_ip that builds the overall command; it's aware of
which machine it's running on and makes machine-specific decisions.  It
specifies fully

  - the location of the perl interpreter, so I needn't use the same
    version of perl on each machine; I wouldn't be likely to update
    all of them at the same time...


  - the location of the G_iP perl script (and which one; as I modify it
    myself I have each release's original & successive revisions)


  - the location of the cache files, via --profiledir


  - the location of the settings files; actually I have n separate
    files, one per machine, all in the common folder; I changed the
    G_iP perl script to read a machine-file called

        options_<machinid>.txt

    where machinid is a suitably-set environment variable that affects
    almost every script I run.  Also, appending ".txt" to the filename
    makes it easier to open it in a texteditor; Windows isn't keen on
    files with no extension.

    Inside the machine-specific settings files are the machine-specific 
    locations of all the helper applications.


  - I also changed the G_iP script to use separate files for the radio
    and tv download histories, and my wrapper knows about that too, not
    so it can build commands with specific history-file names, but so 
    it can directly open the files for other reasons


I have scheduled tasks defined on all the machines to run G_iP every 25
minutes to refresh the cache files.  However the script that gets run
(actually the wrapper, again) checks a flag file, also in a common Dropbox
folder to say which machine's scheduled task is actually meant to do the
work; the tasks on the other machines just start & stop immediately having
observed that it's not their role that day.  


One of the jobs the wrapper script does is prevent manual activities that
might interfere with scheduled-task ones, or manual ones happening on all
machines at once, from interfering with each other.  It also looks for
problems caused by Dropbox syncing not happening timeously etc.

-- 
Jeremy Nicoll - my opinions are my own.