On Sat, 12 Mar 2005 11:58:58 -0800, Brad Templeton
<[EMAIL PROTECTED]> wrote:
>
> I think this may be too roundabout a way to attain your real goal.
>
> While myth has a variety of modes to give a show permanence (no autoexpire,
> no episode limit) due to bugs, you have lost shows you hoped were
Today is national reply to your own email day. Make sure you join the
celebration.
On Sat, 12 Mar 2005 01:40:05 -0600, Daniel Manjarres <[EMAIL PROTECTED]> wrote:
> 5) This is really important. Add a group to the watch/delete
> recordings screen with the contents of the delete queues
Oh yes, these data structures were originally queues in mymhead, but
have changed into something else as I was typing. Hope that is not too
confusing.
off-topic. I was recording TDS from march 2003, not july 2004.
___
mythtv-dev mailing list
mythtv-dev@m
Hi guys,
Well just to give you a data point:
I have a 700GB LVM dedicated to mythtv and only mythtv. My music and
video files are stored elsewhere. I have autoexpire turned on by
default, but several recording settings have it turned back off, the
example I will use here is "The Daily Show" which
>> Adding the index didn't change much, (isn't that a primary
>>key anyway?), but recordid was int(11) in the recorded table
>> instead of being int(10). Changing it to int(10) and running
>>OPTIMIZE on the table drop the query down to 4.75 seconds.
>The output from explain will tell you if it's b
Adding the index didn't change much, (isn't that a primary key
anyway?), but recordid was int(11) in the recorded table instead of
being int(10). Changing it to int(10) and running OPTIMIZE on the
table drop the query down to 4.75 seconds.
I'll switch everything back to the default 0.17 and OPTIMI
New resuts:
mysql> CREATE INDEX title ON recorded (title);
Query OK, 738 rows affected (0.27 sec)
Records: 738 Duplicates: 0 Warnings: 0
mysql> CREATE INDEX findid ON recorded (findid);
Query OK, 738 rows affected (0.25 sec)
Records: 738 Duplicates: 0 Warnings: 0
reduced the giant query from
Mark Edwards wrote:
It's actually quite likely to work miracles, particularly if you have just
repeatedly changed your table type ;)
It will rebuild your indexes again and allow then to be used for queries.
Which is nice.
Now it's 19.19 seconds for 3068 rows to be returned using innodb.
before i
On Tue, 22 Feb 2005 14:52:50 -, Mark Edwards <[EMAIL PROTECTED]> wrote:
> Your output isn't very disimilar than mine, I use one more index, but it's
> on a small table so unlikely to cause the discrepancies.
> I suggest running ANALYSE and OPTIMISE on all tables in your DB. (I run them
> every
On Mon, 21 Feb 2005 21:42:01 +, Mark <[EMAIL PROTECTED]> wrote:
> Stick an EXPLAIN in front of the query
Great idea. I would never have thought of that, although I don't know
what to do with the output =) .
+-++--+--+-+
| table | t
So this is the structure of the 3 tables in my db. I guess the first
thing is to make sure they are not on crack. The next thing is to
figure out if I should be adding any indices or what to speed things
up. I apparently have 6 times the recordings that y'all have, so maybe
thats where I need to lo
After losing all those shows I am still trying to figure out wtf went wrong.
for reference here are the sizes of the tables in my database.
allrecord.MYIrecords: 11
callsignnetworkmap.MYI records: 52
channel.MYI records: 72
codecparams.MYI
On Sat, 19 Feb 2005 23:30:03 -0500 (EST), Chris Pinkham
<[EMAIL PROTECTED]> wrote:
> > 1) deleting a recording in progress: Accorrding to top(1) mysqld jumps
> > to 100% CPU usage while the frontend sits there not repainting the
> > screen. This takes 8-10 seconds to finish.
>
> Are you using 0.17
llow other parts of
the myth system to get access to the db is just too big of a hack to
work for all cases, but I can always be wrong. In any case I ain't
going to be able to fix it so I won't complain too much.
HTH
Daniel Manjarres
___
my
On Fri, 18 Feb 2005 14:56:18 -0500 (EST), Chris Pinkham
<[EMAIL PROTECTED]> wrote:
>
> After typing all that in, I see several improvements I'll look at making
> that should help lessen the impact of deletes and improve the interaction.
Well, after re-reading that list I notice it doesn't mentio
On Fri, 18 Feb 2005 14:56:18 -0500 (EST), Chris Pinkham
<[EMAIL PROTECTED]> wrote:
> > convert recorded to MYISAM, oldrecoreded back to innnodbfirst
> > delete takes 10 seconds, AND a a new stutter appears after the
> > recording is done (this may be uncorrelated).
>
> This stutter could b
On Fri, 18 Feb 2005 09:36:33 +, Ed Wildgoose <[EMAIL PROTECTED]> wrote:
> From your symptoms and without looking at the code, my first thought
> was some kind of transaction wrapping in the myth delete function so
> that the metadata delete and disk delete would both be sure to happen.
> Howe
Yan-Fa Li wrote:
Daniel Manjarres wrote:
One difference may be the filesystems we're using. I have ext3 on a
700GB lvm volume. The delays get really bad when deleting more than one
show on my system.
Interesting. I run the db on a separate file system. You're running
everyth
Yan-Fa Li wrote:
True, but I was wondering if the problem was related to re-reading the
table after you deleted the show. Setting the query cache might have
helped that case. I've been using mysql with myisam for quite some time
and I've not noticed multiple seconds of delay deleting shows, but
Yan-Fa Li wrote:
Daniel Manjarres wrote:
Thanks for the quick response.
Ok, well I decided to switch the database back to test it, and it is
slow as hell again. This time I did:
for a in $(ls *frm | cut -f1 -d. ); do echo "use mythconverg; ALTER
TABLE $a TYPE=MYISAM;"|mysql ; don
Anduin Withers wrote:
but I forgot
to test delete speed with the 0.17 code before doing the conversion,
so I can't tell if there was a change in the code base that would
speed this up regardless of the database format used.
In this case it is almost certainly the .17 code more than your DB
con
Hi guys, Sorry if this isn't exactly core mythtv code related.
I always have been unhappy with the GUI pausing for several seconds
after deleting recordings, so I decided to try converting the database
tables from MYISM to innodb to see if there would be any performance
difference (innodb has row-
On Tue, 30 Nov 2004 21:03:56 -0600, David Engel <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 30, 2004 at 10:55:07AM -0500, Doug Larrick wrote:
> Well, pthread_mutex_t seems to have the same problem as QMutex in that
> a precess already waiting doesn't get priority over a process that
> releases, yield
23 matches
Mail list logo
