Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Android newsgroup reader Groundhog compatibility
6 views
Skip to first unread message
Lu Wei
Dec 27, 2019, 9:18:33 AM12/27/19
to
In group comp.mobile.android I saw a news reader Groundhog, tested it,
failed with my Hamster playground server, succeeded with a "outside"
server. The log as below:
--------------------------------------------------------------------------------------------
2019-12-27 22:07:37 {2525} Client 192.168.1.5:119 connected
2019-12-27 22:07:37 {2525} < 200 Hamster-NNTP, Hamster-Playground Vr.
1.25 (Build 1.25.2.0)
2019-12-27 22:07:37 {2525} > GROUP hamster.en.config
2019-12-27 22:07:37 {2525} < 211 42 1 42 hamster.en.config
2019-12-27 22:07:37 {2525} > GROUP hamster.en.config
2019-12-27 22:07:37 {2525} < 211 42 1 42 hamster.en.config
2019-12-27 22:07:37 {2525} > HEAD 2
2019-12-27 22:07:37 {2525} < 221 2
<1dd7e1be-57d8-40ce...@fm22g2000vbb.googlegroups.com> head
2019-12-27 22:07:37 {2525} > BODY
<1dd7e1be-57d8-40ce...@fm22g2000vbb.googlegroups.com>
2019-12-27 22:07:37 {2525} < 430 Missing article will be searched on
next pull
2019-12-27 22:07:37 {2526} Client 192.168.1.5:119 connected
2019-12-27 22:07:37 {2526} < 200 Hamster-NNTP, Hamster-Playground Vr.
1.25 (Build 1.25.2.0)
2019-12-27 22:07:37 {2526} > BODY
<1dd7e1be-57d8-40ce...@fm22g2000vbb.googlegroups.com>
2019-12-27 22:07:37 {2526} < 430 Missing article will be searched on
next pull
2019-12-27 22:07:37 {2526} > HEAD 3
2019-12-27 22:07:37 {2526} < 412 no newsgroup has been selected
2019-12-27 22:07:37 {2526} > HEAD 4
2019-12-27 22:07:37 {2526} < 412 no newsgroup has been selected
...(deleted redundant items)
2019-12-27 22:07:38 {2526} > HEAD 42
2019-12-27 22:07:38 {2526} < 412 no newsgroup has been selected
2019-12-27 22:07:38 {2526} Client 192.168.1.5:119 disconnected
------------------------------------------------------------------------------------
I see Groundhog uses "head" and "body" command to retrieve articles, not
"xover" and "article" command like Thunderbird. And after getting a "430
Missing article" response, it created another thread to try again, but
maybe Hamster think it should issue a "group" command first. Is it a bug
of Hamster or Groundhog?
If anyone would like to test, the download link I paste below:
Groundhogw 1.20.3 (zoldar build) is available in some apk online
libraries, for example:
https://www.apkmonk.com/app/com.almarsoft.GroundhogReader/
https://www.appbrain.com/app/groundhog-usenet-reader/com.almarsoft.GroundhogReader
An updated and bugfixed Groundhog fork:
http://83.220.108.211/bins/groundhog/
--
Regards,
Lu Wei
IM: xmpp:luwe...@riotcat.org
PGP: 0xA12FEF7592CCE1EA
failed with my Hamster playground server, succeeded with a "outside"
server. The log as below:
--------------------------------------------------------------------------------------------
2019-12-27 22:07:37 {2525} Client 192.168.1.5:119 connected
2019-12-27 22:07:37 {2525} < 200 Hamster-NNTP, Hamster-Playground Vr.
1.25 (Build 1.25.2.0)
2019-12-27 22:07:37 {2525} > GROUP hamster.en.config
2019-12-27 22:07:37 {2525} < 211 42 1 42 hamster.en.config
2019-12-27 22:07:37 {2525} > GROUP hamster.en.config
2019-12-27 22:07:37 {2525} < 211 42 1 42 hamster.en.config
2019-12-27 22:07:37 {2525} > HEAD 2
2019-12-27 22:07:37 {2525} < 221 2
<1dd7e1be-57d8-40ce...@fm22g2000vbb.googlegroups.com> head
2019-12-27 22:07:37 {2525} > BODY
<1dd7e1be-57d8-40ce...@fm22g2000vbb.googlegroups.com>
2019-12-27 22:07:37 {2525} < 430 Missing article will be searched on
next pull
2019-12-27 22:07:37 {2526} Client 192.168.1.5:119 connected
2019-12-27 22:07:37 {2526} < 200 Hamster-NNTP, Hamster-Playground Vr.
1.25 (Build 1.25.2.0)
2019-12-27 22:07:37 {2526} > BODY
<1dd7e1be-57d8-40ce...@fm22g2000vbb.googlegroups.com>
2019-12-27 22:07:37 {2526} < 430 Missing article will be searched on
next pull
2019-12-27 22:07:37 {2526} > HEAD 3
2019-12-27 22:07:37 {2526} < 412 no newsgroup has been selected
2019-12-27 22:07:37 {2526} > HEAD 4
2019-12-27 22:07:37 {2526} < 412 no newsgroup has been selected
...(deleted redundant items)
2019-12-27 22:07:38 {2526} > HEAD 42
2019-12-27 22:07:38 {2526} < 412 no newsgroup has been selected
2019-12-27 22:07:38 {2526} Client 192.168.1.5:119 disconnected
------------------------------------------------------------------------------------
I see Groundhog uses "head" and "body" command to retrieve articles, not
"xover" and "article" command like Thunderbird. And after getting a "430
Missing article" response, it created another thread to try again, but
maybe Hamster think it should issue a "group" command first. Is it a bug
of Hamster or Groundhog?
If anyone would like to test, the download link I paste below:
Groundhogw 1.20.3 (zoldar build) is available in some apk online
libraries, for example:
https://www.apkmonk.com/app/com.almarsoft.GroundhogReader/
https://www.appbrain.com/app/groundhog-usenet-reader/com.almarsoft.GroundhogReader
An updated and bugfixed Groundhog fork:
http://83.220.108.211/bins/groundhog/
--
Regards,
Lu Wei
IM: xmpp:luwe...@riotcat.org
PGP: 0xA12FEF7592CCE1EA
Wolfgang Jäth
Dec 28, 2019, 3:12:30 AM12/28/19
to
Am 27.12.2019 um 15:17 schrieb Lu Wei:
> > I see Groundhog uses "head" and "body" command to retrieve articles, not
> "xover" and "article" command like Thunderbird.
Requesting "head" and "body" is an a little bit very outmoded procedure;
> > I see Groundhog uses "head" and "body" command to retrieve articles, not
> "xover" and "article" command like Thunderbird.
about 30 years or the like. It's nevertheless still a valid protocoll.
Groundhog requests first "HEAD 2", i. e. Article #2, and then simply
requests "BODY", obviously *meaning* "BODY 2". The 430 response from
Hamster indicates, that it seems to interpret such a "BODY" command
/without/ parameter as a request for a previously selected /MID/, not
for a previously selected /article number/ - but there's no MID at all
previously selected. If Hamser woud refer an empty "BODY" command to
article numbers, the failure responses had to be either
"412 - No newsgroup selected" or "423 - No article with that number".
Unfortunately, the appropriate RFC's at that time did /allow/ such
minsunderstandings (one reason, why no bloody soul does use HEAD/BODY
any more).
Wolfgang
--
Donald Trump ist ein großer Visionär, der seiner Zeit weit voraus ist:
Er verbreitet schon jetzt den Slogan "make America great again", obwohl
dieser erst in der Ära /nach/ ihm seine volle Bedeutung entfalten wird.
Lu Wei
Dec 28, 2019, 8:22:43 AM12/28/19
to
On 2019-12-28 1:48, Wolfgang Jäth wrote:
>
> Groundhog requests first "HEAD 2", i. e. Article #2, and then simply
> requests "BODY", obviously *meaning* "BODY 2". The 430 response from
> Hamster indicates, that it seems to interpret such a "BODY" command
> /without/ parameter as a request for a previously selected /MID/, not
> for a previously selected /article number/ - but there's no MID at all
> previously selected. If Hamser woud refer an empty "BODY" command to
> article numbers, the failure responses had to be either
> "412 - No newsgroup selected" or "423 - No article with that number".
>
I think you misread the log: the command after "HEAD 2" is "BODY
>
> Groundhog requests first "HEAD 2", i. e. Article #2, and then simply
> requests "BODY", obviously *meaning* "BODY 2". The 430 response from
> Hamster indicates, that it seems to interpret such a "BODY" command
> /without/ parameter as a request for a previously selected /MID/, not
> for a previously selected /article number/ - but there's no MID at all
> previously selected. If Hamser woud refer an empty "BODY" command to
> article numbers, the failure responses had to be either
> "412 - No newsgroup selected" or "423 - No article with that number".
>
<1dd7e1be-57d8-40ce...@fm22g2000vbb.googlegroups.com>".
Though "BODY 2" is more natural, yet since it has <mid> from HEAD
command, BODY <mid> should be OK too. I tested with telnet, got the
same "430 Missing article" reply (though "body 2" will return the
article body). I tried with other articles, most failed too, until I
tried "head 40" and corresponding "body <mid>". Article 41 and 42 all
works. So it seems because articles before 40 are too old, I guess when
Hamster searches a <mid>, it searches in a pool of <mid> instead of real
database, and when it purges history, it actually purges that pool, so
old <mid> can not be found. Is this the case?
Wolfgang Jäth
Dec 28, 2019, 11:04:31 AM12/28/19
to
Am 28.12.2019 um 14:21 schrieb Lu Wei:
> On 2019-12-28 1:48, Wolfgang Jäth wrote:
>>
>> Groundhog requests first "HEAD 2", i. e. Article #2, and then simply
>> requests "BODY", obviously *meaning* "BODY 2". The 430 response from
>> Hamster indicates, that it seems to interpret such a "BODY" command
>> /without/ parameter as a request for a previously selected /MID/, not
>> for a previously selected /article number/ - but there's no MID at all
>> previously selected. If Hamser woud refer an empty "BODY" command to
>> article numbers, the failure responses had to be either
>> "412 - No newsgroup selected" or "423 - No article with that number".
>>
> I think you misread the log: the command after "HEAD 2" is "BODY
> <1dd7e1be-57d8-40ce...@fm22g2000vbb.googlegroups.com>".
> Though "BODY 2" is more natural, yet since it has <mid> from HEAD
> command, BODY <mid> should be OK too. I tested with telnet, got the
> same "430 Missing article" reply (though "body 2" will return the
> article body). I tried with other articles, most failed too, until I
> tried "head 40" and corresponding "body <mid>". Article 41 and 42 all
> works.
more than *I* had, before you did post here).
Can you take a look into the regarding ini-file
([hamster]\groups\hamster.en.config\dataa.ini), for the following entries:
[Ranges]
Local.Min
Local.Max
They should note the currently really available lowest resp. highest
article numbers. According to you Local.Min shoud note "40", right"?
All below is already purged (or dismissed; if the same article is pulled
simultaneously from different groups, the article number counter is
increased twice or even more, but only one of them is finally used).
> So it seems because articles before 40 are too old, I guess when
> Hamster searches a <mid>, it searches in a pool of <mid> instead of real
> database, and when it purges history, it actually purges that pool, so
> old <mid> can not be found. Is this the case?
which is stored in the IDX-file. As the vesting period for the group
articles itself and the history (i. e. index) can be set individually,
it's possible (and IIRC recomended, btw.), that the index register still
can hold MIDs of articles already beinig purged, as well as vice versa
(articles present, but not indexed any more).
According to your observation of GH being able to receive the headers,
the articles technically seem being present. And according to having no
access by MID request, the index (i.e. history) seems already purged.
This missmatch can be repaired by "File => Rebuild history", but only
for all groups together, and it may need some [tm] time. And of course
you'll lose all /previous/ informations about history entries,
especially about those being loaded in the past and already purged.
To avoid this problem again, you shold check "Configuration => Local
Servers => NNTP => Storage Settings" entries among each other, as well
as, if so, any maybe individual group settings. The holding period for
history should allways be /at/ /least/ as long as for any group, better
/longer/, /never/ less.
Lu Wei
Dec 28, 2019, 8:47:31 PM12/28/19
to
On 2019-12-28 23:56, Wolfgang Jäth wrote:
> ...
>
Thanks for the confirmation and explanation. That explained the
phenomenon. The hamster.en.config\data.ini has:
[Ranges]
Local.Min=1
Local.Max=47
and
[Setup]
purge.articles.keepdays=0
autounsubscribe=0
So the article is there (as "body 2" will return the article body). That
is set by me deliberately, since hamster groups have so few articles
that I'd like to keep them. But purge history setting is global (set to
90 days), so that makes <mid> searching not work. I think GH should be
blamed not using "body <number>" method! Yet anyway, could purging
history be set by individual group?
And I still wonder why GH created another thread after got 430 response,
and issued another "body <mid>" command without issuing "group" command
first. That is GH's fault too I think. Actually if GH did not receive
430, it will proceed and behaves normal (1.20.3 version only, GH2 show
blank group anyway on my phone).
> ...
>
Thanks for the confirmation and explanation. That explained the
phenomenon. The hamster.en.config\data.ini has:
[Ranges]
Local.Min=1
Local.Max=47
and
[Setup]
purge.articles.keepdays=0
autounsubscribe=0
So the article is there (as "body 2" will return the article body). That
is set by me deliberately, since hamster groups have so few articles
that I'd like to keep them. But purge history setting is global (set to
90 days), so that makes <mid> searching not work. I think GH should be
blamed not using "body <number>" method! Yet anyway, could purging
history be set by individual group?
And I still wonder why GH created another thread after got 430 response,
and issued another "body <mid>" command without issuing "group" command
first. That is GH's fault too I think. Actually if GH did not receive
430, it will proceed and behaves normal (1.20.3 version only, GH2 show
blank group anyway on my phone).
Wolfgang Jäth
Dec 29, 2019, 6:34:12 AM12/29/19
to
Am 29.12.2019 um 02:46 schrieb Lu Wei:
> On 2019-12-28 23:56, Wolfgang Jäth wrote:
>> ...
>>
> Thanks for the confirmation and explanation. That explained the
> phenomenon. The hamster.en.config\data.ini has:
>
> [Ranges]
> Local.Min=1
> Local.Max=47
>
> and
>
> [Setup]
> purge.articles.keepdays=0
> autounsubscribe=0
>
> So the article is there (as "body 2" will return the article body). That
> is set by me deliberately, since hamster groups have so few articles
> that I'd like to keep them. But purge history setting is global (set to
> 90 days), so that makes <mid> searching not work. I think GH should be
> blamed not using "body <number>" method!
Well, it's an allowed behavior; why blame?
> On 2019-12-28 23:56, Wolfgang Jäth wrote:
>> ...
>>
> Thanks for the confirmation and explanation. That explained the
> phenomenon. The hamster.en.config\data.ini has:
>
> [Ranges]
> Local.Min=1
> Local.Max=47
>
> and
>
> [Setup]
> purge.articles.keepdays=0
> autounsubscribe=0
>
> So the article is there (as "body 2" will return the article body). That
> is set by me deliberately, since hamster groups have so few articles
> that I'd like to keep them. But purge history setting is global (set to
> 90 days), so that makes <mid> searching not work. I think GH should be
> blamed not using "body <number>" method!
> Yet anyway, could purging
> history be set by individual group?
0 new messages