I've long used Tin 2.0.1 but I noticed that newer versions
download less data when entering busy groups (without compression),
so I've been trying 2.6.4 (built from source). But with the NNTP
server I use for Usenet (running DNews) some groups that have
articles shown in 2.0.1 are empty in 2.6.4 (same with 2.6.2
installed from a Debian package on a different PC).

Curiously it sometimes depends on the getart_limit setting. With "getart_limit=500" I can see articles in alt.bitcoins, but with "getart_limit=1000" it opens empty, with "*** No articles ***" at
the bottom (normally the view stays on the group list while that
message displays for genuinely-empty groups). Same with comp.infosystems.gemini, comp.os.misc, and various other
low-traffic groups.

But some groups show up empty in 2.6.4 with "getart_limit=500" or "getart_limit=1000", eg. ibm.ibmpc.thinkpad. But articles are
always shown in Tin 2.0.1 with either setting.

I also tried setting "cache_overview_files=ON"* and running
"tin -u -r -v" first. But I get the same behaviour except that the
second time I try to view one of these falsely-empty groups Tin
stays on the group list while displaying "*** No articles ***".

I tried renaming ~/.tin/filter to ~/.tin/filter.disabled and
changing "kill_level=2" to "kill_level=1" in case the filtering was
going wrong, but no difference.

I've diffed ~/.tin/tinrc between the three versions (newer ones
were generated from my 2.0.1 config.), but don't see any relevant
differences.

Is there a new setting that I should change to work with DNews
servers? Or is this a bug?


* I thought this might further reduce download sizes when entering
groups, but it appears not.

--
__ __
#_ < |\| |< _#

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In Computer Nerd Kev <not@telling.you.invalid> wrote:

I've long used Tin 2.0.1 but I noticed that newer versions

which actually was the same as 2.1.0, both form december 2011.

Curiously it sometimes depends on the getart_limit setting. With "getart_limit=500" I can see articles in alt.bitcoins, but with "getart_limit=1000" it opens empty, with "*** No articles ***" at
the bottom (normally the view stays on the group list while that
message displays for genuinely-empty groups). Same with comp.infosystems.gemini, comp.os.misc, and various other
low-traffic groups.

a positive getart_limit fetches the last "limit" articles (so you may
miss some unread articles if the limit is too small), a negative number
will fetch all unread arts plus the last "limit" read articles (for propper threading). I would avoid positives numbers (as (auto)catchup may mark
unseen articles as read).

But some groups show up empty in 2.6.4 with "getart_limit=500" or "getart_limit=1000", eg. ibm.ibmpc.thinkpad. But articles are
always shown in Tin 2.0.1 with either setting.

sounds strange, run both with "-D 1" and check what differs (requires
tin has been build with --enable-debug // -DDEBUG) in the log
(see the SECURITY section in the manpage regarding the log location).

feel free to send me the logs privately (after removing any confidential
data like username/password).

I also tried setting "cache_overview_files=ON"* and running

mixing cache_overview_files with getart_limit is usually a bad idea;
you don't want to have an incomplete local cache and once you have a
complete local cache (minus the new articles since the last cache update)
there is no need to limit the number of fetched overviews.

"tin -u -r -v" first. But I get the same behaviour except that the

with cache_overview_files=ON tin will build/update the cache on every
start, -u can be used to build the cache via cron as initially caching
may take a while on huge groups, but once the cache is there there is no
real need to do it anymore (except the group has a lot of traffic and is
read rarely).

I tried renaming ~/.tin/filter to ~/.tin/filter.disabled and
changing "kill_level=2" to "kill_level=1" in case the filtering was
going wrong, but no difference.

filtering happens after the group has been entered, if you can't enter the group then tin sees no articles (either from the freshly fetched overviews
or from the cache) at all.

Is there a new setting that I should change to work with DNews
servers? Or is this a bug?

there was ~14 years of development between the versions (and getart_limit
is rarely used), so hard to say - but I couldn't see any issues here on a
quick test (but I do not have any DNews read access anymore).

* I thought this might further reduce download sizes when entering
groups, but it appears not.

cache_overview_files will reduce the fetched data once the cache is build.

I would remove the getart_limit setting and initially build the cache via -u. on the next normal star of tin should only fetch missing overviews from the server (for each group entered during that session). which may be a win
with huge groups (i.e. gmane.linux.kernel on news.gmane.io).

OR

use a negative getart_limit (depending on the change rate of the group;
i.e. I'd use something like -5000 or even -10000 for gmane.linux.kernel,
for news.software.readers -500 or even less should be ok).

with recent versions of tin you may also use "-C" to reduce network traffic (with the drawback that the server has to compress the data first which may take a while on huge groups, if that "while" is longer than the servers or
the clients connecton timeout you'll have a problem - for the client side
you could adjust nntp_read_timeout_secs / -t). by fetching compressed
overviews (if the server does offer compression) and/or stored the cached overview locally compressed (compress_overview_files) (of course this makes only sense with cache_overview_files).

I would prefer local (compressed) caching over getart_limit and only use getart_limit if disk space is limited. -C can reduce network traffic even
more but is not that widely available and has issues with delayed auth
(can be worked around with forced auth / -A) and/or low connection timeout settings (-t num) and with "normal" groups I didn't see a big win.

HTH,
urs
--
Jef Poskanzer:
"When people aren't stupid Usenet is even more useful. Too bad this happens
so rarely."

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Urs Janssen <urs@buil.tin.org> wrote:

In Computer Nerd Kev <not@telling.you.invalid> wrote:

Curiously it sometimes depends on the getart_limit setting. With
"getart_limit=500" I can see articles in alt.bitcoins, but with
"getart_limit=1000" it opens empty, with "*** No articles ***" at
the bottom (normally the view stays on the group list while that
message displays for genuinely-empty groups). Same with
comp.infosystems.gemini, comp.os.misc, and various other
low-traffic groups.

a positive getart_limit fetches the last "limit" articles (so you may
miss some unread articles if the limit is too small), a negative number
will fetch all unread arts plus the last "limit" read articles (for propper threading). I would avoid positives numbers (as (auto)catchup may mark
unseen articles as read).

I gave this a try and those falsely-empty groups do show articles
in 2.6.4 with "getart_limit=-500". But it's not going to work for
me. I'm used to subscribing to busy groups with lots of idiots
arguing and only check them when I'm bored enough. If I check
aus.cars now with "getart_limit=-500" I download 3.9M, which is
worse than Tin 2.0.1 with "getart_limit=500" which downloads 2.3MB.
With "getart_limit=500" Tin 2.6.4 downloads 461KB - that's the
significant improvement that prompted me to upgrade in the first
place.

If I miss some posts because there are over 500 unread, I don't
care. It's just a pool of BS for me to tap into when there's
bugger all real discussion elsewhere on Usenet. But I need to
reduce how much internet data I use since it's become more
expensive for me.

But some groups show up empty in 2.6.4 with "getart_limit=500" or
"getart_limit=1000", eg. ibm.ibmpc.thinkpad. But articles are
always shown in Tin 2.0.1 with either setting.

sounds strange, run both with "-D 1" and check what differs (requires
tin has been build with --enable-debug // -DDEBUG) in the log
(see the SECURITY section in the manpage regarding the log location).

feel free to send me the logs privately (after removing any confidential
data like username/password).

I'll do that soon, when I get the chance. I'll need to rebuild
them with debugging.

It looks like the groups display empty in newer Tin versions if
there are fewer than getart_limit articles in them on the server:

Empty with "getart_limit=1000":

alt.bitcoins - 709 articles
comp.infosystems.gemini - 831 articles
comp.os.misc - 592 articles
ibm.ibmpc.thinkpad - 101 articles
ausics.general - 8 articles
ausics.announce - 23 articles

Empty with "getart_limit=500":

ibm.ibmpc.thinkpad - 101 articles
ausics.general - 8 articles
ausics.announce - 23 articles

I also tried setting "cache_overview_files=ON"* and running

mixing cache_overview_files with getart_limit is usually a bad idea;
you don't want to have an incomplete local cache and once you have a
complete local cache (minus the new articles since the last cache update) there is no need to limit the number of fetched overviews.

"tin -u -r -v" first. But I get the same behaviour except that the

with cache_overview_files=ON tin will build/update the cache on every
start, -u can be used to build the cache via cron as initially caching
may take a while on huge groups, but once the cache is there there is no
real need to do it anymore (except the group has a lot of traffic and is
read rarely).

Oh, OK. That might not be a practical option for me. I just tried
"tin -u -r -v" after commenting-out getart_limit in tinrc and by
the sixth group of 169 in my .newsrc it had already downloaded
about 40MB and I had to stop it because I can't spare very much
more internet data. Maybe I could do it over free WiFi somewhere if
it's a one-off thing but that won't be any time soon.

I tried renaming ~/.tin/filter to ~/.tin/filter.disabled and
changing "kill_level=2" to "kill_level=1" in case the filtering was
going wrong, but no difference.

filtering happens after the group has been entered, if you can't enter the group then tin sees no articles (either from the freshly fetched overviews
or from the cache) at all.

Well Tin does "enter" the groups (displays the group name above an
empty space with "*** No articles ***" at the bottom). It doesn't
enter groups that are also shown empty in 2.0.1 - that's when it
just shows "*** No articles ***" but stays at the groups list like
the old version. 2.6.4 also stays on the group list if you try
to enter a falsely-empty group a second time before it's
refreshed the active file from the server.

Is there a new setting that I should change to work with DNews
servers? Or is this a bug?

there was ~14 years of development between the versions (and getart_limit
is rarely used), so hard to say - but I couldn't see any issues here on a quick test (but I do not have any DNews read access anymore).

* I thought this might further reduce download sizes when entering
groups, but it appears not.

cache_overview_files will reduce the fetched data once the cache is build.

I would remove the getart_limit setting and initially build the cache via -u. on the next normal star of tin should only fetch missing overviews from the server (for each group entered during that session). which may be a win
with huge groups (i.e. gmane.linux.kernel on news.gmane.io).

If it remains a net win for downloaded data overall after "tin -u"
is run the first time while I'm connected to a free WiFi hotspot
(if I can find one that's still usable - they all got horribly slow
after smartphones became popular), that could be an option. Maybe
I'd need to backup the cache to avoid accidentally losing it, and
overall it would be a lot more work than I've been used to for
accessing Usenet, so I want to be fairly sure that it's a benefit.

with recent versions of tin you may also use "-C" to reduce network traffic

Yes I'm planning to use that for INN servers (eg. Gmane) if I
upgrade, but the Usenet news server I use doesn't support it (I
think DNews development stopped before compression was added to
the standard). On balance I decided that Ausics' other advantages
outweigh that disadvantage.

--
__ __
#_ < |\| |< _#

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Computer Nerd Kev <not@telling.you.invalid> wrote:

Urs Janssen <urs@buil.tin.org> wrote:

In Computer Nerd Kev <not@telling.you.invalid> wrote:

Curiously it sometimes depends on the getart_limit setting. With
"getart_limit=500" I can see articles in alt.bitcoins, but with
"getart_limit=1000" it opens empty, with "*** No articles ***" at
the bottom (normally the view stays on the group list while that
message displays for genuinely-empty groups). Same with
comp.infosystems.gemini, comp.os.misc, and various other
low-traffic groups.

a positive getart_limit fetches the last "limit" articles (so you may
miss some unread articles if the limit is too small), a negative number
will fetch all unread arts plus the last "limit" read articles (for propper >> threading). I would avoid positives numbers (as (auto)catchup may mark
unseen articles as read).

I gave this a try and those falsely-empty groups do show articles
in 2.6.4 with "getart_limit=-500".

Also with "getart_limit=500" if I hit 'z' on the group in the group
list to mark all unread, then I see all the articles when I enter
it. If I read most of the early ones, most of those read articles
don't show next time I enter it, but the newer unread ones are
still there. So 2.6.4 is hiding read articles in those groups even
though I've got "show_only_unread_arts=OFF".

I'll get you the debug logs later when I've rebuilt the Tins.

--
__ __
#_ < |\| |< _#

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In Computer Nerd Kev <not@telling.you.invalid> wrote:

I gave this a try and those falsely-empty groups do show articles
in 2.6.4 with "getart_limit=-500".

Also with "getart_limit=500" if I hit 'z' on the group in the group
list to mark all unread, then I see all the articles when I enter
it. If I read most of the early ones, most of those read articles

that also sounds strange, in th etop level) 'z' can give you the connect
number of available articles (even if higher than getart_limit), but
when entering the group tin will issue "[X]OVER $L-$H" (*) with
$L = highest artnum of that group minus getart_limit
$H = highest artnum of that group
no matter if you pressed 'z' (SelectMarkGrpUnread) before or not.
(* assuming that the server does offer overview data and can do
either OVER or XOVER; if it doesn't tin will use HEAD in a loop
from $L to $H instead).
I don't see a way (minus caching) that it will fetch more than that.

don't show next time I enter it, but the newer unread ones are
still there. So 2.6.4 is hiding read articles in those groups even
though I've got "show_only_unread_arts=OFF".

getart_limit will fetch the data of the last "limit" articles in that
group. no matter if they are read or not. show_only_unread_arts does not
affect the numbers, that's just if unread arts are shown to you in the group (2nd) level or not. with show_only_unread_arts=OFF read articles are still visible in the group-level (use 'r' in that level to
toggle show_only_unread_arts, if there are read articles you should notice
a change in status (centered) line at the top (the first number after the
group name should change)).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In Computer Nerd Kev <not@telling.you.invalid> wrote:

a positive getart_limit fetches the last "limit" articles (so you may
miss some unread articles if the limit is too small), a negative number
will fetch all unread arts plus the last "limit" read articles (for propper >> threading). I would avoid positives numbers (as (auto)catchup may mark
unseen articles as read).

I gave this a try and those falsely-empty groups do show articles
in 2.6.4 with "getart_limit=-500". But it's not going to work for
me. I'm used to subscribing to busy groups with lots of idiots
arguing and only check them when I'm bored enough. If I check
aus.cars now with "getart_limit=-500" I download 3.9M, which is
worse than Tin 2.0.1 with "getart_limit=500" which downloads 2.3MB.

I don't think that aus.cars is a real high traffic group (looks like < 100 arts/day), but if you read it rarely a negative getart_limit may result in significat more traffic (as its base is your lowest read article number)
than a positive getart_limit.

if you don't care much about the group you could do
(this is with negative getart_limit)
'c'atchup the group in the select (top most) level
enter the group
'#' mark range
'1-$' all articles
'Z' unread
you now have <= -getart_limit unread articles in the group. if you don't
read anything and quit tin and till the next start of tin there would be
say 1000 new articles next time you see all the articles from the last
session plus the 1000 new articles. (don't do the "# 1-$ Z" dance again).

with a postive getart_limit you'd see not more than that limit and if that's lower than e.g. 1000 you'll miss some of those new articles...
if you don't care: fine.

It looks like the groups display empty in newer Tin versions if
there are fewer than getart_limit articles in them on the server:

if you can't enter the group, then the server didn't come up with any
overview data for thr group (in the requested range).

if you can enter the group but see no articles then all articles are read (should not happen with show_only_unread_arts=OFF; use 'r' to toggle show_only_unread_arts and what the top status bar (in group-level)), e.g:

show_only_unread_arts=ON
news.newusers.questions (0P 500/0+ 0* 0o 0K) M
^articles to show
^^^getart_limit
^threads to show
vs.
show_only_unread_arts=OFF
news.newusers.questions (5P 500/11 0* 0: 0o 3K) M
^ ^^^ ^^

Empty with "getart_limit=1000":
alt.bitcoins - 709 articles

the logs would be helpfull, getart_limit with a positive number
should issue [X]OVER "high_mark minus limit"-"high_mark"
(in case of high_mark minus limit would be < 1 it will be set to 1).
so that should NOT lead to "empty group".

Oh, OK. That might not be a practical option for me. I just tried
"tin -u -r -v" after commenting-out getart_limit in tinrc and by
the sixth group of 169 in my .newsrc it had already downloaded
about 40MB and I had to stop it because I can't spare very much
more internet data. Maybe I could do it over free WiFi somewhere if
it's a one-off thing but that won't be any time soon.

initially building the cache = download overviews for all articles
in all subscribed groups. that may be a lot of data (dpending on the
number of groups and articles per group), but that's done just once.

Well Tin does "enter" the groups (displays the group name above an
empty space with "*** No articles ***" at the bottom). It doesn't

what else is in the top status bar? and what after pressing 'r'?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Computer Nerd Kev <not@telling.you.invalid> wrote:

Urs Janssen <urs@buil.tin.org> wrote:

In Computer Nerd Kev <not@telling.you.invalid> wrote:

Curiously it sometimes depends on the getart_limit setting. With
"getart_limit=500" I can see articles in alt.bitcoins, but with
"getart_limit=1000" it opens empty, with "*** No articles ***" at
the bottom (normally the view stays on the group list while that
message displays for genuinely-empty groups). Same with
comp.infosystems.gemini, comp.os.misc, and various other
low-traffic groups.

a positive getart_limit fetches the last "limit" articles (so you may
miss some unread articles if the limit is too small), a negative number will fetch all unread arts plus the last "limit" read articles (for propper threading). I would avoid positives numbers (as (auto)catchup may mark unseen articles as read).

I gave this a try and those falsely-empty groups do show articles
in 2.6.4 with "getart_limit=-500". But it's not going to work for
me. I'm used to subscribing to busy groups with lots of idiots
arguing and only check them when I'm bored enough. If I check
aus.cars now with "getart_limit=-500" I download 3.9M, which is
worse than Tin 2.0.1 with "getart_limit=500" which downloads 2.3MB.
With "getart_limit=500" Tin 2.6.4 downloads 461KB - that's the
significant improvement that prompted me to upgrade in the first
place.

If I miss some posts because there are over 500 unread, I don't
care. It's just a pool of BS for me to tap into when there's
bugger all real discussion elsewhere on Usenet. But I need to
reduce how much internet data I use since it's become more
expensive for me.

Urs will correct me if I'm wrong, but AFAIK, you can set per group/ hierarchy/combination_of_groups ('scope') tinrc variables in
.tin/attributes. The variables set in .tin/attributes will override
those set in .tin/tinrc. See tin(5) for details.

So you can set a negative getart_limit for sane groups and a postive
one for "busy groups with lots of idiots".

For example I set different undeclared_charset, organization, news_quote_format, from and sigfile variables for different 'scope's.

Hope this helps.

[...]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Urs Janssen <urs@buil.tin.org> wrote:

In Computer Nerd Kev <not@telling.you.invalid> wrote:
the logs would be helpfull, getart_limit with a positive number
should issue [X]OVER "high_mark minus limit"-"high_mark"
(in case of high_mark minus limit would be < 1 it will be set to 1).
so that should NOT lead to "empty group".

Logs sent. As noted in the email the issue is that 2.6.4 is
requesting for ibm.ibmpc.thinkpad:
XOVER 26-26

Where 2.0.1 requests:
XOVER 26-101

Oh, OK. That might not be a practical option for me. I just tried
"tin -u -r -v" after commenting-out getart_limit in tinrc and by
the sixth group of 169 in my .newsrc it had already downloaded
about 40MB and I had to stop it because I can't spare very much
more internet data. Maybe I could do it over free WiFi somewhere if
it's a one-off thing but that won't be any time soon.

initially building the cache = download overviews for all articles
in all subscribed groups. that may be a lot of data (dpending on the
number of groups and articles per group), but that's done just once.

OK, so after the cache is built it only downloads new article
"overviews"? The Usenet server I use hasn't expired articles since
the early 2010s, so without getart_limit there are a lot of headers
for some groups. It would be nice to be able to see all those old
articles and only download the overviews for new posts to add to it,
instead of downloading the latest 500 each time. If that's how the
cache works without getart_limit enabled, then I'll try and set that
up when I get the chance to do the initial download.

Well Tin does "enter" the groups (displays the group name above an
empty space with "*** No articles ***" at the bottom). It doesn't

what else is in the top status bar? and what after pressing 'r'?

Opening ibm.ibmpc.thinkpad in 2.6.4 I get:

ibm.ibmpc.thinkpad (0B 500/0 0* 0: 0o 0K) h=help
[snip blank lines]
*** No articles ***

After pressing 'r' I get:

ibm.ibmpc.thinkpad (0B 500/0+ 0* 0o 0K) h=help
[snip blank lines]
*** No articles ***
--
__ __
#_ < |\| |< _#

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Frank Slootweg <this@ddress.is.invalid> wrote:

Computer Nerd Kev <not@telling.you.invalid> wrote:

I gave this a try and those falsely-empty groups do show articles
in 2.6.4 with "getart_limit=-500". But it's not going to work for
me. I'm used to subscribing to busy groups with lots of idiots
arguing and only check them when I'm bored enough. If I check
aus.cars now with "getart_limit=-500" I download 3.9M, which is
worse than Tin 2.0.1 with "getart_limit=500" which downloads 2.3MB.
With "getart_limit=500" Tin 2.6.4 downloads 461KB - that's the
significant improvement that prompted me to upgrade in the first
place.

If I miss some posts because there are over 500 unread, I don't
care. It's just a pool of BS for me to tap into when there's
bugger all real discussion elsewhere on Usenet. But I need to
reduce how much internet data I use since it's become more
expensive for me.

Urs will correct me if I'm wrong, but AFAIK, you can set per group/ hierarchy/combination_of_groups ('scope') tinrc variables in
.tin/attributes. The variables set in .tin/attributes will override
those set in .tin/tinrc. See tin(5) for details.

So you can set a negative getart_limit for sane groups and a postive
one for "busy groups with lots of idiots".

Thanks. I have used that before but didn't think of it for this.
Since this issue seems to be a bug I might just stick with old Tin
until everything's working as intended though. Usually I keep up
with the sane groups fairly easily though so going over 500 unread
isn't a common issue in them (usually just when one's having a
moment of "temporary insanity", usually as a consequence of
cross-posting).

--
__ __
#_ < |\| |< _#

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In Frank Slootweg <this@ddress.is.invalid> wrote:

Urs will correct me if I'm wrong, but AFAIK, you can set per group/ hierarchy/combination_of_groups ('scope') tinrc variables in
.tin/attributes. The variables set in .tin/attributes will override
those set in .tin/tinrc. See tin(5) for details.

correct

So you can set a negative getart_limit for sane groups and a postive
one for "busy groups with lots of idiots".

should work (minus the current bug), but I would use caching then
instead (which will likely be available on a per server basis with
the next release) or (havn't done that) use uucp with compressed
batches feed to a local server (if traffic is an issue and your
provider (still) offers uucp).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In Computer Nerd Kev <not@telling.you.invalid> wrote:

OK, so after the cache is built it only downloads new article
"overviews"? The Usenet server I use hasn't expired articles since

yes, it just fills what's not in the cache.

Opening ibm.ibmpc.thinkpad in 2.6.4 I get:
ibm.ibmpc.thinkpad (0B 500/0 0* 0: 0o 0K) h=help

After pressing 'r' I get:
ibm.ibmpc.thinkpad (0B 500/0+ 0* 0o 0K) h=help

I still have no clue where tin doesn't get the high-mark for that
group/limit right (which is lower than your limit so it could just
use the high-mark from the GROUP response) and why it issues
an "[X]OVER low-high" when both numbers are equal it should just
send "[X]OVER low" ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In Computer Nerd Kev <not@telling.you.invalid> wrote:

Is there a new setting that I should change to work with DNews
servers? Or is this a bug?

getart_limit > 0 hast several issues (some but not all) only tiggered
when the grouos high mark was lower than the limit. while fixing those
(thanks for the private feedback and logs) I took the chance and reduced
the code complexity. fix will be in the next release (usualy done in
december).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Urs Janssen <urs@buil.tin.org> wrote:

getart_limit > 0 hast several issues (some but not all) only tiggered
when the grouos high mark was lower than the limit. while fixing those (thanks for the private feedback and logs) I took the chance and reduced
the code complexity. fix will be in the next release (usualy done in december).

Thanks again!

--
__ __
#_ < |\| |< _#

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)