[mythtv] http://code.mythtv.org/trac/ticket/10428 not fixed completely?

Wed Mar 6 14:05:50 UTC 2013

On Tue, Mar 5, 2013 at 4:46 PM, Dan Wilga <
mythtv-dev2 at dwilga-linux1.amherst.edu> wrote:

> On 3/5/13 3:54 PM, Thomas Börkel wrote:
>
>> HI!
>>
>> It seems, this is not fixed. Watching a recording (not really Live TV)
>> while it is being recorded, 10-15s behind, I get lots of those messages
>> from the ticket and also these:
>>
>> "RingBuf(/mythtv/backend/**video/recordings/2222_**20130305183000.mpg):
>> Taking too long to be allowed to read.."
>>
>> Using 0.26 fixes from February 2013.
>>
> I don't often do this, but this past weekend I tried to do so for two
> different recordings and was surprised at how poorly it performed. This
> used to "just work".
>
> It would take at least 60 seconds to start playback and, once it did play,
> jumping forward would sometimes cause playback to halt for 2-3 minutes.
> Several times MFE bus errored. In my case, it did not matter how close to
> the end of the recording was being played back; I was at least 45 minutes
> back from "live" when the troubles began. These are some of the many log
> messages:
>
> Mar  2 17:33:58  N CoreContext mythplayer.cpp:2093 (PrebufferEnoughFrames)
> Player(0): Waited 19104ms for video buffers AAAAAAAAAAAAAA
> Mar  2 17:33:58  N CoreContext mythplayer.cpp:2093 (PrebufferEnoughFrames)
> Player(0): Waited 19205ms for video buffers AAAAAAAAAAAAAA
> Mar  2 17:33:58  N CoreContext mythplayer.cpp:2093 (PrebufferEnoughFrames)
> Player(0): Waited 19307ms for video buffers AAAAAAAAAAAAAA
> Mar  2 17:33:58  I Decoder ringbuffer.cpp:1098 (WaitForAvail)
> RingBuf(myth://192.168.64.1:**6543/3180_20130302205900.mpg<http://192.168.64.1:6543/3180_20130302205900.mpg>):
> Waited 0.2 seconds for data #012#011#011#011to become a
> vailable... 0 < 32768
> Mar  2 17:33:58  N CoreContext mythplayer.cpp:2093 (PrebufferEnoughFrames)
> Player(0): Waited 19408ms for video buffers AAAAAAAAAAAAAA
> Mar  2 17:33:58  N CoreContext mythplayer.cpp:2093 (PrebufferEnoughFrames)
> Player(0): Waited 19511ms for video buffers AAAAAAAAAAAAAA
> Mar  2 17:33:58  I Decoder ringbuffer.cpp:1098 (WaitForAvail)
> RingBuf(myth://192.168.64.1:**6543/3180_20130302205900.mpg<http://192.168.64.1:6543/3180_20130302205900.mpg>):
> Waited 0.5 seconds for data #012#011#011#011to become a
> vailable... 0 < 32768
> Mar  2 17:33:58  N CoreContext mythplayer.cpp:2093 (PrebufferEnoughFrames)
> Player(0): Waited 19612ms for video buffers AAAAAAAAAAAAAA
> Mar  2 17:33:59  N CoreContext mythplayer.cpp:2093 (PrebufferEnoughFrames)
> Player(0): Waited 19714ms for video buffers AAAAAAAAAAAAAA
> Mar  2 17:33:59  N CoreContext mythplayer.cpp:2093 (PrebufferEnoughFrames)
> Player(0): Waited 19817ms for video buffers AAAAAAAAAAAAAA
> Mar  2 17:33:59  N CoreContext mythplayer.cpp:2093 (PrebufferEnoughFrames)
> Player(0): Waited 19921ms for video buffers AAAAAAAAAAAAAA
> Mar  2 17:33:59  E CoreContext mythplayer.cpp:2116 (PrebufferEnoughFrames)
> Player(0): Waited too long for decoder to fill video buffers. Exiting..
> Mar  2 17:33:59  I CoreContext tv_play.cpp:2155 (HandleStateChange) TV:
> Attempting to change from WatchingRecording to None
> Mar  2 17:33:59  I Decoder ringbuffer.cpp:1098 (WaitForAvail)
> RingBuf(myth://192.168.64.1:**6543/3180_20130302205900.mpg<http://192.168.64.1:6543/3180_20130302205900.mpg>):
> Waited 1.0 seconds for data #012#011#011#011to become available... 0 < 32768
> Mar  2 17:33:59  W CoreContext mythplayer.cpp:2984 (PauseDecoder)
> Player(0): Waited 100ms for decoder to pause
> Mar  2 17:33:59  W CoreContext mythplayer.cpp:2984 (PauseDecoder)
> Player(0): Waited 100ms for decoder to pause
> Mar  2 17:33:59  W CoreContext mythplayer.cpp:2984 (PauseDecoder)
> Player(0): Waited 100ms for decoder to pause
> Mar  2 17:33:59  W CoreContext mythplayer.cpp:2984 (PauseDecoder)
> Player(0): Waited 100ms for decoder to pause
> Mar  2 17:33:59  W CoreContext mythplayer.cpp:2984 (PauseDecoder)
> Player(0): Waited 100ms for decoder to pause
>
> I don't necessarily think the ticket pointed to by the OP is relevant, due
> to the fact that it happened far back from "live". In my case, the
> recording device was a PVR-350, in case that matters.
>
> MythTV Version : v0.26.0-104-gc3fff6e
> MythTV Branch : fixes/0.26
> Network Protocol : 75
> Library API : 0.26.20130112-1
> QT Version : 4.7.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_libcrypto
> using_libdns_sd using_libfftw3 using_libxml2 using_lirc using_mheg
> using_opengl_video using_qtwebkit using_qtscript 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 using_libxml2
>
>
I know everyone hates 'me too' replies, but....me too. I did a head update
on the weekend, since then playing SD recordings from a WinTV USB-PVR (same
as a PVR-x50, basically) has been terrible. Startup takes about 30 seconds,
and if you try and skip more than about 30 seconds, it will hang. Could be
unrelated since you are on a much older version than me, but the symptoms
are eerily similar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-dev/attachments/20130306/e4b47541/attachment.html>