[mythtv-users] Failed radio recordings from dvb-t with 0.26-fixes

[John Pilkington]

On 24/04/13 11:21, Roger Siddons wrote:
> On Wed, 24 Apr 2013 09:28:56 +0100, John Pilkington <J.Pilk at tesco.net>
> wrote:
>
>  > On 23/04/13 13:42, John Pilkington wrote:
>  >> Hi: After my upgrade to 0.26-fixes for Fedora 17 from rpmfusion I've had
>  >> three failed radio recordings from a normally reliable tuner. The
>  >> console log shows nothing unusual. Video recordings have been ok, and
>  >> live radio playback works.
>  >>
>  >> The file length is actually 564 bytes; 3*188 bytes or 3 packets.
>  >> I was going to paste the entire thing here, but the line wrapping spoils
>  >> it. The packet heads are 47 40 00 15, 47 45 14 12, 47 05 16 3f
>  >> That was Radio4.
>
> <snip>
>
>  >
>  > This is console output on attempting to play a 'recording' in progress:
>  >
>  > 2013-04-24 09:22:15.184850 I TV: Attempting to change from None to
>  > WatchingRecording
>  > 2013-04-24 09:22:15.187369 I MythCoreContext: Connecting to backend
>  > server: 192.168.1.4:6543 (try 1 of 1)
>  > 2013-04-24 09:22:15.188105 I Using protocol version 75
>  > 2013-04-24 09:22:15.449126 I Pulse: PulseAudio suspend OK
>  > 2013-04-24 09:22:15.524099 N AudioPlayer: Enabling Audio
>  > 2013-04-24 09:22:15.524230 W
>  > RingBuf(/mnt/f10store/myth/reca/1703_20130424081500.mpg): Peek()
>  > requested 2048 bytes, but only returning 564
>  > 2013-04-24 09:22:15.524245 W Player(1): OpenFile() waiting on data
>  > 2013-04-24 09:22:15.574358 W
>  > RingBuf(/mnt/f10store/myth/reca/1703_20130424081500.mpg): Peek()
>  > requested 2048 bytes, but only returning 564
>  >
>
> <snip>
>
> Seems unlikely but http://code.mythtv.org/trac/ticket/10833 might be of
> interest regarding UK radio/ringbuffer issues. 0.26/fixes does/did have
> some ringbuffer optimisations that don't work well with UK radio because
> the detected stream rate isn't correct.
>
> IIRC I had no problem with recording - those issues showed up on
> playback only. However YMMV or recent backports may have exacerbated the
> problem - I haven't updated for a while.
>

Hmm, yes.  I often regret failure to heed 'if it ain't broke....' 
0.25.3 Just Worked - eventually.

Something else that is broke now - sometimes - is Audio track selection 
in my mythDVBcut script.  This is new.  I use

mythffmpeg -i "filename" 2>&1 | grep -C 4 Video > tmp.txt

to find out what's there and grep for Audio  and Video.  Now I'm seeing

> [mpegts @ 0x185e140] Could not find codec parameters (Audio: mp3, 0 channels, s16)
> [NULL @ 0x1862280] start time is not set in estimate_timings_from_pts
> Input #0, mpegts, from '1072_20130424093100.mpg':
>   Duration: 00:26:57.37, start: 51109.892644, bitrate: 1880 kb/s
>     Stream #0:0[0x1ab1]: Video: mpeg2video (Main), yuv420p, 544x576 [SAR 32:17 DAR 16:9], 15000 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
>     Stream #0:1[0x1ab2](eng): Audio: mp2, 48000 Hz, stereo, s16, 128 kb/s
>     Stream #0:2[0x1ab3](eng): Audio: mp3, 0 channels, s16
>     Stream #0:3[0x1ab6](eng): Subtitle: dvb_subtitle
> At least one output file must be specified

and the complaint in the first line, which I haven't seem before, breaks 
it.  Just changing the grep -C 4 may fix it.   It seems quite possible 
that the radio recording failure has a similar origin...

John P