[mythtv-users] 0.27 watching Live recording freezes

Steven Adeff adeffs.mythtv at gmail.com
Sun Nov 24 15:21:30 UTC 2013


On Sat, Nov 23, 2013 at 10:29 AM, Dave Hill <myth at davidrhill.com> wrote:
> On 11/20/2013 11:21 AM, Steven Adeff wrote:
>> On Sun, Nov 17, 2013 at 9:04 PM, Dave Hill <myth at davidrhill.com> wrote:
>>> Hello,
>>> 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.
>>>
>>> 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.
>>>
>>> At the time of the failure, I see this in the mythfrontend log:
>>>
>>> Nov 17 17:54:48 dhliv mythfrontend.real: mythfrontend[6857]: I Decoder
>>> ringbuffe
>>> r.cpp:1098 (WaitForAvail)
>>> RingBuf(/storage/recordings/2786_20131117212400.mpg):
>>> Waited 0.2 seconds for data #012#011#011#011to become available... 0 <
>>> 32768
>>> Nov 17 17:54:48 dhliv mythfrontend.real: mythfrontend[6857]: N
>>> CoreContext
>>> mythp
>>> layer.cpp:2130 (PrebufferEnoughFrames) Player(l): Waited 102ms for video
>>> buffers
>>>   AAAAAAAAAAAAALff
>>>
>>> ... then a bunch of similar messages with the "waited" time ticking up
>>> till
>>> it reaches 20 seconds:
>>>
>>> Nov 17 17:55:08 dhliv mythfrontend.real: mythfrontend[6857]: N
>>> CoreContext
>>> mythp
>>> layer.cpp:2130 (PrebufferEnoughFrames) Player(l): Waited 19932ms for
>>> video
>>> buffe
>>> rs AAAAAAAAAAAAALff
>>> Nov 17 17:55:08 dhliv mythfrontend.real: mythfrontend[6857]: E
>>> CoreContext
>>> mythp
>>> layer.cpp:2153 (PrebufferEnoughFrames) Player(l): Waited too long for
>>> decoder to
>>>   fill video buffers. Exiting..
>>> Nov 17 17:55:08 dhliv mythfrontend.real: mythfrontend[6857]: I
>>> CoreContext
>>> tv_pl
>>> ay.cpp:2198 (HandleStateChange) TV: Attempting to change from
>>> WatchingRecording
>>> to None
>>>
>>>
>>> In the mythbackend log around the same time, I see this:
>>>
>>> Nov 17 17:52:14 davetv mythbackend: mythbackend[2199]: I ProcessRequest
>>> recorder
>>> s/recorderbase.cpp:457 (GetKeyframeDurations) RecBase[5](/dev/video5):
>>> GetKeyfra
>>> meDurations(308350,9223372036854775807,#65) out of 2475
>>> Nov 17 17:52:43 davetv mythbackend: mythbackend[2199]: N Expire
>>> autoexpire.cpp:2
>>> 64 (CalcParams) AutoExpire: CalcParams(): Max required Free Space: 82.0
>>> GB
>>> w/fre
>>> q: 15 min
>>> 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.
>>> Nov 17 17:54:30 davetv mythbackend: mythbackend[2199]: I
>>> PreviewGeneratorQueue mythdbcon.cpp:409 (PurgeIdleConnections) New DB
>>> connection, total: 15
>>> Nov 17 17:55:43 davetv mythbackend: mythbackend[2199]: I ProcessRequest
>>> mainserver.cpp:1420 (HandleAnnounce) MainServer::ANN Playback
>>> Nov 17 17:55:43 davetv mythbackend: mythbackend[2199]: I ProcessRequest
>>> mainserver.cpp:1422 (HandleAnnounce) adding: dhliv as a client (events:
>>> 0)
>>>
>>>
>>> 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.
>>>
>>> Does anyone else have similar problems?  What other information should I
>>> gather to help diagnose it?
>>>
>>> Thank you,
>>> Dave Hill
>>
>> every so often this will happen, but simply starting the recording
>> again will allow for many more hours of livetv viewing without issue.
>>
>> what does the wait i/o look like when this happens?
>> I agree, NFS may be at issue.
>>
> RE: 'simply starting the recording again'... I have tried restarting
> playback of the recording many times and it keeps freezing.  Are you saying
> I should stop recording the program and restart it?   It seems like stopping
> commflagging was enough to make it playback smoothly, so I think that will
> be my workaround for now.
> What command would I use to check the wait i/o?
> Could this be the result of too many capture cards with only one storage
> group?  My backend has 1 HDPVR + 2 HVR2000s and 1 PVR150 and they all record
> to one storage group.  Perhaps the load of a couple of HD recordings + both
> commflagging + 1 frontend watching is too much for the hard drive?  I am
> considering adding a storage group on a new drive to see if that helps.
>
> Thanks,
> Dave
>

sorry, meant starting livetv again.
it sounds like your drive speed may not be up to the task you are asking of it.

top shows wait i/o, %wa


-- 
Steve
http://www.mythtv.org/wiki/User:Steveadeff
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette - http://www.mythtv.org/wiki/Mailing_List_etiquette


More information about the mythtv-users mailing list