[mythtv-users] Live TV: Too fast now ?

Sun Aug 17 16:16:10 UTC 2014

On 17/08/14 16:11, Roger Siddons wrote:
> I've just got around to trying out 0.27 (clean install of Mythbuntu 
> 14.04.1/0.27.3) and obviously wanted to check out JYA's Live TV 
> improvements, even though we don't use it very often.
>
> *When* it works, it's a great improvement - channel changes are fast & 
> reliable. So thanks JYA for all your hard work.
>
> However, overall the WAF factor is worse because;
>
> 1. When starting Live TV it fails 60% of the time - "Could not open 
> decoder"
>
> 2. When it works, switching tuner source fails 90% of the time. 
> Although a feature of minor importance, I find it useful for checking 
> all tuners are working properly.
>
> The debug/playback frontend log of successfully starting Live TV, then 
> switching source is at http://paste.ubuntu.com/8071453/.
>
> It appears as though the frontend is quick to abort Live TV because 
> ffmpeg can't determine the (audio?) codec. However this failure did 
> produce a (damaged) recording that played fine from 'Watch Recordings' 
> - all 2.5 s of it.
>
> $ mythffmpeg -i /var/lib/mythtv/livetv/1004_20140817130826.mpg
>
> ffmpeg version 1.2.7 Copyright (c) 2000-2014 the FFmpeg developers
> built on Aug 11 2014 23:51:16 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
> configuration: --compile-type=profile --prefix=/usr --runprefix=/usr 
> --disable-mythlogserver --enable-crystalhd --enable-lirc 
> --enable-audio-alsa --enable-audio-oss --enable-dvb --enable-ivtv 
> --enable-firewire --enable-joystick-menu --with-bindings=perl 
> --enable-ffmpeg-pthreads --enable-pic 
> --perl-config-opts='INSTALLDIRS=vendor' --enable-libvpx --enable-sdl 
> --enable-libmp3lame --enable-libx264 --enable-opengl-video 
> --enable-vaapi --enable-vdpau
> libavutil 52. 18.100 / 52. 18.100
> libavcodec 54. 92.100 / 54. 92.100
> libavformat 54. 63.104 / 54. 63.104
> libavdevice 54. 3.103 / 54. 3.103
> libavfilter 3. 42.103 / 3. 42.103
> libswscale 2. 2.100 / 2. 2.100
> libswresample 0. 17.102 / 0. 17.102
> libpostproc 52. 2.100 / 52. 2.100
> [dvbsub @ 0xee09a0] Invalid extradata, subtitle streams may be combined!
> [mpegts @ 0xedba20] write_section_data: PID 0x898 CRC error
> [mpeg2video @ 0xede980] 0x0 is invalid
> Last message repeated 19 times
> [mpegts @ 0xedba20] PES packet size mismatch
> Last message repeated 1 times
> [NULL @ 0xee09a0] start time is not set in estimate_timings_from_pts
> [NULL @ 0xee25c0] start time is not set in estimate_timings_from_pts
> [mpegts @ 0xedba20] write_section_data: PID 0x898 CRC error
> Last message repeated 2 times
> [mpegts @ 0xedba20] PES packet size mismatch
> Last message repeated 1 times
> Input #0, mpegts, from '/var/lib/mythtv/livetv/1004_20140817130826.mpg':
> Duration: 00:00:02.53, start: 70302.141778, bitrate: 3257 kb/s
> Stream #0:0[0x44d]: Video: mpeg2video (Main), yuv420p, 720x576 [SAR 
> 64:45 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
> Stream #0:1[0x44e](eng): Audio: mp2, 48000 Hz, stereo, s16p, 192 kb/s
> Stream #0:2[0x44f](eng): Audio: mp2, 48000 Hz, mono, s16p, 64 kb/s
> Stream #0:3[0x46b](eng): Subtitle: dvb_subtitle
> Stream #0:4[0x898]: Data: dsmcc_b
>
> I'm guessing this is because my old tuners (KWorld UB499-2T & 
> AverMedia 771 on UK OTA) are too slow to tune/settle and ffmpeg can't 
> interpret the garbage they start up with when there's so little data. 
> However the tuners are reliable and do produce perfect recordings and 
> so I'm looking for a way to slow down Live TV's startup or make it 
> more tolerant.
>
> A "DVB tuning delay" of 6000 ms (poked manually as mythtv-setup is 
> still broken) doesn't have any effect (except it waits 6s before 
> failing) so I presume the extra delay doesn't produce any more/better 
> data. Interestingly this only seems to be respected on Live TV 
> start-up: switching input source to a tuner with a tuning delay set 
> fails quickly with no delay.
>
> For "Quick tuning":  "Always" seems to be better than "Never" but 
> doesn't solve the issue.
>
> Likewise "Wait for Seq Header: Off" seems to reduce the failure rate, 
> but not significantly.
>
> So, questions:
>
> 1. Are there any other settings that would have an impact ?
>
> 2. Live TV always appears to check RAM for 1500 ms before checking the 
> file. Are there any settings/ways to increase this ?
>
> 3. Is it feasible/desirable for Live TV to re-examine the file 
> periodically before giving up ? If the file exists/is growing then 
> isn't there a chance that ffmpeg might eventually succeed. A long 
> pause is preferable to a failure. And if you're trying to watch Live 
> TV with a duff tuner then a delay of 10s before raising an error 
> doesn't seem unreasonable to me.
>
> 4. What's the best way to inspect the tuner data, ie. determine why 
> ffmpeg isn't happy ? Would ProjectX help ?
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
Have seen this on 0.28pre as well.

Try this to get into the mythtv-backend from a terminal

sudo service mythtv-backend stop

mythtv-setup.real


In the capture card screen for each tuner

change signal timeout to 7000  (default is 1000)
change tuning tmeout to 10000 (default is 3000)
set tuning delay back to 0

Now exit the backed and restart it

sudo service mythtv-backend start


Mike


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20140817/7c57b51a/attachment.html>