[mythtv-users] tv playback woes

Chris Rouch chris.rouch at gmail.com
Mon Aug 22 13:44:26 UTC 2011


On 18 August 2011 17:32, Chris Porter <hoodlum7 at gmail.com> wrote:
>
>
> On Thu, Aug 18, 2011 at 7:25 AM, Chris Rouch <chris.rouch at gmail.com> wrote:
>>
>> 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
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://www.mythtv.org/mailman/listinfo/mythtv-users
>
> For the backend errors I suggest you look at the wiki and perform a database
> repair and optimization daily.
> http://www.mythtv.org/wiki/User_Manual:Periodic_Maintenance#Optimize_the_Database
>
>
> Have you tried any other profiles like Slim? Do you get the same results?


It was originally CPU++, and I  tried VDPAU and CPU++. Not sure if I
tried Slim, But see below.
>

> What exactly is the display difference between VDPAU and CPU+?  By
> displaying only in the middle half of the screen do you mean you have black
> bars on the left and right of the video??

Yes, that's what I mean. I can use the TV remote to expand the picture
to fill the screen, but then the myth menus are oversized too.

>
> The "video frame buffering failed too many times" gives me the impression
> your backend is not able to feed data fast enough to your frontend.

I think you might be right. I'm going to try moving an evening's worth
of viewing to the disk on the frontend (I guess I have to change the
storage group to make this work?) and see if that works. It fails
every evening normally, so if we get a couple of   evenings without
errors then I have to look at how to speed up the data transfer.
remotefs is one thing that google popped up - has anyone tried it?


Regards,

Chris


More information about the mythtv-users mailing list