My usage of get_iplayer is to download to computer harddrive, then copy that file to a USB stick which is then plugged into the USB port of a Samsung 5100 TV.

All has been well using the option
for some while, albeit receiving the warning about remapping to hvfxsd.

Since the start of August 2017, downloaded material has not been usable as it has been missing the audio, although the files play well (audio and video) on a computer using VLC on Ubuntu.

I found various discussions regarding this, such as this:
https://www.computing.net/answers/window...11344.html

I discovered that simply recoding the file produced by get_iplayer with Handbrake using the "out-of-the-box" setting was sufficient to create a playable (audio and video) file.

Whilst this was working well, there was a lot of time spent on the download and re-encoding.  Also disk space was diminishing as I was keeping both versions.

using ffprobe I also discovered that the files directly produced by get_iplayer, at my options, were



Delving further into the settings of Handbrake I discovered that the critical setting was the Audio bitrate, which was at 160K in the preset dropdown.

I have a little experience with ffmpeg and discovered that


would also create a playable file.  The actual codec seemed not to matter, but the audio bitrate was the breaking point

Whilst not a programmer, I can often successfully fiddle with existing code, and opened up the perl get_iplayer.

I changed the line


to


I  changed from 160K as acquisition will be one of 96K, 128K, 320K from the figures given here:
https://github.com/get-iplayer/get_iplay...i/modesref
and it seemed redundant to specify 160K.

This fixes my issue, but I realise that hard coding options is generally regarded as "a bad thing", and of course I am now degrading my master copy, from which there can be no return.

I wonder if the audio part of the tv options should be specifiable separately from the overall tvmode, or be specifiable within the options file?

I've written this up as fully as I can partly to help any others who hit this problem with older TVs - I understand that it also affects many Sony models.  It's not a specific request for extra functionality.

Just use --tvmode=dvfxsd (which should produce 96k audio), or another dvf mode.  As shown in the recording modes reference, the max audio bit rate for dvf modes is 128k.

I'll try that now as I have a number of test files at various bitrates and can make the direct comparison.

Previously though, when I used to worry about mp3 v. cd "quality", I would have said that sub 128K bitrates were unacceptable - we'll see what difference age has made!

I'm trying to keep open the possibility of 960 x 540 video (otherwise - what's the point of a "big telly"?) at 128K (when available) but without going to dvfsd with 50fps which makes for large filesizes.
----------------------------------------------------------------------------------------------------
Update: Very subjective, using decent headphones, and not on any particularly "difficult" audio track - I can hear (just) the difference between the 94 kb/s files and other at a higher bitrate, but 164 kb/s and 317 kb/s sound the same.

(31-08-2017, 01:46 PM)I'm trying to keep open the possibility of 960 x 540 video (otherwise - what's the point of a "big telly"?) at 128K (when available) but without going to dvfsd with 50fps which makes for large filesizes.

I think you can do that with youtube-dl. It's not likely to be in get_iplayer any time soon.

I wouldn't worry about audio bit-rates.
Using the mediainfo program (Linux):-

Note that 160kB/sec audio makes up only 7% of the file size.

(31-08-2017, 04:02 PM)I wouldn't worry about audio bit-rates.
...
Note that 160kB/sec audio makes up only 7% of the file size.

The problem I'm trying to overcome is not the overall size of the file which is related to the bitrates.

The issue is that some older devices - specifically the Samsung TV I identified in my original post, some old Sonys, and others as discussed in the linked computing.net forum thread, are incapable of rendering audio when it exceeds some unspecified bitrate - regardless of the codec.
I found many people floundering with this problem on other fora.