Unresponsive Filters

[Megalith]

Downloaded the latest beta last night. I'm liking it so far---the new gui I'm on the fence about, but everything seems to run much more smoothly, and the program doesn't appear to freeze anymore when I try to show massive amounts of posts.

But the main problem is how unresponsive the filters seem to be. It usually goes like this: select some options, nothing happens, only an empty screen with no posts shown. Or, I'll wait a huge while and posts actually do show back up---but with every single post, not only the ones I filtered for.

Am I the only one experiencing this?

[mho]

But the main problem is how unresponsive the filters seem to be. It usually goes like this: select some options, nothing happens, only an empty screen with no posts shown. Or, I'll wait a huge while and posts actually do show back up---but with every single post, not only the ones I filtered for.

In 6 (at least pre-beta10) headers are downloaded to a file (as quickly as possible) and then inserted into the database in the background. While this is happening, sometimes things like filters don't work as expected. When all .RV4-files in the spool directory have been processed, things will get back to normal, but this can take a while.

- mho

[Quade]

Exactly.

B10 won't feed in the background by default so, this particular problem will go away. It bring with it new potential problems though.

1 - Header downloads might not be as fast
2 - Significantly more disk IO during header download.

It's optional though so, you can pick which mode you prefer, foreground "feed the database as quickly as possible" or background "feed slower but, finish slower".

[mho]

or background "feed slower but, finish slower".

Don't think you meant that:-)

- mho

[Megalith]

Will look forward to the release of B10, then!

[Quade]

or background "feed slower but, finish slower".

This IS what I mean. Background mode downloads headers as fast as it can and then slowly feeds the DB so, it finishes later.

Foreground mode downloads and inserts at the same time so, you finish faster, even though the download speed is slower.

[mho]

or background "feed slower but, finish slower".

This IS what I mean. Background mode downloads headers as fast as it can and then slowly feeds the DB so, it finishes later.

Foreground mode downloads and inserts at the same time so, you finish faster, even though the download speed is slower.

Hmm... Then I have a hard time seeing any advantage of the background mode. I thought it would finish updating everything quicker, but the price being that not everything would work as well while still updating. If foreground has less of these drawbacks _and_ finishes faster, why would I want the background mode?

I envision being able to move the download jobs for the groups I'm currently interesting in to the top of the queue and then let the rest finish while I browse/download.

- mho

[Quade]

Background mode is less stressful to the PC. You also get the header downloads out of the download list faster which means, while the inserts are happening, downloads can be happening at the same time.

[mho]

Background mode is less stressful to the PC. You also get the header downloads out of the download list faster which means, while the inserts are happening, downloads can be happening at the same time.

Aha! It seems to be more stressful to _me_, though, so, it's a choice between me and the PC - well, let me think about it...:-)

- mho