"Dave Liquorice" <allso...@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. _______________________________________________ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer