2.97 failing to produce files

[Vangelis forthnet]

On Sun Dec 11 20:41:39 GMT 2016, Charles Johnson wrote:

> that's done separately in a script and is just
>
> ffmpeg -i "${f}" $(basename "${f}").mp3

So, to recap,  your original issue (failure to remux FLV audio files
into MP4 container, after upgrading to GiP 2.97) was caused
by the inability of your obsolete FFmpeg v0.8.18 to handle code
introduced in 2.97 - upgrading to FFmpeg 3.2.2 rectified that issue.

Now, this is a second issue, unrelated to GiP itself,
in that your FFmpeg 3.2.2 build  (on Debian Jessie)
appears unable to transcode a HE-AACv1 m4a file
(produced by GiP) to MP3.

If this inability is global (for all flashaaclow files),
the best course of action would be to report it to
some place relevant, either to the Debian Jessie
team or the FFmpeg mailing list
https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-user/

As stated previously, I can't get my hands on a
pre-compiled FFmpeg-3.2.2-win32 binary (that is
also Windows NT6.0 compatible) to test - the
most recent one I got was compiled from code
authored on Dec 4th, 2016.

I created the following batch file

FOR %%N in (*.m4a) DO ffmpeg -i "%%N" -vn "%%~nN.mp3"
pause

and tested various "aaclow" audio files
downloaded by GiP, I was unable to
replicate your bug with that FFmpeg version...

On Mon Dec 12 13:56:02 GMT 2016, Charles Johnson wrote:

> I backed up ffmpeg 3.2.2, symlinked the latest build
> from here https://www.johnvansickle.com/ffmpeg/
> with /usr/bin/ffmpeg

Apologies for being thick, but do you actually
mean the latest git build (gedb4f5d built on 20161211)
or latest 3.2.2 build offered by johnvansickle?
(so as to determine whether the Debian Jessie
flavour of 3.2.2 was at some fault or the 3.2.2
code in general...)

> Oh and i got atomicparsley but probably don't need it

AP is always welcome here, since it adds a full
metadata tag + Windows Explorer thumbnail :-)

On Mon Dec 12 10:14:30 GMT 2016, Charles Johnson wrote:

> get_iplayer --mode=flashaaclow1 --start=0 --stop=0 --pid 
> b084tjt3 --force --verbose --overwrite 2>&1 | tee b084tjt3.log

Two comments:

> --mode=flashaaclow1

GiP will, by default, use the first CDN,
so appending "1" to the mode is redundant;
plus, if CDN 1 fails for whatever reason,
no fallback to CDN 2 will be attempted...

> --start=0 --stop=0

Though I'm not seeing evidence of these being used
in the linked log (perhaps they negate each other),
why include them in the command to begin with?
>From the docs:

--start <secs|hh:mm:ss>          Recording/streaming start offset
--stop <secs|hh:mm:ss>           Recording/streaming stop offset

> Thanks for the help

You are welcome :-)

Vangelis.