Mailing List Archive

Failed radio recordings from dvb-t with 0.26-fixes
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.

Similarly for one 'recorded' while I was writing this:
47 40 00 13, 47 46 a4 10, 47 06 a6 13
Radio4Extra.

$ mythbackend --version
Please attach all output as a file in bug reports.
MythTV Version : 0.26.0-7.fc17 (v0.26.0-111-g3944ca9)
MythTV Branch : fixes/0.26
Network Protocol : 75
Library API : 0.26.20130225-1
QT Version : 4.8.4
Options compiled in:
linux release use_hidesyms using_alsa using_jack using_oss using_pulse
using_pulseoutput using_backend using_bindings_perl
using_bindings_python using_bindings_php using_crystalhd using_dvb
using_firewire using_frontend using_hdhomerun using_ceton using_hdpvr
using_iptv using_ivtv using_joystick_menu using_libcrypto
using_libdns_sd using_libfftw3 using_libxml2 using_libudf using_lirc
using_mheg using_opengl_video using_qtwebkit using_qtscript using_qtdbus
using_v4l2 using_x11 using_xrandr using_xv using_bindings_perl
using_bindings_python using_bindings_php using_mythtranscode
using_opengl using_vaapi using_vdpau using_ffmpeg_threads using_live
using_mheg using_libass using_libxml2 using_libudf


John P


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Failed radio recordings from dvb-t with 0.26-fixes [ In reply to ]
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.
>
> Similarly for one 'recorded' while I was writing this:
> 47 40 00 13, 47 46 a4 10, 47 06 a6 13
> Radio4Extra.
>
> $ mythbackend --version
> Please attach all output as a file in bug reports.
> MythTV Version : 0.26.0-7.fc17 (v0.26.0-111-g3944ca9)
> MythTV Branch : fixes/0.26
> Network Protocol : 75
> Library API : 0.26.20130225-1
> QT Version : 4.8.4
> Options compiled in:
> linux release use_hidesyms using_alsa using_jack using_oss using_pulse
> using_pulseoutput using_backend using_bindings_perl
> using_bindings_python using_bindings_php using_crystalhd using_dvb
> using_firewire using_frontend using_hdhomerun using_ceton using_hdpvr
> using_iptv using_ivtv using_joystick_menu using_libcrypto
> using_libdns_sd using_libfftw3 using_libxml2 using_libudf using_lirc
> using_mheg using_opengl_video using_qtwebkit using_qtscript using_qtdbus
> using_v4l2 using_x11 using_xrandr using_xv using_bindings_perl
> using_bindings_python using_bindings_php using_mythtranscode
> using_opengl using_vaapi using_vdpau using_ffmpeg_threads using_live
> using_mheg using_libass using_libxml2 using_libudf
>
>
> John P
>

I thought this might be because the recording profile had changed, but
it's set to 'normal' and should be ok.

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>

2013-04-24 09:22:16.477277 W Player(1): OpenFile() waiting on data
2013-04-24 09:22:16.527397 W
RingBuf(/mnt/f10store/myth/reca/1703_20130424081500.mpg): Peek()
requested 2048 bytes, but only returning 564
2013-04-24 09:22:16.527422 E Player(1): OpenFile(): Could not read
first 2048 bytes of '/mnt/f10store/myth/reca/1703_20130424081500.mpg'
2013-04-24 09:22:16.527433 E Player(1): Unable to open video file.
2013-04-24 09:22:36.557353 E playCtx: StartPlaying() Failed to start player
2013-04-24 09:22:36.775263 I Pulse: PulseAudio resume OK
2013-04-24 09:22:36.776006 I TV: Main UI disabled.
2013-04-24 09:22:36.776020 I TV: Entering main playback loop.
2013-04-24 09:22:36.788221 I ScreenSaverX11Private: DPMS Deactivated 1
2013-04-24 09:22:36.788820 I TV: Exiting main playback loop.
2013-04-24 09:22:36.810945 N Resuming idle timer




_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Failed radio recordings from dvb-t with 0.26-fixes [ In reply to ]
On Wed, 24 Apr 2013 09:28:56 +0100, John Pilkington <J.Pilk@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
> WatchingRecording2013-04-24 09:22:15.187369 I MythCoreContext:
> Connecting to backendserver: 192.168.1.4:6543 (try 1 of 1)2013-04-24
> 09:22:15.188105 I Using protocol version 752013-04-24 09:22:15.449126 I
> Pulse: PulseAudio suspend OK2013-04-24 09:22:15.524099 N AudioPlayer:
> Enabling Audio2013-04-24 09:22:15.524230 W
> RingBuf(/mnt/f10store/myth/reca/1703_20130424081500.mpg): Peek()
> requested 2048 bytes, but only returning 5642013-04-24 09:22:15.524245 W
> Player(1): OpenFile() waiting on data2013-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.
Re: Failed radio recordings from dvb-t with 0.26-fixes [ In reply to ]
On 24/04/13 11:21, Roger Siddons wrote:
> On Wed, 24 Apr 2013 09:28:56 +0100, John Pilkington <J.Pilk@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



_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Failed radio recordings from dvb-t with 0.26-fixes [ In reply to ]
On Wed, 24 Apr 2013 15:39:33 +0100, John Pilkington <J.Pilk@tesco.net>
wrote:
>
> 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...
>

FWIW I've been using 0.26 on DVB-T (incl Radio 4) for 5 months with no
significant issues (apart from 10833).

However your latter issue does remind me of one, possibly related,
incident (that I haven't got around to investigating properly):
Successive recordings of the last hour of CBeebies failed to play (video
buffer failed too many times) even though the filesize was good. The logs
said Myth couldn't find any video codec parameters, I believe. However
they would play fine whilst the recording was in progress. When my (3 min)
padding recorded the MHEG data at channel end it somehow 'corrupted' the
codec info so that the recording then became unplayable. Reducing the end
padding solved that problem. That's obviously not the cause of your 9:30am
failure but, to me, they raise questions about the 'new' ffmpeg in 0.26.
Their forums may provide some clues...
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Failed radio recordings from dvb-t with 0.26-fixes [ In reply to ]
On 24/04/13 22:03, Roger Siddons wrote:

>
> FWIW I've been using 0.26 on DVB-T (incl Radio 4) for 5 months with no
> significant issues (apart from 10833).

Yes, I had it on my laptop for several months and updated a home-build a
few times. The intention was to try it out there before switching the
main box from 0.25.3, and I had most of the things that bothered me
sorted out; there was no radio problem on that. Then it looked as if
disaster had struck and I made a series of large unpremeditated changes,
after which it seemed ok; but disk space was tight and I didn't check it
out thoroughly before making related changes on the main box. I ought
to check it now...
>
> However your latter issue does remind me of one, possibly related,
> incident (that I haven't got around to investigating properly):
> Successive recordings of the last hour of CBeebies failed to play (video
> buffer failed too many times) even though the filesize was good. The
> logs said Myth couldn't find any video codec parameters, I believe.
> However they would play fine whilst the recording was in progress. When
> my (3 min) padding recorded the MHEG data at channel end it somehow
> 'corrupted' the codec info so that the recording then became unplayable.
> Reducing the end padding solved that problem. That's obviously not the
> cause of your 9:30am failure but, to me, they raise questions about the
> 'new' ffmpeg in 0.26. Their forums may provide some clues...

Yes, I've seen this at both ends of the part-time channels. A
preliminary pass through mythDVBcut (Project-X based) almost always
fixes it, but I suppose that must depend on where in the recording it
finds its tables. It doesn't work on audio-only - and it won't expand a
564-byte recording into anything useful! Nor does it correct for the
switch to UTC, which only started making a difference here at the start
of this month. Luckily I only have to mentally subtract one hour...

Ho hum.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Failed radio recordings from dvb-t with 0.26-fixes [ In reply to ]
On Wed, 2013-04-24 at 15:39 +0100, John Pilkington wrote:
> On 24/04/13 11:21, Roger Siddons wrote:
> > >> 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.
That looks like the "no video stream keep buffering" (no writing) bug..
The first packet is a PSI/PAT..

Try:
dvbsnoop -if <filename> -s -ts


> 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...

I use these to parse ffprobe output:

strsearch="\<$ff_aac_latm"
temp_str=`ffprobe -i $thefile 2>&1 | grep 'Audio' | grep $language |
grep $strsearch `
streams_latm_pid=( `echo $temp_str | awk -F'[' '{ print $2 }' | awk
-F']' '{ print$1 }' ` )
streams_latm_index=( `echo $temp_str | awk -F'#0:' '{ print $2 }' | awk
-F'[' '{ print$1 }' ` )

where language="eng" & ff_aac_latm="aac_latm"


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Failed radio recordings from dvb-t with 0.26-fixes [ In reply to ]
On Wed, 2013-04-24 at 23:02 +0100, John Pilkington wrote:
> On 24/04/13 22:03, Roger Siddons wrote:

> Yes, I've seen this at both ends of the part-time channels. A
> preliminary pass through mythDVBcut (Project-X based) almost always
> fixes it, but I suppose that must depend on where in the recording it
> finds its tables. It doesn't work on audio-only - and it won't expand a
> 564-byte recording into anything useful! Nor does it correct for the
> switch to UTC, which only started making a difference here at the start
> of this month. Luckily I only have to mentally subtract one hour...
>
> Ho hum.
>
The later ffmpeg/ffprobe like to have the analyse_duration extended to
3000000.
This is required because (ffmpeg has changed &) mythtv does not start
recording on a "proper" start packet. So there is a varying amount to
undecode-able junk up to the first SPS & then decode-able AU packets.

Brett


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Failed radio recordings from dvb-t with 0.26-fixes [ In reply to ]
On 24/04/13 23:02, John Pilkington wrote:
> On 24/04/13 22:03, Roger Siddons wrote:
>
>>
>> FWIW I've been using 0.26 on DVB-T (incl Radio 4) for 5 months with no
>> significant issues (apart from 10833).
>
> Yes, I had it on my laptop for several months and updated a home-build a
> few times. The intention was to try it out there before switching the
> main box from 0.25.3, and I had most of the things that bothered me
> sorted out; there was no radio problem on that. Then it looked as if
> disaster had struck and I made a series of large unpremeditated changes,
> after which it seemed ok; but disk space was tight and I didn't check it
> out thoroughly before making related changes on the main box. I ought
> to check it now...

I have. It has the same problem. Live radio plays, recordings just sit
there, apparently recording as expected, but the file stays at 564
bytes. This is Scientific Linux 6.4 running MythTV 0.26 from rpmfusion,
same git-number as the Fedora 17 box, but with v4l support from ATrpms
packages; the media-build script is still failing for me.

I hoped I might get some idea of when this started, but the last radio
recording listed on the laptop was made last September and my first
installation of 0.26 was in mid-December. So much for the intention to
check everything out...

John P


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Failed radio recordings from dvb-t with 0.26-fixes [ In reply to ]
John Pilkington wrote:
> On 24/04/13 23:02, John Pilkington wrote:
>> On 24/04/13 22:03, Roger Siddons wrote:
>>
>>>
>>> FWIW I've been using 0.26 on DVB-T (incl Radio 4) for 5 months
>>> with no
>>> significant issues (apart from 10833).
>>
>> Yes, I had it on my laptop for several months and updated a
>> home-build a
>> few times. The intention was to try it out there before switching
>> the
>> main box from 0.25.3, and I had most of the things that bothered
>> me
>> sorted out; there was no radio problem on that. Then it looked
>> as if
>> disaster had struck and I made a series of large unpremeditated
>> changes,
>> after which it seemed ok; but disk space was tight and I didn't
>> check it
>> out thoroughly before making related changes on the main box. I
>> ought
>> to check it now...
>
> I have. It has the same problem. Live radio plays, recordings just
> sit
> there, apparently recording as expected, but the file stays at 564
> bytes. This is Scientific Linux 6.4 running MythTV 0.26 from
> rpmfusion,
> same git-number as the Fedora 17 box, but with v4l support from
> ATrpms
> packages; the media-build script is still failing for me.
>
> I hoped I might get some idea of when this started, but the last
> radio
> recording listed on the laptop was made last September and my first
> installation of 0.26 was in mid-December. So much for the intention
> to
> check everything out...
>
> John P

This is a known bug logged against mythtv. It's fixed in 0.26 fixes.
Since rpmfusion didn't have a version that fixes it, I ended up
rolling my own from 0.26 fixes git download, and that fixes it.
Without it, every DVB-T (freeview UK) recording fails with the same
symptoms you report, namely the recording starts, but results in a
file of a few hundred bytes only. It would appear that there is
still no rpmfusion update available with this fix included.

I'm currently running
[mike@puzzle ~]$ mythfrontend --version
Please attach all output as a file in bug reports.
MythTV Version : v0.26.0-138-g69cd78b-dirty
MythTV Branch : fixes/0.26
Network Protocol : 75
Library API : 0.26.20130225-1
QT Version : 4.8.4
Options compiled in:
linux profile use_hidesyms using_alsa using_oss using_pulse
using_pulseoutput using_backend using_bindings_perl
using_bindings_python using_bindings_php using_dvb using_frontend
using_hdhomerun using_ceton using_hdpvr using_iptv using_ivtv
using_joystick_menu using_lirc using_mheg using_opengl_video
using_qtwebkit using_qtscript using_qtdbus using_v4l2 using_x11
using_xrandr using_xv using_bindings_perl using_bindings_python
using_bindings_php using_mythtranscode using_opengl using_vdpau
using_ffmpeg_threads using_live using_mheg

--
Mike Holden


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Failed radio recordings from dvb-t with 0.26-fixes [ In reply to ]
On 25/04/13 21:21, Mike Holden wrote:
> John Pilkington wrote:
>> On 24/04/13 23:02, John Pilkington wrote:
>>> On 24/04/13 22:03, Roger Siddons wrote:
>>>
>>>>
>>>> FWIW I've been using 0.26 on DVB-T (incl Radio 4) for 5 months
>>>> with no
>>>> significant issues (apart from 10833).
>>>
>>> Yes, I had it on my laptop for several months and updated a
>>> home-build a
>>> few times. The intention was to try it out there before switching
>>> the
>>> main box from 0.25.3, and I had most of the things that bothered
>>> me
>>> sorted out; there was no radio problem on that. Then it looked
>>> as if
>>> disaster had struck and I made a series of large unpremeditated
>>> changes,
>>> after which it seemed ok; but disk space was tight and I didn't
>>> check it
>>> out thoroughly before making related changes on the main box. I
>>> ought
>>> to check it now...
>>
>> I have. It has the same problem. Live radio plays, recordings just
>> sit
>> there, apparently recording as expected, but the file stays at 564
>> bytes. This is Scientific Linux 6.4 running MythTV 0.26 from
>> rpmfusion,
>> same git-number as the Fedora 17 box, but with v4l support from
>> ATrpms
>> packages; the media-build script is still failing for me.
>>
>> I hoped I might get some idea of when this started, but the last
>> radio
>> recording listed on the laptop was made last September and my first
>> installation of 0.26 was in mid-December. So much for the intention
>> to
>> check everything out...
>>
>> John P
>
> This is a known bug logged against mythtv. It's fixed in 0.26 fixes.
> Since rpmfusion didn't have a version that fixes it, I ended up
> rolling my own from 0.26 fixes git download, and that fixes it.
> Without it, every DVB-T (freeview UK) recording fails with the same
> symptoms you report, namely the recording starts, but results in a
> file of a few hundred bytes only. It would appear that there is
> still no rpmfusion update available with this fix included.
>
> I'm currently running
> [mike@puzzle ~]$ mythfrontend --version
> Please attach all output as a file in bug reports.
> MythTV Version : v0.26.0-138-g69cd78b-dirty
> MythTV Branch : fixes/0.26
> Network Protocol : 75
> Library API : 0.26.20130225-1
> QT Version : 4.8.4

Yes, thanks. It looks like http://code.mythtv.org/trac/ticket/11442,
fix committed to 0.26-fixes on 7 March,

http://code.mythtv.org/trac/changeset/77259c5a504d1edb79d8c9d4c6f45265b365a818/mythtv

My apologies for starting the thread without a proper check.

And perhaps I should add that the stock SL6 kernel does work, for me,
with an older, SD-only usb stick, 704J, although Project-X has always
seen packets out of sequence from this device and there are often
noticeable video artefacts. The HD/SD 290e gives excellent results, but
needs the extra v4l support.

Only one tuner from the twin-tuner 704J is recognised, with great
difficulty, by mythtvsetup under the current Fedora 17 kernel,
3.8.4-102.fc17.x86_64, and results have been poor. Ticket #11058 etc.

John P


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Failed radio recordings from dvb-t with 0.26-fixes (SOLVED) [ In reply to ]
> Yes, thanks. It looks like http://code.mythtv.org/trac/ticket/11442,
> fix committed to 0.26-fixes on 7 March,
>
> http://code.mythtv.org/trac/changeset/77259c5a504d1edb79d8c9d4c6f45265b365a818/mythtv
>
>
> My apologies for starting the thread without a proper check.
>
> And perhaps I should add that the stock SL6 kernel does work, for me,
> with an older, SD-only usb stick, 704J, although Project-X has always
> seen packets out of sequence from this device and there are often
> noticeable video artefacts. The HD/SD 290e gives excellent results, but
> needs the extra v4l support.
>
> Only one tuner from the twin-tuner 704J is recognised, with great
> difficulty, by mythtvsetup under the current Fedora 17 kernel,
> 3.8.4-102.fc17.x86_64, and results have been poor. Ticket #11058 etc.
>
> John P
>

Let me tie up this thread by thanking Richard Shaw for a new rpmfusion
build. I have it on both my systems, SL6.i686 and f17.x86_64. I can
make recordings from radio on both, and MythCenter-wide looks better
too. I don't think the rpms have made it to the repo yet but I
understand they should be on their way.

2013-04-28 11:18:27.926062 C mythfrontend version: fixes/0.26
[0.26.0-8.fc17 (v0.26.0-149-g5f45c0b)] www.mythtv.org
2013-04-28 11:18:27.926073 C Qt version: compile: 4.8.4, runtime: 4.8.4

..and just as food for thought... (1005 is tv, 1703 is radio)

2013-04-28 12:55:25.331151 W
TFW(/mnt/sam1/recb/1005_20130428111600.mpg:81): write(61476) cnt 58
total 3543988 -- took a long time, 2803 ms
2013-04-28 12:55:30.867105 I Reschedule requested for MATCH 0 0 0 -
EITScanner
2013-04-28 12:55:34.335860 I Scheduled 86 items in 3.4 = 2.00 match +
1.18 check + 0.25 place
2013-04-28 12:55:50.098864 W
TFW(/mnt/sam1/recb/1005_20130428111600.mpg:81): write(65424) cnt 66
total 4110244 -- took a long time, 11257 ms
2013-04-28 12:55:50.098906 W
TFW(/mnt/sam1/recb/1703_20130428110400.mpg:80): write(44744) cnt 30
total 1940724 -- took a long time, 10997 ms
2013-04-28 12:55:52.471404 W
TFW(/mnt/sam1/recb/1005_20130428111600.mpg:81): write(63920) cnt 77
total 4844572 -- took a long time, 2373 ms
2013-04-28 12:55:52.471604 W
TFW(/mnt/sam1/recb/1703_20130428110400.mpg:80): write(65424) cnt 36
total 2293976 -- took a long time, 2373 ms

John P




_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users