[mythtv-users] tv playback woes

[Chris Rouch]

On 17 August 2011 15:22, Chris Rouch <chris.rouch at gmail.com> wrote:
> Over the last couple of weeks we've been experiencing regular, but
> random freezes of the tv playback which end with the playback aborting
> and a dialog being displayed (sorry I don't remember the exact
> message). The frontend logs are full of messages like this:
>
>
> 2011-08-14 21:36:47.182 Player(0): Waited 100ms for video buffers UUUAuAAUAAAUA
> AUUAuAAAAULAAAAUAA
> 2011-08-14 21:36:47.286 Player(0): Waited 100ms for video buffers UUUAuAAUAAAUA
> AUUAuAAAAULAAAAUAA
> 2011-08-14 21:36:47.296 Player(0): Waited 100ms for video buffers UUUAuAAUAAAUA
> AUUAuAAAAULAAAAUAA
> 2011-08-14 21:36:47.302 Player(0): Waited 100ms for video buffers UUUAuAAUAAAUA
> AUUAuAAAAULAAAAUAA
> 2011-08-14 21:36:47.313 Player(0): Waited 100ms for video buffers UUUAuAAUAAAUA
> AUUAuAAAAULAAAAUAA
> 2011-08-14 21:36:47.349 Player(0), Error: Waited too long for decoder to fill v
> ideo buffers. Exiting..
>
>
> The back end logs show nothing unusual happening at this time. This
> happens if I nfs mount the directory from the backend or use myth's
> internal protocol. If I then try to watch the same program again it
> usually works normally.
>
> The backend is running centos5, latest rpms from atrpms.
> The frontend is running mythbunto 10.10 with JYA's 0.24 repository.
>
> Does anyone have any idea how to debug this?
>
> Failing that, is it possible to roll back the frontend so that it has
> an earlier version of myth 0.24? This was all working well a month ago
> so anything before then would be worth trying. I've already rolled
> back the rpms on the backend to 0.24.1-274, without any noticeable
> difference.
>
> In case it matters, the front end is an acer revo with a "Intel(R)
> Atom(TM) CPU  330   @ 1.60GHz" cpu, connected by hdmi. the playback
> profile is CPU+ (VDPAU is available, but the resulting picture only
> occupies the middle half of the screen, so is not really usable).
>
> Any help will be appreciated.
>
> Thanks,
>
> Chris
>

Some more info:

The dialog box says "video frame buffering failed too many times".

The backend isn't entirely normal. There are lots of entries like this
(also when there are no playback problems):


2011-08-17 23:02:49.685 DB Error (delta position map insert):
Query was:
INSERT INTO recordedseek (chanid, starttime, mark, type, offset)
VALUES ( ? , ? , ? , ? , ? )
Bindings were:
:CHANID=105, :MARK=114024, :OFFSET=2028720862, :STARTTIME=2011-08-17T21:30:00,
:TYPE=9
Driver error was [2/1062]:
QMYSQL3: Unable to execute statement
Database error was:
Duplicate entry '105-2011-08-17 21:30:00-9-114024' for key 1


and this (not many, but one co-incided with the playback problems):


2011-08-14 22:22:01.815 TFW, Error: Write() -- IOBOUND begin
remaining(19281) free(0) size(2097152) cnt(1)


and this coincided, though I expect it is normal:

2011-08-17 23:02:38.254 AutoExpire: Adding Programs to 'Do Not Expire' List
2011-08-17 23:02:38.256     105 at 2011-08-17T21:30:00 in use by
recorder on sheedy
2011-08-17 23:02:38.256     1004 at 2011-08-04T02:25:00 in use by
player on ratty
2011-08-17 23:02:38.257 AutoExpire: ExpireLiveTV(10000)
2011-08-17 23:02:38.257 AutoExpire: FillDBOrdered: Adding Short LiveTV programs
 in starttime order
2011-08-17 23:02:38.271 AutoExpire: SendDeleteMessages. Nothing to expire.


And last night, just before the "waited for video buffers" messages
there was this in the front end logs:


2011-08-17 23:01:08.977 ALSA, Error: WriteAudio: buffer underrun

Any help or suggestions will be really appreciated.

Thanks,

Chris