[mythtv-users] 0.27 watching Live recording freezes

Jim Stichnoth stichnot at gmail.com
Tue Nov 19 17:42:32 UTC 2013


On Sun, Nov 17, 2013 at 6: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?
>
> It doesn't happen to me.  I have no problems with watching in-progress
recording from the HDPVR or HDHR.

The backend messages you excerpted are unremarkable.

Can you try not using NFS - let it communicate the file through the myth
protocol - and see if that changes anything?

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20131119/e9608d23/attachment.html>


More information about the mythtv-users mailing list