Comments and 2 questions

[kheldar01]

So at last I'm using trial UE since 3 days, just configured using tips on help file included, probably it'll need a fine tuning.
I can only add my voice to the chorus: impressive indeed.

With my Athlon64 3500+ NP needs over 2 mins to backup DB and startup.
Opening groups is slooow compared to UE

And now with UE: almost zero time to open a big binary group over 2 milion and half header Almost zero load time of program and to close it.
Quick filter applied at once.....
And mainly no crash at all till now.

Seem another planet

Very good work Alex, when filters will be in this program can be perfect.

And now some questions:


1) regarding the initial setting on newgroup type (binary compact, message id , articles) I followed the hints in help file. I set all groups with over 1 million headers to binary compact, the ones with 100k to articles.

I see no performance difference at all.

So what the point having 3 different types ? Why dont set all to binary compact ?

2)
In the newsserver list properties window there is server on top of the list called new server. I didnt add it nor i can remove it. What's the purpose of that ? Just curious

3)
Tried the search bar: whatever I write the aswer is always the same. search failed.
Do I need to set up an account on newzbin to use it or I'm missing something ?

[Josef K]

1) regarding the initial setting on newgroup type (binary compact, message id , articles) I followed the hints in help file. I set all groups with over 1 million headers to binary compact, the ones with 100k to articles.

I see no performance difference at all.

So what the point having 3 different types ? Why dont set all to binary compact ?

There are several differences with the types. Compact binary obviously saves a lot of disk space (remember to compact and free) and memory. Article numbers allows UE to better handle server expiration. You could set everything to compact binary but I think there are underlying things not mentioned in the help notes. Alex would have to expand on this but I think threading is an issue here as well. You would notice a difference if you'd set all groups to anything other than compact binary - your RAM may not be able to handle lots of loaded large groups.

As a general rule I'm using compact binary for binary groups and article numbers for text groups.

2) In the newsserver list properties window there is server on top of the list called new server. I didnt add it nor i can remove it. What's the purpose of that ? Just curious

That is where you set the default settings for each new server you add. For example, if you add servers that you will know you want specific task numbers, etc. then set them for new server. Then when you go to add a new server, those values will already be set without you having to do them again.

3) Tried the search bar: whatever I write the aswer is always the same. search failed.
Do I need to set up an account on newzbin to use it or I'm missing something ?

You will need a NewzBin account. However (I don't know how far this has progressed lately) there have been problems with this.

[alex]

compact binary type has its limitations, it doesn't always show partials in threads, so if you imagine a relatively small group where partials might be posted in replies and you want to see threads (e.g. alt.binaries.cracks) you can use other types since the newgroup is small.

if you have access to a bad server which doesn't understand anything but article numbers you have to use the article number type and the article number download body method although it takes a lot of space (in principle compact binary type containing article numbers is also possible but it is not implemented).

for text newsgroups without partials the compact binary type behaves exactly like message-id direct type, so yes, in practice the type maybe is enough.

as to newzbin search bar it is slower than their web interface, the reason is when you use their web interface what is returned is only subjects of matching articles and the main bulk containing message-ids is downloaded only when you invoke 'get message-ids', it is when the delay happens. in their newsreader backend they return message-ids for all matches right away so it is slower, i talked with them about a possibility of a protocol which would behave like their web interface, but i don't know whether they implemented it (in fact it is easy for them but it is difficult on the newsreader side). the delay itself in returning message-ids in both cases is caused by their using sql which is not an effective solution.