Glad it worked, as for the detail of what's wrong with the stream, I am not sure.
I guess it's because the start is stereo and there is nothing to properly tell it about the change.
The errors produced by faad do indicate that it "knows" there is an unexpected channel layout change, but it seems to be luck/the way the player calls it as to whether it can resync.
I originally tested with just the sound extracted with ffmpeg -acodec copy. For some reason this behaved slightly differently with mplayer than sound + vid in that it couldn't recover from the second change like it did with vid, but could still play the 5.1 if I skipped past it.
I assume vlc does more querying of faad than mplayer in some way and gets confused by faad reading junk before it resyncs - hence thinking the stream has changed to 44.1k.
mencoder may work, but the problem will be getting proper vsync with chunks of sound missing (though I haven't tried) and of course it's not really supported anymore.
I guess the best thing is to use transport streams - if very rarely you get a no sound issue with those it could be "an unlucky start" that confuses the player.
The nice thing about ts is that you can cut them around anyway with dd and don't have to worry about headers. You should use bs=188 to maintain packets as some players like vlc are fussy about that. So to fix an unlucky start you could just do something like -
dd if=in.ts of=out.ts bs=188 skip=2000
and hope you get a better start.
Though I've never seen it with tvh, very rarely when using tzap/dvbstream to record long ago, it was possible to end up with just audio and vid streams without PAT/PMT and vlc wouldn't play sound on these - but mplayer or mpc on windows would.
I still haven't looked at how tvh makes these mkv, if it's ffmpeg then maybe someone on their list would know in what way they are broken. Of course it may not happen with current ffmpeg.
As I said before I made a mkv with current ffmpeg and -acodec copy and it worked. It was obviously different from the sample though in that the aac as broadcast is in latm and that was preserved in my test, but the aac in the sample is not in latm so something has changed it.