[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