Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[NickR]

Live and time-shifted TV are fine, but when I record any program via schedule, the resulting .ts file has no audio. 
I recorded the same program on two different machines using JRiver and Media Portal 2 (MP2) for comparison, and then used ffprobe to examine the results.  The first output is from MP2, the second from JRiver, with header and "Program …" line removed...

tail --lines=+12 C:\TEMP\FFProbe_A.txt | grep -ivE "^  Program "
[mpeg2video @ 000001bc3808e980] Invalid frame dimensions 0x0.
    Last message repeated 12 times
[mpegts @ 000001bc3808c580] start time for stream 2 is not set in estimate_timings_from_pts
[mpegts @ 000001bc3808c580] start time for stream 3 is not set in estimate_timings_from_pts
[mpegts @ 000001bc3808c580] PES packet size mismatch
[mpegts @ 000001bc3808c580] Could not find codec parameters for stream 2 (Audio: mp3 (mp3float) ([3][0][0][0] / 0x0003), 0 channels, fltp): unspecified frame size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, mpegts, from '\\hp8460p\d\Recorded TV\House\House - S2E13 - Skin Deep.ts':
  Duration: 00:45:52.77, start: 0.255500, bitrate: 1605 kb/s
    Stream #0:0[0x30]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, progressive), 544x576 [SAR 32:17 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
    Stream #0:1[0x40](eng): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 128 kb/s
    Stream #0:2[0x41](eng): Audio: mp3 ([3][0][0][0] / 0x0003), 0 channels, fltp (visual impaired) (descriptions) (dependent)
    Stream #0:3[0x50](eng): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
===================================================
tail --lines=+12 C:\TEMP\FFProbe_B.txt | grep -ivE "^  Program "
[mpeg2video @ 000001836d464040] Invalid frame dimensions 0x0.
    Last message repeated 2 times
[mpegts @ 000001836d45c580] start time for stream 1 is not set in estimate_timings_from_pts
[mpegts @ 000001836d45c580] start time for stream 2 is not set in estimate_timings_from_pts
[mpegts @ 000001836d45c580] start time for stream 3 is not set in estimate_timings_from_pts
[mpegts @ 000001836d45c580] Could not find codec parameters for stream 1 (Audio: mp3 (mp3float) ([3][0][0][0] / 0x0003), 0 channels, fltp): unspecified frame size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
[mpegts @ 000001836d45c580] Could not find codec parameters for stream 2 (Audio: mp3 (mp3float) ([3][0][0][0] / 0x0003), 0 channels, fltp): unspecified frame size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, mpegts, from '\\hp6550b\d\TV Recording\House - S02E13 - Skin Deep.ts':
  Duration: 00:46:40.12, start: 32344.814600, bitrate: 1455 kb/s
    Stream #0:0[0x19c1]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, progressive), 544x576 [SAR 32:17 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
    Stream #0:1[0x19c2](eng): Audio: mp3 ([3][0][0][0] / 0x0003), 0 channels, fltp
    Stream #0:2[0x19c3](eng): Audio: mp3 ([3][0][0][0] / 0x0003), 0 channels, fltp (visual impaired) (descriptions) (dependent)
    Stream #0:3[0x19c6](eng): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)

I don't know if these analytics help, but it looks to me as though there are differences specific to the audio stream, i.e. missing codec parameters.

[Yaobing]

Please try the latest build, MC25.0.75, and see if there is any difference.

There has been no changes in MC that could result in this behavior.  Did the problem occur only recently?  If the TV station changed their parameters, this kind of problem could occur.  Try re-scanning your channels.

[NickR]

As you said there had been no changes that could result in this behaviour, I'm reluctant to go through whole download / re-install / test / …, especially when I think I may have found a workaround.
I tried ffprobe on a few more files, and found that channel 72 actually recorded the sound OK.  The only real difference between this channel and others that had a problem was that the Audio PID was exactly 1 greater than the Video PID, whereas for the problematic channels there was a difference of 2, or in some instances 5, especially when the Audio format was not MPEG-1.
So I went through all the channels, making all the formats MPEG-2 Video and MPEG-1 Audio, and changing the Audio PID to be the same as the Video PID plus 1, and Voila, (at least one) .ts file tested OK on an updated channel.
I'm not sure this will work for all channels, but it seems like a step in the right direction.
The question now is, why did the channel scan assign the incorrect Audio PIDs?

[Yaobing]

The question now is, why did the channel scan assign the incorrect Audio PIDs?

That was why I suggested that you re-scan your channels.  Is your current channel set recently scanned?  If not, maybe the TV stations made changes and re-scanning should pick up the new values.

[NickR]

I should have made it clearer - each time I rescan, lots of the Audio formats get set to "AAC LATM" with Audio PID 5 more than Video PID.  The last time, which was just before I made the mass edit today, I even checked the option for a slower more accurate scan.  I'm quite confident that if I did a rescan now, it would just mess things up so that I'd have to re-do the mass edit.
You seemed to think recent updates unlikely to affect this area of the program's behaviour.  On the other hand, maybe it was fixed in version 72 (item 3). 
I'll download and check version 75 and let you know if it's fixed.

[NickR]

Doh!  I wish I'd checked for new versions before I posted - the latest version seems to have corrected the problem I described so this can be closed. 
ffprobe was useful for analysis though, huh?