<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 11/19/2013 12:42 PM, Jim Stichnoth wrote:<br>
<blockquote
cite="mid:CAF5-Jox4b+188BCJpD6vTKmhO+SNOO7pwAn3o8oei5KNh_qomg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Sun, Nov 17, 2013 at 6:04 PM, Dave
Hill <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:myth@davidrhill.com" target="_blank">myth@davidrhill.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
I'm running the Mythbuntu 12.04 with the latest
0.27-fixes. My backend is a dual-core phenom II w/4GB ram
and the recordings are in their own 1.5TB partition with
100GB kept free. It has a HDPVR for recording from my
STB. My frontend is a nvidia ION system with the
recordings partition mounted over NFS (not sure if that is
relevant). I generally do not have any problems with this
setup other than this.<br>
<br>
I have been seeing this problem primarily when watching
NFL football games on Sundays. It only happens if the
recording is in progress. It doesn't seem to matter if I
am watching 2 hours or 5 minutes or 30 seconds behind the
current time. The picture freezes during playback and
eventually exits with video frame buffering failure. When
it happens, it continues to happen after I restart
playback, perhaps with 2-10 minutes of playtime between
freezes. Rebooting the frontend machine has worked most
of the time, though in one instance, I needed to reboot
the backend as well to clear it up.<br>
<br>
At the time of the failure, I see this in the mythfrontend
log:<br>
<br>
Nov 17 17:54:48 dhliv mythfrontend.real:
mythfrontend[6857]: I Decoder ringbuffe<br>
r.cpp:1098 (WaitForAvail) RingBuf(/storage/recordings/2786_20131117212400.mpg):<br>
Waited 0.2 seconds for data #012#011#011#011to become
available... 0 < 32768<br>
Nov 17 17:54:48 dhliv mythfrontend.real:
mythfrontend[6857]: N CoreContext mythp<br>
layer.cpp:2130 (PrebufferEnoughFrames) Player(l): Waited
102ms for video buffers<br>
AAAAAAAAAAAAALff<br>
<br>
... then a bunch of similar messages with the "waited"
time ticking up till it reaches 20 seconds:<br>
<br>
Nov 17 17:55:08 dhliv mythfrontend.real:
mythfrontend[6857]: N CoreContext mythp<br>
layer.cpp:2130 (PrebufferEnoughFrames) Player(l): Waited
19932ms for video buffe<br>
rs AAAAAAAAAAAAALff<br>
Nov 17 17:55:08 dhliv mythfrontend.real:
mythfrontend[6857]: E CoreContext mythp<br>
layer.cpp:2153 (PrebufferEnoughFrames) Player(l): Waited
too long for decoder to<br>
fill video buffers. Exiting..<br>
Nov 17 17:55:08 dhliv mythfrontend.real:
mythfrontend[6857]: I CoreContext tv_pl<br>
ay.cpp:2198 (HandleStateChange) TV: Attempting to change
from WatchingRecording<br>
to None<br>
<br>
<br>
In the mythbackend log around the same time, I see this:<br>
<br>
Nov 17 17:52:14 davetv mythbackend: mythbackend[2199]: I
ProcessRequest recorder<br>
s/recorderbase.cpp:457 (GetKeyframeDurations)
RecBase[5](/dev/video5): GetKeyfra<br>
meDurations(308350,9223372036854775807,#65) out of 2475<br>
Nov 17 17:52:43 davetv mythbackend: mythbackend[2199]: N
Expire autoexpire.cpp:2<br>
64 (CalcParams) AutoExpire: CalcParams(): Max required
Free Space: 82.0 GB w/fre<br>
q: 15 min<br>
Nov 17 17:54:30 davetv mythbackend: mythbackend[2199]: E
ProcessRequest programinfo.cpp:2358 (GetPlaybackURL)
ProgramInfo(2705_20131028005900.mpg): GetPlaybackURL:
'2705_20131028005900.mpg' should be local, but it can not
be found.<br>
Nov 17 17:54:30 davetv mythbackend: mythbackend[2199]: I
PreviewGeneratorQueue mythdbcon.cpp:409
(PurgeIdleConnections) New DB connection, total: 15<br>
Nov 17 17:55:43 davetv mythbackend: mythbackend[2199]: I
ProcessRequest mainserver.cpp:1420 (HandleAnnounce)
MainServer::ANN Playback<br>
Nov 17 17:55:43 davetv mythbackend: mythbackend[2199]: I
ProcessRequest mainserver.cpp:1422 (HandleAnnounce)
adding: dhliv as a client (events: 0)<br>
<br>
<br>
Watching 'top' during the failure on the backend, I see
that it is showing 10-15% idle time, with 100% of one of
the cores being used by mythcommflag.<br>
<br>
Does anyone else have similar problems? What other
information should I gather to help diagnose it?<br>
<br>
</blockquote>
<div>It doesn't happen to me. I have no problems with
watching in-progress recording from the HDPVR or HDHR.</div>
<div><br>
</div>
<div>The backend messages you excerpted are unremarkable.</div>
<div><br>
</div>
<div>Can you try not using NFS - let it communicate the file
through the myth protocol - and see if that changes
anything?</div>
<div><br>
</div>
<div>Jim</div>
</div>
</div>
</div>
<br>
</blockquote>
I believe I was running without NFS at first when the problem
started and I thought NFS mounting the recordings might help. But I
can certainly try it again and see if I see any different, more
interesting messages.<br>
<br>
It happened again last night and stopping commercial flagging seemed
to clear it up. After that, it played smoothly for the rest of the
game. It seems like mythcommflag is somehow "locking out" the rest
of the system from reading the current recording.<br>
Dave<br>
<br>
</body>
</html>