'fileprefix' filename templates are having characters elided
Jeremy Nicoll - ml get_iplayer
jn.ml.gti.91 at wingsandbeaks.org.uk
Sat Nov 8 04:40:54 PST 2014
With 2.84 etc this worked. With 2.90 (I've not used any of the intermediate
versions), specifying for example:
--fatfilename --whitespace --file-prefix "$GRAB-SN130-002369 R=<nameshort> -
S<seriesnum> E<episodenum> - E=<episodetitle> 'E=<episode>' P=<pid> M=<mode>
Z=<duration> F=<firsbcastdate> L=<lastbcastdate>"
--get "clare in the comm.*past caring"
produces a final file name like:
$GRAB-SN130-002369 RClare in the Community - S2 E1 - E EPast Caring
Pb00fslwd Mflashaacstd Z1800 F2008-11-30 L2014-11-02.mp3
that is, all the '=' signs, and the pair of single quotes, have vanished.
(I've also deliberately placed round and square brackets around parts of
these filenames in the past, to make parsing them subsequently with other
utilities easier), and would prefer such characters I choose to introduce
should survive.
This suggests to me that the new(ish) logic for removing non-ascii and
punctuation characters from a filename is being applied after the metadata
values have been plugged into my fileprefix template name.
Surely removing single quotes is wrong anyway? It's going to remove "'s" at
the end of title words, and ruin names like "O'Leary" in programme titles.
It seems to me that the process should be
- extract metadata values from wherever
- elide non-ascii and punctuation chars from them
- plug those edited strings into the fileprefix template
I know there are output options that would allow me to turn off the elision
of weird chars from filenames, but I'm happy that the BBC-supplied weird
characters get elided. I just don't want mine removed as well.
--
Jeremy Nicoll - my opinions are my own.
More information about the get_iplayer
mailing list