Regarding the issue reported yesterday in this forum, i've been getting exactly the same issue for over a week now.
I'm in the UK and have been using GiP for years and haven't changed my Broadband service for over a year.
I have tried numerous files, several times, over several days. all with the same result.
I've alter the --tvmode and this hasn't altered the results.
There are no reported issues on iPlayer for these programmes.

I note FFmpeg has a later version - is it worth updating this ?

Try a more recent version of ffmpeg and report back if it makes any difference. However, I can tell you that the supplied version works just fine, as it must do for virtually everyone else. You can also try downloading with --raw (skips re-muxing to take ffmpeg out of the equation) to get the base .ts file and check it for problems. ffmpeg may simply be choking on corrupted bits of the .ts file. Use the timestamps around the error messages to get approximate locations.

EDIT: If you are using a VPN, turn it off and try again.

EDIT 2: You can't infer anything from the size of the output files because you can't establish that they have been screwed up in exactly the same manner.

Thanks - will report back.

Right here goes...

As you say FFmpeg is working for everybody else, so I went with the --raw option 

Downloaded using GiP --raw a .TS file and for comparison a .MP4 (ADTS errors in FFmpeg as before 

in attached pic)

VLC played .TS file and sound broke from 2:17 to 2:27
VLC played .MP4 and sound broke before this and didn't come back.
Played it again, skipping to 2:00 and it had same break at 2:17 as .TS file had

WMP handles the sound breaks better, in that it skips the bad part, but carries on
WMP playing the .MP4 file had numerous breaks, 1:13-1:17, 2:17-2:27 and many many more

I was able to play the programme on iPlayer without a sound glitch, and even downloaded it in SD 

which played fine at the 2:17 point.

At this point I'm assuming a variety of data glitches which are spotted by FFmpeg, and some that 

are actually present in the .TS file.

Update - downloaded .TS file again - different glitches - all ok at 2:17-2:27
Different sized file as well.



Update - ran TsChecker - showed 108 discontinuity errors in one and 69 in the 2nd run

eg -----------------------------------------------------------
## File = C:\Users\Steve\Desktop\iPlayer Recordings\QI_XL_Series_N_-_5._Not_Nearly.ts
Included PIDs (*=PCR) = 32, 33*, 34
Root PIDs found = 0
First and last PCR = 00:00:09.9, 00:44:06.1  (in pid #33)
Duration = 00:43:56.2

Checking in progress
@00:02:18.2 (pid=33): Discontinuity, expected=2, found=0
@00:02:18.2 (pid=34): Discontinuity, expected=12, found=0
@00:02:25.9 (pid=33): Discontinuity, expected=5, found=0
@00:02:25.9 (pid=34): Discontinuity, expected=14, found=0
@00:02:33.6 (pid=0): Discontinuity, expected=2, found=4
@00:04:28.8 (pid=33): Discontinuity, expected=14, found=0
@00:04:28.8 (pid=34): Discontinuity, expected=9, found=0
@00:04:36.4 (pid=0): Discontinuity, expected=3, found=4
@00:04:51.8 (pid=33): Discontinuity, expected=6, found=0
 <snip>
---------------------------------------------------------------
The first error at least tying up with the first break when played with VLC

So I assume that if .TS files have bad data they will produce bad .MP4 files
I haven't any old .TS files, but thought I'd run FFmpg in verify mode on some files produced on 

15/11 and 22/11 no errors, files after 26/11 gave errors such as shown

eg ------------------------------------------
[aac @ 03a3b340] Number of bands (58) exceeds limit (47).
Error while decoding stream #0:1: Invalid data found when processing input
Error while decoding stream #0:1: Not yet implemented in FFmpeg, patches welcome
[aac @ 03a3b340] Number of bands (72) exceeds limit (47).
Error while decoding stream #0:1: Invalid data found when processing input
[aac @ 03a3b340] invalid band type
Error while decoding stream #0:1: Invalid data found when processing input
[aac @ 03a3b340] Number of bands (64) exceeds limit (47).
Error while decoding stream #0:1: Invalid data found when processing input
[aac @ 03a3b340] skip_data_stream_element: Input buffer exhausted before END element found
Error while decoding stream #0:1: Invalid data found when processing input
[aac @ 03a3b340] Expected to read 11 SBR bytes actually read 13.
[aac @ 03a3b340] channel element 0.6 is not allocated
Error while decoding stream #0:1: Invalid data found when processing input
[aac @ 03a3b340] channel element 2.5 is not allocated
Error while decoding stream #0:1: Invalid data found when processing input
[aac @ 03a3b340] Inconsistent channel configuration.
[aac @ 03a3b340] get_buffer() failed
 <snip>
----------------------------------------------

What can have changed or is this all down to poor broadband ?

Thanks. That confirms my suspicion that it had nothing to do with ffmpeg. Discontinuities are not necessarily a problem, though they appear to be in this case. ffmpeg can usually cope if the packets are intact. As to why you are getting corrupted files, I have no idea. If you download via VPN or proxy, that would be a likely culprit, or it could just be poor broadband. You are accessing different media streams via the iPlayer site and BBC Downloads app, so you can't infer much from how those behave.

Try --tvmode=hlsvhigh to see if the equivalent mobile-oriented stream fares any better. If that fails, try --tvmode=flashvhigh to see if the equivalent RTMP stream works better. The latter would only be a temporary solution since RTMP support is on the way out. If both fail, try youtube-dl. Its downloader may be more robust than get_iplayer's.

Thanks for the reply, I've backtracked through old stuff and found that all files after a certain date have poor MP4 files, and re-downloading some of the older files only gives me a corrupt copy.

Info on different streams for, BBC download uses maximum broadband for the required time - say 30mins,
whereas GiP gets a very broken service, gaps of 15 to 10 seconds every 20 to 30 seconds of data !!

No VPN, or proxy - so off to try your suggestions.