I wanted to update you on our latest directions to fix Hoster's problems.
1. It appears that Microsoft has turned Windows 7 64-bit into a VIRTUAL MACHINE. They call it WOW (Windows on Windows). Hoster is a 32-bit app, so it would be run in WOW mode, not 64-bit mode or the Vista "32-bit emulation mode" on a 64-bit OS.
Virtual machines give each Application a limited amount of system resources (which would explain why Search dialog is choking), and may also prevent the App from getting to hardware resources as we could do in the past. WOW may run Hoster in the equivalent of a fractional GigaByte of RAM, and the CPU power "your guess is as good as mine" a fraction of the processor speed. This is now starting to make sense why Hoster runs fine on a good 'ole XP or even a (gag) Vista system, or Windows 7 32-bit.
What the heck! Why didn't Microsoft warn everyone that if you buy a Windows 7 64-bit system (the standard shipped today), you would see performance of ALL your "old programs" equal to some shamefully slow system, WAY INFERIOR to XP?
So, you may want to wait for 5.03 to come out, but if we can't find a way to programmatically allocate RAM/CPU power to the Hoster WOW, we will suggest you install Win7 32-bit.
May God have mercy on us all!
2. Over the years of development, all Indices in the Hoster Songs.mdb and Singers.mdb were removed.
This probably happened when we spent 22 man-months to gain compatibility with Vista that allowed Hoster to also run on Win7.
This means that every search was executed as a "string" search, traversing the entire database. TheMusicGeek reported when using the Search button dialog on his 24MB Songs.mdb, the system could "sleep" for 30-60 seconds. That seriously got my personal attention.
3. In 5.03 we are re-engineering the Singer database.
This database has a Singer Table with SingerID and SingerName fields, and a Song Table with SingerID and BookID fields. The Singers button dialog shows columns with Title, Artist, Brand, and DiscID. It doesn't store these fields, but uses the BookID to "string search" the Songs.mdb, then read these fields and populate the dialog columns. It's no wonder why using the Singers database in any way is slow.
You may wonder why the heck we did that? Well, when the Singers database was "conceived", we expected maybe 100 "repeat singers" (a lot of "followers") with maybe 50 songs (an extravagant set we thought). Uhh... some of you folks are reporting way more Singers/Songs.
In 5.03, when you add a BookID for a Singer, we will copy the Title, Artist, Brand and DiscID AT THAT TIME from the Songs Database and store them in the Song Table as new fields. Then, we won't need to query the Songs database for them. Changes made in Edit Songs will NOT update your Song Table records, but we'll add a "Refresh" button to re-synchronize the Songs Table when you want.
We also are adding "indexing" on these fields:
1. Songs.mdb - Songs Table BookID, Title and Artist. The "BookID" button to add songs to the Playlist will be lightening fast. In the Search button dialog, searching on BookID, Title or Artist will be MUCH faster, but searching Brand, DiscID, Language, Genre, Karaoke, Audio, Video (versus all) will be as slow as you have now.
2. Singers.mdb - Singer Table SingerName, Song Table SingerID and possible Title.
It is not feasible to index all fields as you would not have enough RAM to hold these "in-memory" index tables. Title and Artist are each 64-Bytes long. A 50,000 record (files) Songs.mdb database would require 50K x (64 B+64 B) = 6.4MB just for these two indices. Given that Win7 64-bit WOW mode seems to STARVE Hoster for RAM,this could drastically affect performance, versus improve it.
Also, the more indices we require, the longer it will take to "Index HD Files" or "Build Database". We are making reasonable tradeoffs.
So, that's where we are this weekend. 