<font color='black' size='2' face='Arial, Helvetica, sans-serif'><font color="black" face="Arial, Helvetica, sans-serif" size="2">
<div style="font-family: arial,helvetica; font-size: 10pt; color: black;"><br>
> I was able to get rid of the "WriteAudio: buffer underrun" problem by enabling "Extra audio buffering" under "Utilities/Setup --> Setup --> TV <br>
> Settings --> Playback". (It only happened while watching 720p HD, not 1080p, which was interesting.)<br>
<br>
Thanks but that didn't make much difference to me because I think the problem goes much deeper.<br>
<br>
<br>
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:<br>
<br>
<div style="margin-left: 40px;">
# Time: 110207 19:58:20<br>
# User@Host: mythtv[mythtv] @ localhost []<br>
# Query_time: 3.302175 Lock_time: 0.000039 Rows_sent: 6816 Rows_examined: 44664<br>
SET timestamp=1297108700;<br>
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;<br>
</div>
<br>
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. <br>
<br>
I have 4GB RAM and an Intel Core i3 processor on a Gigabyte GA-H55-UD3H.<br>
<br>
My /etc/mysql/conf.d/mythtv-tweaks.cnf looks like this:<br>
<br>
key_buffer = 48M<br>
table_cache = 256<br>
sort_buffer_size = 48M<br>
net_buffer_length = 8M<br>
thread_cache_size = 10<br>
join_buffer_size = 8M<br>
query_cache_type = 1<br>
query_cache_size = 32M<br>
<br>
So pretty much everything is cached. I have a 5 year old database and this query was scanning <font><font color="black" face="Arial, Helvetica, sans-serif" size="2">44664 rows which is pretty big.</font></font><br>
<br>
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.<br>
<br>
<br>
<br>
<br>
</div>
</font></font>