[mythtv-users] Mythtv 0.24 Acer Revo ALSA WriteAudio buffer underruns
pnetherwood at email.com
pnetherwood at email.com
Mon Feb 7 21:12:49 UTC 2011
> I was able to get rid of the "WriteAudio: buffer underrun" problem by enabling "Extra audio buffering" under "Utilities/Setup --> Setup --> TV
> Settings --> Playback". (It only happened while watching 720p HD, not 1080p, which was interesting.)
Thanks but that didn't make much difference to me because I think the problem goes much deeper.
On further digging I noticed that the pauses coincided with CPU spikes on the backend with mysqld going up to 100% CPU usage for a few seconds. Turing on the mysql slow query log showed it was the scheduler query shown below:
# Time: 110207 19:58:20
# User at Host: mythtv[mythtv] @ localhost []
# Query_time: 3.302175 Lock_time: 0.000039 Rows_sent: 6816 Rows_examined: 44664
SET timestamp=1297108700;
SELECT c.chanid, c.sourceid, p.starttime, p.endtime, p.title, p.subtitle, p.description, c.channum, c.callsign, c.name, oldrecduplicate, p.category, sched_temp_record.recpriority, sched_temp_record.dupin, recduplicate, findduplicate, sched_temp_record.type, sched_temp_record.recordid, p.starttime - INTERVAL sched_temp_record.startoffset minute AS recstartts, p.endtime + INTERVAL sched_temp_record.endoffset minute AS recendts, p.previouslyshown, sched_temp_record.recgroup, sched_temp_record.dupmethod, c.commmethod, capturecard.cardid, cardinput.cardinputid,p.seriesid, p.programid, p.category_type, p.airdate, p.stars, p.originalairdate, sched_temp_record.inactive, sched_temp_record.parentid, (CASE sched_temp_record.type WHEN 6 THEN sched_temp_record.findid WHEN 9 THEN to_days(date_sub(p.starttime, interval time_format(sched_temp_record.findtime, '%H:%i') hour_minute)) WHEN 10 THEN floor((to_days(date_sub(p.starttime, interval time_format(sched_temp_record.findtime, '%H:%i') hour_minute)) - sched_temp_record.findday)/7) * 7 + sched_temp_record.findday WHEN 7 THEN sched_temp_record.findid ELSE 0 END) , sched_temp_record.playgroup, oldrecstatus.recstatus, oldrecstatus.reactivate, p.videoprop+0, p.subtitletypes+0, p.audioprop+0, sched_temp_record.storagegroup, capturecard.hostname, recordmatch.oldrecstatus, sched_temp_record.avg_delay, c.recp0.24.0+fixes.20110206.1a69c92riority + cardinput.recpriority + (cardinput.cardinputid = sched_temp_record.prefinput) * 2 AS powerpriority FROM recordmatch INNER JOIN sched_temp_record ON (recordmatch.recordid = sched_temp_record.recordid) INNER JOIN program AS p ON ( recordmatch.chanid = p.chanid AND recordmatch.starttime = p.starttime AND recordmatch.manualid = p.manualid ) INNER JOIN channel AS c ON ( c.chanid = p.chanid ) INNER JOIN cardinput ON (c.sourceid = cardinput.sourceid) INNER JOIN capturecard ON (capturecard.cardid = cardinput.cardid) LEFT JOIN oldrecorded as oldrecstatus ON ( oldrecstatus.station = c.callsign AND oldrecstatus.starttime = p.starttime AND oldrecstatus.title = p.title ) WHERE p.endtime >= NOW() - INTERVAL 1 DAY ORDER BY sched_temp_record.recordid DESC;
which you can see is a monster query for any database. Its taking 3.3 seconds to run. Every time this query runs the backend locks up causing all of my remote front ends (Revos) to pause. I'm pretty sure there are some missing indexes which is slowing down the joins. My hardware is quite new. I've recently upgraded the backend and this same problem existed on both machines so its definitely a query optimization problem and not a problem with the hardware or a corrupted database.
I have 4GB RAM and an Intel Core i3 processor on a Gigabyte GA-H55-UD3H.
My /etc/mysql/conf.d/mythtv-tweaks.cnf looks like this:
key_buffer = 48M
table_cache = 256
sort_buffer_size = 48M
net_buffer_length = 8M
thread_cache_size = 10
join_buffer_size = 8M
query_cache_type = 1
query_cache_size = 32M
So pretty much everything is cached. I have a 5 year old database and this query was scanning 44664 rows which is pretty big.
I suspect this is one for the devs to have a look at. Missing indexes? I'm running version 0.24.0+fixes.20110206.1a69c92.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20110207/39689018/attachment-0001.htm>
More information about the mythtv-users
mailing list