Re: [Tin] Newer versions falsely show empty groups

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.

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