Re: [Tin] Newer versions falsely show empty groups

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."