This behaviour was mentioned in a previous thread but it was for a previous version of DVDP. What version are you currently using?

I find it slow here from time to time, but I chalk that up to the poor computer have to chew on my rather enormous database, which is closing on 8GB. So I don't fault the program.      

Skip

tlevel,

The larger the database, the more memory Profiler will need, so depending on how much memory your machine has, I'm sure that database size could affect performance.

So, sarcasm unwarranted.

Quoting GSyren:

Quote:
tlevel,

The larger the database, the more memory Profiler will need, so depending on how much memory your machine has, I'm sure that database size could affect performance.

So, sarcasm unwarranted.

Completely agree, but Skip says his "database" is 8gb. Maybe his backup file is 8gb, but I'm sure most of it is his images. So if he can't tell between a database and his backup file, then sarcasm warranted, especially, since he rolled his eyes first.

First of all, Skips 8GB are mostly oversized cover scans, which aren't even touched during Add DVD.

Second, while the number of profiles in a local database may have a minor affect on performance if a filter has to be removed prior to adding DVDs, it really is only minor.

The slow performance comes from the list control that displays the available DVD titles. The control is not designed to handle a large number of entries efficiently. This can be very easily verified by preselecting a region/locality with a small number of available titles in Tools->Options-Defaults.

So, please, stop the "could be this" or "could be that" and do at least *some* research before arguing.

Skip, I think you recall the size of your database without the images incorrectly. 600MB rang alarm bells with me, so I just did a quick backup of my collection without covers-cans.

My total collection is about the same as your (4632 vs your 4,868) and the backup came out as 51.5MB.  Unless you have War and Peace pasted into your notes field for each profile, I am not sure how you get to 10x the size.

I have the same issue and have since using v3, I am currently using the most recent version. I also get a very similar poor search performance when seaching for cast/crew names (in filters and when editing profiles). It does seem to be intermitant though - but I have never worked out why.

The "solution" I have found is to write the search term elsewhere, and then copy/paste it into the field - you then get the delay only once, rather than for each letter typed. Still not great, but a massive improvement.

I am 99% sure it has nothing to do with the images. It seems pretty clear (as they are in a folder) that they are just referenced in the database, not actually embedded in it for them to impact things.

To confirm that I have restored the above backup without images to a new database, and I see exactly the same performance - the images can't be the reason.

Quoting kahless:

Quote:
Quoting Lopek:

Quote:


The "solution" I have found is to write the search term elsewhere, and then copy/paste it into the field - you then get the delay only once, rather than for each letter typed. Still not great, but a massive improvement.

Yes, the performance when searching names in the cast section is really poor. But I can confirm that your "workaround" with copy/past definitely works well. Maybe some database experts can explain this...

Don't think this is a database issue per say. I also have the same issue with cast/crew and have noticed that the more you use it (without doing other stuff) the faster the performance will be. Cast/crew list getting stored in memory vs page file. It seems that Ken has an active search for cast/crew that will filter names on every key stroke press, which is why this method is much slower than cut/paste. H (filter) e (filter) l (filter) e (filter) n (filter) vs Helen (filter). Size of the database will naturally have an affect on the speed, my actor's table is 97 mb alone (headshots are probably stored here also), but my image directory which is 1.8gb does not even come into play, I seriously doubt that it is loaded into memory.

Hi friends,

my hardware is rather fast, 3GHz PC with 3GB RAM and DVDP Version is 3.0.2

Pls correct my if I am wrong but your personal data base whatever size it has has nothing to do with adding a new DVD to your collection. I guess for a new DVD first is looked at the INVELOS online database (which you update each time you use the programm) so this size matters.

And as Voltaire53 mentioned another point is your reginoal code. I have RC2, Germany as default.

So my feature request whould be to fasten this part of the programm.

Thanx
Hardy