When I read you post about the icons, I thought maybe that could be a factor. I say that because my channels table had nothing in the icon column, but as it turns out, having nothing is not a problem if you don't care about seeing the icons. I guess when I switched from zap2it to SchedulesDirect, I lost the icons and never really noticed. I populated the icons (per the wiki) and now I have them, but nothing has changed otherwise.
<br><br>Since you believe this has nothing to do with the slow scheduler query, and since enabling slow deletes made no difference. and since yours works without the use of InnoDB, can you offer any other suggestions as what this could be? Issues to investigate? Configuration changes to consider? Verbose logging that might shed light on it? Anything?
<br><br><div><span class="gmail_quote">On 12/1/07, <b class="gmail_sendername">Michael T. Dean</b> <<a href="mailto:mtdean@thirdcontact.com">mtdean@thirdcontact.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 12/01/2007 04:03 AM, <a href="mailto:f-myth-users@media.mit.edu">f-myth-users@media.mit.edu</a> wrote:<br>> > Date: Sat, 01 Dec 2007 00:17:43 -0500<br>> > From: "Michael T. Dean" <<a href="mailto:mtdean@thirdcontact.com">
mtdean@thirdcontact.com</a>><br>><br>> > On 11/30/2007 05:12 AM, <a href="mailto:f-myth-users@media.mit.edu">f-myth-users@media.mit.edu</a> wrote:<br>> > > It is also completely unreasonable for you to ignore and dismiss all
<br>> > > the evidence people are handing you that RESCHEDULES ARE SLOW even<br>> > > if one has ARLEADY DONE all of the recommended screwing around.<br>><br>> > How many times do I have to say, "His system takes the same amount of
<br>> > time for a scheduling run as my system and my system does /not/ lock<br>> > up--or show /any/ delay at all--after a delete," before it's apparent<br>> > that my system can somehow run a "SLOW" reschedule without affecting UI
<br>> > responsiveness? Am I the only one to whom this implies that the "SLOW"<br>> > reschedule is /not/ the issue?<br>><br>> There are two points here. One is that reschedules are slow no matter
<br>> what you're doing,<br><br>Fine. Look. I'm not saying that it can't be improved--there's not a<br>single place in Myth that can't be improved, as nothing is ever<br>perfect. I'm simply saying that the "recent OP"--the guy who has a
<br>problem and restarted this thread--can make his system perform much<br>better. It seems there are far too many people trying to convince him<br>that there's nothing he can do because Myth is broken and the scheduler
<br>was improperly designed.<br><br>Daniel and Janne have actually made some changes that make the<br>scheduling faster (maybe only committed to multirec so far, though--I<br>don't remember). Chris Pinkham promised you that he would make (and he
<br>has already made some) changes which make the DB locking less of an<br>issue. Others may have also made some changes.<br><br>Though I can't guarantee it--because I'm a non-dev and because I don't<br>make decisions (so arguing with me is really a waste of both our time),
<br>I'm pretty certain no major rewrite of the scheduler will be done in<br>0.20-fixes (stable) branch. I'm even more certain that no major rewrite<br>of the scheduler will be done in the 0.18-fixes (archive) branch.
<br><br>> for some users.<br>><br><br>And /there/ is the important point. Find out why it's only /some/ users<br>and--if, in fact, the configuration difference is a Myth bug, I will fix<br>it for you.<br><br>> Now, as for your own performance, can you please run a couple of tests
<br>> and let us know how -your- system performs?<br><br>That will have to wait until I can find the time.<br><br>> If you cannot ever get the UI to pause while doing this, I'm sure many<br>> of us would be interested to know the size of your oldrecorded tables
<br>><br><br>7072 in oldrecorded, 2903907 in recordedseek, 4577 in recordedmarkup<br><br>> and the number and makeup of your recording rules,<br><br>78 in record (all are currently always/any channel rules--though I often
<br>add up to 20 find once/any channel rules for movies), 413 in<br>recordmatch, 437 in recorded.<br><br>Every table in the DB is MyISAM with the exception of the new<br>MythWeather tables, which are InnoDB (see<br><a href="http://www.gossamer-threads.com/lists/mythtv/dev/302941#302941">
http://www.gossamer-threads.com/lists/mythtv/dev/302941#302941</a> ).<br><br>Oh, and, I've deleted at least 10 shows today, so those numbers were higher.<br><br>> as mentioned in<br>> that old thread about scheduler performance from a few months ago.
<br>> Also interesting would be the match/place lines from your sched logs,<br>> and the contents of your MySQL conf (e.g., memory allocations, etc).<br>><br><br>It's the default one that's installed from a source install--with the
<br>one exception that I disabled (commented) log-bin.<br><br>> > Never optimize before profiling. IMHO, picking something--no matter how<br>> > "likely" to be the problem--and changing it without actually proving it
<br>> > is the source of the problem is just a waste of time.<br>><br>> You seem to be completely ignoring the fact that you've been told<br>> repeatedly that simple reschedule -is- a big problem,<br>
<br>I've been told a lot of things. I believe very little of of what I'm<br>told until I have proof.<br><br>> P.S. One way of verifying your contention that it's the actual<br>> removal of the recordedseek info that's causing deletions to
<br>> be slow<br><br>I _never_ said that removal of recordedseek info causes deletion to be<br>slow. As a matter of fact, I have never even agreed that deletion is<br>slow--as it isn't for me.<br><br>I simply made a comment which tried to point out that--despite what many
<br>had said in the thread--enabling slow deletes on a fast filesystem<br>/does/ have an effect. I did not say that effect would fix the<br>slowness. I did not say that removing records from recordedseek is slow.<br><br>
Far too many people seem to be forgetting that there's a /lot/ going on<br>in the system and that few people have a clear picture of all that<br>happens. I know enough about what happens to know that I don't have a
<br>clear picture of all that happens. Because of this, even things that<br>don't seem to be relevant may actually be relevant.<br><br>Mike<br>_______________________________________________<br>mythtv-users mailing list
<br><a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a><br><a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users</a><br></blockquote></div>
<br>