Please see below ...
On 29/10/2018 20:39, RS wrote:
My main PC dual boots between Windows 10 1803 and kubuntu 18.04.1 LTS.
I would like to be able to run get_iplayer on whichever OS happens to
be running, as I do, for example, with Thunderbird, where I have both
profiles pointing to the same message base.
In the case of get_iplayer I would need to point the --profile-dir for
both installations to the same NTFS directory containing the files
options, tv.cache, radio.cache and download_history.
No, although you appear to have solved some of the problems, I do not
believe this can work satisfactorily for the sort of reasons you have
discovered.
We had a long discussion back in March about file formats, because
when I copied the get_iplayer files from Windows 10 to ubuntu the
options file was interpreted wrongly. Ralph diagnosed the problem.
http://lists.infradead.org/pipermail/get_iplayer/2018-March/011536.html
It was that the files written in Windows used CRLF as a line
terminator (DOS format) and files written in Linux used LF as a line
terminator (Unix format). The files tv.cache, radio.cache and
download_history rely on separators to separate records and fields, so
the different line terminators do not matter. The options file does
rely on the line terminator LF to separate records and for some
options the presence of a CR causes the option to be wrongly interpreted.
Yes, there are problem with both OSs reading the other's files ...
Windows doesn't recognise LF on its own as a line terminator, and
therefore the lines either side of one effectively get concatenated with
an oddball character in between.
Linux doesn't recognise CR as part of the line terminator, even
though it is followed by LF, and therefore appends it to the line data.
... and I gave an example of each and how it had caused obscure bugs
that had wasted my time considerably in the past.
Ralph kindly suggested some code to convert files from DOS format to
Unix format.
> `od -c foo' will show them, and they can be removed with
> `sed -i 's/\r$//' foo'.
I have since found an easier way to do the conversion. If I load a
file into the Linux nano text editor it tells me if there are some DOS
format lines. When I save it I can type alt-D to toggle between
saving it in Unix format and saving it in DOS format.
What a palaver, see below.
That is not the end of the problem. Ralph also pointed out that if
Perl thought it was running under Windows it would convert LF to CRLF
when writing a file. I think I have now found a solution. Windows 10
now supports the Linux Bash Shell and I have used it to install ubuntu
to run under Windows 10. That does seems to work, and Perl is
generating files in Unix format, so it does not seem to recognise that
it is running under Windows, which is what I wanted.
At present I am still testing it with default file locations. I have
run into a problem I have so far been unable to solve; it hangs while
tagging. If I repeat the run with get_iplayer --force --tag-only
--verbose it displays the metadata it has processed followed by
Started writing to temp file.
Progress: > 0% ------------------------------------------------------|
It does not move from 0%. I have probably done something silly so
that I have prevented the temp file from being created or written to,
although I would then have expected an error message. I have looked
at the get_iplayer v3.17 script to try to see what it is doing when it
prints those strings. There is a comment "Tagger Class" at line 8814.
I cannot see the strings "Started" or "temp " or "Progress:" there or
anywhere else in the script.
I can't suggest a particular reason for this, other than checking
whether AtomicParsley is being found under your unusual arrangement, and
whether the parameters being fed to it are exactly what is expected,
including checking for possible embedded CRs and LFs. One way of
finding these is to bracket a log message with, say ">>>" and "<<<" -
in other words, instead of a debug message like (this is not taken from
get_iplayer, I'm just demonstrating the principle) ...
"Calling Atomic Parsley with the following command-line: ".$comandline
... alter it to something like ...
">>>Calling Atomic Parsley with the following command-line:
".$comandline."<<<"
... then, when examining the output, if there is an orphan "<<<" on a
line by itself, you know that someone somehow has inserted an extra
line-terminator.
But generally, I would not adopt your approach to solving this problem.
I have five dual-boot PCs (though currently I can only use the 3 that
are laptops because my monitor caught fire) and 2 embedded linux NASs
and have needed to reconcile get_iplayer configuration and search data
between them, and to do this, I wrote a script called gip.pl, which
takes care to write the correct line-endings for the target OS.
Although it's designed to reconcile over a LAN between whatever OSs are
running on dual-boot PCs, I think you could modify it fairly easily to
reconcile between two locally mounted get_iplayer configurations. If
you were able to achieve this, you could then run gip.pl instead of
get_iplayer directly, and if you gave it the appropriate command-line
parameters, it would reconcile the two configurations each time it was
run before calling get_iplayer(.pl) to perform the downloads. I began to
document it, but didn't get very far, but the script has, I think and
hope, fairly comprehensive self-documentation in the form of comments:
www.macfh.co.uk/Test/GiP.html
_______________________________________________
get_iplayer mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/get_iplayer
