Spurious write permission error

[C E Macfarlane]

Please see below ...

www.macfh.co.uk/CEMH.html

>     -----Original Message-----
>     From: get_iplayer [mailto:get_iplayer-bounces at lists.infradead.org]On
>     Behalf Of Nick Payne
>     Sent: 02 May 2016 13:41
>     To: get_iplayer at lists.infradead.org
>     Subject: Spurious write permission error
>
>     Running GiP 2.94 on Windows. I had two downloads running
>     simultaneously,
>     both writing to the same directory.

I don't suppose much, if any, thought has been given to running multiple
instances of GiP simultaneously  -  so, for example, the download_history is
in a non-standard text format, rather than an open or de facto standard
multi-user database format such as SQLite  -  and consequently it seems very
likely that both downloads were attempting to write to the same file, which
may not necessarily be the one that you might guess from examining the files
remaining afterwards.  If you wish to run two GiP instances simultaneously,
I'd suggest that they should work from different directories, but, of
course, the problem with this idea is keeping the download_histories and
caches in the two directories in sync, see below.  Thus in general, I'd
suggest only ever running one instance of GiP at a time, and always from the
same machine, so that the information available to it is always up-to-date.

That said, I do meet circumstances, such as Wimbledon and the Proms, where
it can be useful to have two or more instances running together.  Usually I
do this on two seperate NASs  -  my version of RAID is two have two
identical NASs which are synced in the early hours of the morning.  Thus one
NAS takes care of the usual nightly downloads, while the other grinds full
time trying to keep up with, say, Wimbledon.  In this situation, it's not so
necessary that each knows what the other has already downloaded, but,
nevertheless, I have written a Bash script for my Linux machines such as
these NASs which when run on one causes it to sync various support files
with the another.  The script is tolerably well-documented internally, but
nevertheless is probably not for the programmatically or technologically
faint-hearted!  However, if there is sufficient interest, I could see about
making it publicly available on an unsupported, users' risk only basis.

Regards