Is it possible in pullnews to pre-skip articles above a certain number of
bytes, instead of downloading the whole article first?

Maybe by making a small change in the perl script?

Eli

Hi Eli,

> Is it possible in pullnews to pre-skip articles above a certain number of
> bytes, instead of downloading the whole article first?

Currently not.

> Maybe by making a small change in the perl script?

I would suggest these additional lines:

@@ -928,6 +928,13 @@
push @{$article}, "\n" if not $is_control_art;
}
}
+ + my $overview = $fromServer->xover($i);
+ # Skip the article if its size is more than 100,000 bytes.
+ if ($$overview{$i}[5] and $$overview{$i}[5] > 100000) {
+ $skip_article = 1;
+ }
+ if (not $skip_article
and (not $header_only or $is_control_art or
$add_bytes_header))
{

Before downloading the article, we just retrieve its overview data
(containing the size of the article at index 5 of the returned array),
amongst a few other fields.
Of course, change 100,000 to fit your needs.

I've quickly tested it, and I believe it works.

I may add a dedicated option to pullnews and integrate it in a future
release, if that may prove to be useful for others.

--
Julien ÉLIE

« Le caramel est un invité du palais qui menace la couronne. » (Tristan
Bernard)

On Mar 17, 2023 at 2:49:23 PM CDT, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> I may add a dedicated option to pullnews and integrate it in a future
> release, if that may prove to be useful for others.

Hi Julien,

I would likely use it. :)

-Jesse

Hi Jesse,

>> I may add a dedicated option to pullnews and integrate it in a future
>> release, if that may prove to be useful for others.
>
> I would likely use it. :)

:-)

OK, I'll see how to properly implement it.
The quick patch sends an "OVER n" for each article number (#n). I plan
on sending a global "OVER n-high" command to retrieve all the sizes at
once for a given newsgroup. It will save time because less
commands/answers will be sent.

--
Julien ÉLIE

« Sol attigit talos. »

On 17 Mar 2023 at 20:49:23 CET, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Hi Eli,
>
>> Is it possible in pullnews to pre-skip articles above a certain number of
>> bytes, instead of downloading the whole article first?
>
> Currently not.
>
>
>> Maybe by making a small change in the perl script?
>
> I would suggest these additional lines:
>
>
> @@ -928,6 +928,13 @@
> push @{$article}, "\n" if not $is_control_art;
> }
> }
> +
> + my $overview = $fromServer->xover($i);
> + # Skip the article if its size is more than 100,000 bytes.
> + if ($$overview{$i}[5] and $$overview{$i}[5] > 100000) {
> + $skip_article = 1;
> + }
> +
> if (not $skip_article
> and (not $header_only or $is_control_art or
> $add_bytes_header))
> {
>
> I've quickly tested it, and I believe it works.
>
> I may add a dedicated option to pullnews and integrate it in a future
> release, if that may prove to be useful for others.

Hello Julien,

This also works perfectly.

Thanks again :)

Hi Eli and Jesse,

>> I may add a dedicated option to pullnews and integrate it in a future
>> release, if that may prove to be useful for others.
>
> This also works perfectly.

I've just committed a proper patch, which will be shipped with INN
2.7.1. (You can grab it at the same URL as provided before.)

-L size

Specify the largest wanted article size in bytes. The default is to
download all articles, whatever their size. When this option is
used, pullnews will first retrieve overview data (if available) of
each newsgroup to process so as to obtain articles sizes, before
deciding which articles to actually download.

% ./pullnews -d 1 -L 1000
[...]

.. DEBUGGING 656 -- not downloading article
<sr92nq$1ie38$1@news.trigofacile.com> which has 1230 bytes
x DEBUGGING 657 -- article unavailable 423 No such article number 657
.. DEBUGGING 658 -- not downloading article
<ssjtm9$6u9s$1@news.trigofacile.com> which has 1042 bytes

And naturally, they are downloaded with a greater size specified in the
-L flag.

Hope it suits your needs :-)

--
Julien ÉLIE

« Il avait juste assez de culture pour faire des citations fausses. »
(Byron)

On Mar 19, 2023 at 6:11:09 AM CDT, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Hi Eli and Jesse,
>
> Hope it suits your needs :-)

Thanks, Julien, I am giving it a shot, but I think I may have encountered a
new bug.

When running with -d 1, sometimes when I hit CTRL-C to stop the process it
wipes out the pullnews.marks file. It does not do this every time, but seems
like it is happening if I stop the process while it is retrieving overview
information.

Hi Jesse,

> When running with -d 1, sometimes when I hit CTRL-C to stop the process it
> wipes out the pullnews.marks file. It does not do this every time, but seems
> like it is happening if I stop the process while it is retrieving overview
> information.

When you say "wipe out", does it mean you have an empty pullnews.marks
file? Or a pullnews.marks file with wrong article numbers?

Does it happen only with "-d 1"?
I'm unsure what could cause that, as I've not changed the way the
configuration file is handled :-/
It is saved when pullnews receives a SIGINT (Ctrl+C for instance), and
it writes the last article number processed.

I've tried to reproduce it with "-d 1", but do not see anything
suspicious in pullnews.marks. The last line in standard output is
"Saving config" after Ctrl+C.

--
Julien ÉLIE

« When a newly married couple smiles, everyone knows why. When a ten-
year married couple smiles, everyone wonders why. »

On 19 Mar 2023 at 12:11:09 CET, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Hi Eli and Jesse,
>
>>> I may add a dedicated option to pullnews and integrate it in a future
>>> release, if that may prove to be useful for others.
>
> I've just committed a proper patch, which will be shipped with INN
> 2.7.1. (You can grab it at the same URL as provided before.)
>
> -L size
>
> Specify the largest wanted article size in bytes. The default is to
> download all articles, whatever their size. When this option is
> used, pullnews will first retrieve overview data (if available) of
> each newsgroup to process so as to obtain articles sizes, before
> deciding which articles to actually download.

Thank you Julien and I will test the new version soon.

However, I have my doubts about the fact that this new version first downloads
the overview data of the entire newsgroup. That can take a while for a
newsgroup
with a few million messages. I don't know if I like that.

But maybe I misunderstood you.

On 2023-03-20, Eli <eliistheman@gmail.com> wrote:
> However, I have my doubts about the fact that this new version first downloads
> the overview data of the entire newsgroup. That can take a while for a
> newsgroup
> with a few million messages. I don't know if I like that.

You need the overview to get the article size before downloading,
whether that's all at once or per article. I imagine it's more efficient
to get it all up front then filter out the unwanted articles.

Cheers,
Tom

On 20 Mar 2023 at 12:12:11 CET, "Tom Furie" <tom@furie.org.uk> wrote:

> On 2023-03-20, Eli <eliistheman@gmail.com> wrote:
>> However, I have my doubts about the fact that this new version first downloads
>> the overview data of the entire newsgroup. That can take a while for a
>> newsgroup
>> with a few million messages. I don't know if I like that.
>
> You need the overview to get the article size before downloading,
> whether that's all at once or per article. I imagine it's more efficient
> to get it all up front then filter out the unwanted articles.
>
> Cheers,
> Tom

It may be a bit more efficient, but I still see more disadvantages than
advantages. For example, if I want to change the max. file size or want to
change the regex for option -m, this is no longer possible after the entire
overview has already been downloaded and the filtering has already been
processed.

On Mar 19, 2023 at 10:40:08 AM CDT, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Hi Jesse,
>
>> When running with -d 1, sometimes when I hit CTRL-C to stop the process it
>> wipes out the pullnews.marks file. It does not do this every time, but seems
>> like it is happening if I stop the process while it is retrieving overview
>> information.
>
> When you say "wipe out", does it mean you have an empty pullnews.marks
> file? Or a pullnews.marks file with wrong article numbers?
>
> Does it happen only with "-d 1"?
> I'm unsure what could cause that, as I've not changed the way the
> configuration file is handled :-/
> It is saved when pullnews receives a SIGINT (Ctrl+C for instance), and
> it writes the last article number processed.
>
>
> I've tried to reproduce it with "-d 1", but do not see anything
> suspicious in pullnews.marks. The last line in standard output is
> "Saving config" after Ctrl+C.

Here is what I'm seeing in a session that I did not kill, but was killed off
after the upstream host cut me off for time limit:

.. DEBUGGING 361445 -- not downloading already existing message
<45af67cb$0$20803$5fc30a8@news.tiscali.it> code=223
.. DEBUGGING 361449 -- not downloading already existing message
<45af6a64$0$20803$5fc30a8@news.tiscali.it> code=223
.. DEBUGGING 361451 -- not downloading already existing message
<xn0f1cwlp7d8yw000IdSub@news.individual.net> code=223

Transfer to server failed (436): Flushing log and syslog files

When I start the command again:

[news@spool1 ~]$ pullnews -d 1 -O -c pullnews4.marks -L 200000 -t 3 -G
it.sport.calcio,it.sport.calcio.estero,it.sport.calcio.fiorentina,it.sport.ca
lcio.genoa,it.sport.calcio.inter
Mon Mar 20 11:00:14 2023 start

No servers!

[news@spool1 ~]$ cat pullnews4.marks
[news@spool1 ~]$

Hi Eli,

>>> However, I have my doubts about the fact that this new version first downloads
>>> the overview data of the entire newsgroup. That can take a while for a
>>> newsgroup with a few million messages. I don't know if I like that.
>>
>> You need the overview to get the article size before downloading,
>> whether that's all at once or per article. I imagine it's more efficient
>> to get it all up front then filter out the unwanted articles.

Indeed, downloading the overview in a unique command is globally faster
than article by article.

Suppose the group contains article numbers 1 to 1,000,000 and the last
time pullnews ran, it retrieved article 800,000.
Then on a new run, it will first ask the overview of articles 800,001 to
1,000,000 in a unique command, and it will get a unique (long) answer.
Then pullnews will actually download only articles known to be smaller
than the maximum size wanted.

Otherwise, the easiest way would be to retrieve overview data, article
by article. It will take globally more time, but I agree the user
experience is better as he does not have the feeling of a "hang" during
the download of the whole overview.
I could tweak it to download by bunches of 100 articles for instance,
but it's more work to do :( I may have to do so finally...

> It may be a bit more efficient, but I still see more disadvantages than
> advantages. For example, if I want to change the max. file size or want to
> change the regex for option -m, this is no longer possible after the entire
> overview has already been downloaded and the filtering has already been
> processed.

No, it will still be possible.
Overview data is downloaded each time you run pullnews. It does not
save it for later re-use if you "reset" the newsgroup in pullnews.marks.
It downloads overview data between the last retrieved article and the
last existing article in the newsgroup.

--
Julien ÉLIE

« Give laugh to all but smile to one,
Give cheeks to all but lips to one,
Give love to all but Heart to one,
Let everybody love you
But you love one. »

On Mar 20, 2023 at 1:38:39 PM CDT, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Hi Eli,
>
>>>> However, I have my doubts about the fact that this new version first downloads
>>>> the overview data of the entire newsgroup. That can take a while for a
>>>> newsgroup with a few million messages. I don't know if I like that.
>>>
>>> You need the overview to get the article size before downloading,
>>> whether that's all at once or per article. I imagine it's more efficient
>>> to get it all up front then filter out the unwanted articles.
>
> Indeed, downloading the overview in a unique command is globally faster
> than article by article.
>
> Suppose the group contains article numbers 1 to 1,000,000 and the last
> time pullnews ran, it retrieved article 800,000.
> Then on a new run, it will first ask the overview of articles 800,001 to
> 1,000,000 in a unique command, and it will get a unique (long) answer.
> Then pullnews will actually download only articles known to be smaller
> than the maximum size wanted.
>
> Otherwise, the easiest way would be to retrieve overview data, article
> by article. It will take globally more time, but I agree the user
> experience is better as he does not have the feeling of a "hang" during
> the download of the whole overview.
> I could tweak it to download by bunches of 100 articles for instance,
> but it's more work to do :( I may have to do so finally...

Maybe it would be sufficient to print a message indicating it is retrieving
overview data to inform the user of what is happening to account for the
pause?

Hi Jesse,
> Here is what I'm seeing in a session that I did not kill, but was killed off
> after the upstream host cut me off for time limit:
>
> . DEBUGGING 361445 -- not downloading already existing message
> <45af67cb$0$20803$5fc30a8@news.tiscali.it> code=223
> . DEBUGGING 361449 -- not downloading already existing message
> <45af6a64$0$20803$5fc30a8@news.tiscali.it> code=223
> . DEBUGGING 361451 -- not downloading already existing message
> <xn0f1cwlp7d8yw000IdSub@news.individual.net> code=223
>
> Transfer to server failed (436): Flushing log and syslog files

Hmm, this log line does not correspond to a time limit enforced by the
upstream host. It is generated by the downstream server to which you
are sending articles. The "Flushing log and syslog files" message
appears during log rotation (INN is paused a very short moment).

> When I start the command again:
>
> [news@spool1 ~]$ pullnews -d 1 -O -c pullnews4.marks -L 200000 -t 3 -G
> it.sport.calcio,it.sport.calcio.estero,it.sport.calcio.fiorentina,it.sport.ca
> lcio.genoa,it.sport.calcio.inter
> Mon Mar 20 11:00:14 2023 start
>
> No servers!
>
> [news@spool1 ~]$ cat pullnews4.marks
> [news@spool1 ~]$

Gosh!

Don't you have anything else after "Transfer to server failed (436):
Flushing log and syslog files"?
No "can't open pullnews4.marks" error?

I'm a bit surprised, the configuration file is saved this way:

open(FILE, ">$groupFile") || die "can't open $groupFile: $!\n";
print LOG "\nSaving config\n" unless $quiet;
print FILE "# Format: (date is epoch seconds)\n";
print FILE "# hostname[:port][_tlsmode] [username password]\n";
print FILE "# group date high\n";
foreach $server ( ... )
print [...]

close FILE;

You don't even have the "Saving config" debug line in your console, nor
the 3 initial # lines written in the new pullnews4.marks file...
Sounds like open() failed, or close() failed...

Could you try to add an explicit message error ?

close(FILE) or die "can't close $groupFile: $!\n";;

Don't you have in mind anything that could explain why the file couldn't
be written? (lack of disk space, wrong permissions on the file because
pullnews was not started with the right user, etc.)

--
Julien ÉLIE

« Avez-vous remarqué qu'à table les mets que l'on vous sert vous mettent
les mots à la bouche ? » (Raymond Devos)

On Mar 20, 2023 at 2:07:23 PM CDT, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Hi Jesse,
>> Here is what I'm seeing in a session that I did not kill, but was killed off
>> after the upstream host cut me off for time limit:
>>
>> . DEBUGGING 361445 -- not downloading already existing message
>> <45af67cb$0$20803$5fc30a8@news.tiscali.it> code=223
>> . DEBUGGING 361449 -- not downloading already existing message
>> <45af6a64$0$20803$5fc30a8@news.tiscali.it> code=223
>> . DEBUGGING 361451 -- not downloading already existing message
>> <xn0f1cwlp7d8yw000IdSub@news.individual.net> code=223
>>
>> Transfer to server failed (436): Flushing log and syslog files
>
> Hmm, this log line does not correspond to a time limit enforced by the
> upstream host. It is generated by the downstream server to which you
> are sending articles. The "Flushing log and syslog files" message
> appears during log rotation (INN is paused a very short moment).

You are right, I have too many screen sessions running pullnews and mixed two
up.

>> When I start the command again:
>>
>> [news@spool1 ~]$ pullnews -d 1 -O -c pullnews4.marks -L 200000 -t 3 -G
>> it.sport.calcio,it.sport.calcio.estero,it.sport.calcio.fiorentina,it.sport.ca
>> lcio.genoa,it.sport.calcio.inter
>> Mon Mar 20 11:00:14 2023 start
>>
>> No servers!
>>
>> [news@spool1 ~]$ cat pullnews4.marks
>> [news@spool1 ~]$
>
> Gosh!
>
> Don't you have anything else after "Transfer to server failed (436):
> Flushing log and syslog files"?
> No "can't open pullnews4.marks" error?

The output I provided was a copy/paste from the end of the session and the
commands I ran after.

>
> I'm a bit surprised, the configuration file is saved this way:
>
> open(FILE, ">$groupFile") || die "can't open $groupFile: $!\n";
> print LOG "\nSaving config\n" unless $quiet;
> print FILE "# Format: (date is epoch seconds)\n";
> print FILE "# hostname[:port][_tlsmode] [username password]\n";
> print FILE "# group date high\n";
> foreach $server ( ... )
> print [...]
>
> close FILE;
>
>
> You don't even have the "Saving config" debug line in your console, nor
> the 3 initial # lines written in the new pullnews4.marks file...
> Sounds like open() failed, or close() failed...
>
> Could you try to add an explicit message error ?
>
> close(FILE) or die "can't close $groupFile: $!\n";;

Sure, may be a few days before I reply back with results!

> Don't you have in mind anything that could explain why the file couldn't
> be written? (lack of disk space, wrong permissions on the file because
> pullnews was not started with the right user, etc.)

Definitely no reason, plenty of space, no permission issues, I'm running
pullnews as the "news" user.

Hi Eli and Jesse,

>> I could tweak it to download by bunches of 100 articles for instance,
>> but it's more work to do :( I may have to do so finally...
>
> Maybe it would be sufficient to print a message indicating it is retrieving
> overview data to inform the user of what is happening to account for the
> pause?

It was easier to change than I thought.
Chunks of "progress width" articles at a time are now retrieved in
overview data. This corresponds to the value of -C (50 by default),
that is to say the number of "x", "." and like that are shown on one
progress line.
This way, downloading overview data does not take much time and is
almost unnoticeable by the user.

This improved version of pullnews is available at the same URL as
before. Thanks again for the feedback.

--
Julien ÉLIE

« Asseyez-vous une heure près d'une jolie fille, cela passe comme une
minute ; asseyez-vous une minute sur un poêle brûlant, cela passe
comme une heure : c'est cela la relativité. » (Einstein)

Hello Julien,

In some newsgroups I get the following error while using pullnews:

DEBUGGING 560 Post 436: Msg: <Can't store article>

Then pullnews quits.
Can this be avoided as it is very annoying.

On 21 Mar 2023 at 14:49:16 CET, "Eli" <eliistheman@gmail.com> wrote:

> Hello Julien,
>
> In some newsgroups I get the following error while using pullnews:
>
> DEBUGGING 560 Post 436: Msg: <Can't store article>
>
> Then pullnews quits.
> Can this be avoided as it is very annoying.

In the latest version of pullnews (the one from the link you posted earlier)
it quits with the error:

Transfer to server failed (436): Can't store article

It seems that this only happens with some old posted articles. But still very
annoying.

The new pullnews version is working great BTW. It is much faster than the
current one.

Hi Eli,

>> In some newsgroups I get the following error while using pullnews:
>>
>> DEBUGGING 560 Post 436: Msg: <Can't store article>
>>
>> Then pullnews quits.
>> Can this be avoided as it is very annoying.

Do you happen to have other logs in <pathlog>/news.err or news.notice?
It would be useful to understand why innd did not manage to store the
article provided by pullnews. It is an unusual error. Do all the
newsgroups match an entry in storage.conf?

> In the latest version of pullnews (the one from the link you posted earlier)
> it quits with the error:
>
> Transfer to server failed (436): Can't store article

Didn't previous versions of pullnews report the same error?

> It seems that this only happens with some old posted articles. But still very
> annoying.

Only old posts in some newsgroups? Do they have something special?
(article number > 2^31, unusual headers, etc.)

--
Julien ÉLIE

« Il n'y a que le premier pas qui coûte. » (Mme du Deffand)

On 21 Mar 2023 at 20:18:32 CET, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Hi Eli,
>
>>> In some newsgroups I get the following error while using pullnews:
>>>
>>> DEBUGGING 560 Post 436: Msg: <Can't store article>
>>>
>>> Then pullnews quits.
>>> Can this be avoided as it is very annoying.
>
> Do you happen to have other logs in <pathlog>/news.err or news.notice?
> It would be useful to understand why innd did not manage to store the
> article provided by pullnews.

I don't see any reports in the other logs.

> It is an unusual error. Do all the
> newsgroups match an entry in storage.conf?

Yes, I think this is enough and all I have:

method tradspool {
newsgroups: *
class: 0
}

>
>> In the latest version of pullnews (the one from the link you posted earlier)
>> it quits with the error:
>>
>> Transfer to server failed (436): Can't store article
>
> Didn't previous versions of pullnews report the same error?

Yes it did.

>> It seems that this only happens with some old posted articles. But still very
>> annoying.
>
> Only old posts in some newsgroups? Do they have something special?
> (article number > 2^31, unusual headers, etc.)

Here are 3 that I have on hand in a moment:

<42258b3e_2@127.0.0.1>
<Xns9735CDDF6F44CYouandmeherecom@216.113.192.29>
<1186867877_2111@sp6iad.superfeed.net>

If you cannot access the articles then let me know and I'll post the headers
here.

Hi Eli,

> Here are 3 that I have on hand in a moment:
>
> <42258b3e_2@127.0.0.1>
> <Xns9735CDDF6F44CYouandmeherecom@216.113.192.29>
> <1186867877_2111@sp6iad.superfeed.net>
>
> If you cannot access the articles then let me know and I'll post the headers
> here.

I've tried to inject the first one on my news server, and do not see any
problem... I don't know why it cannot be stored on yours.
(I've only added "trigofacile.test" to the list of newsgroups as I do
not carry alt.*)

235 Article transferred OK

X-Proxy-User: $$ch0zr$fsnj
Newsgroups:
alt.2600.qna,alt.2600.warez,alt.2600.414,alt.2600a,alt.2600hz,alt.266,alt.2d,alt.2eggs.sausage.beans.tomatoes.2toast.largetea.cheerslove,alt,alt.3d,trigofacile.test
Subject: An Easier Way To Make Money
From: mytest@usenet.com
Date: Wed, 2 Mar 2005 09:49:51 GMT
X-Newsreader: News Rover 10.2.0 (http://www.NewsRover.com)
Message-ID: <42258b3e_2@127.0.0.1e>
Lines: 140
X-Comments: This message was posted through <A href
X-Comments2: IMPORTANT: Newsfeeds.com does not condone,
X-Report: Please report illegal or inappropriate use to
Organization: Newsfeeds.com http://www.newsfeeds.com 100,000+ UNCENSORED
Newsgroups.
Path: news.trigofacile.com!news-out.spamkiller.net!spool9-east!not-for-mail
Xref: news.trigofacile.com trigofacile.test:713

....

--
Julien ÉLIE

« Plus un ordinateur possède de RAM, plus vite il peut générer un
message d'erreur. »

On 21 Mar 2023 at 22:04:47 CET, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Hi Eli,
>
> I've tried to inject the first one on my news server, and do not see any
> problem... I don't know why it cannot be stored on yours.
> (I've only added "trigofacile.test" to the list of newsgroups as I do
> not carry alt.*)
>
> 235 Article transferred OK

I'll keep looking for a cause.
Thank you very much for your time. I really appreciate it.

Hi Eli,

> Transfer to server failed (436): Can't store article
>
> I'll keep looking for a cause.

As it seems you are using the tradspool storage system, could you please
try:
scanspool -n -v

Though probably not related to overview, could you also try:
tdx-util -A
(if you're using tradindexed)

--
Julien ÉLIE

« Ce sont vos uniones, pas les miens ! » (Astérix)

On 22 Mar 2023 at 07:47:21 CET, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Hi Eli,
>
>> Transfer to server failed (436): Can't store article
>>
>> I'll keep looking for a cause.
>
> As it seems you are using the tradspool storage system, could you please
> try:
> scanspool -n -v
>
> Though probably not related to overview, could you also try:
> tdx-util -A
> (if you're using tradindexed)

Since these commands take quite a long time, I will wait with this until all
pullnews sessions are done and let you know.

Something else:
How can I reset a newsgroup that has already been fully downloaded so that
pullnews starts downloading all posts again?

Can this be done by:
1) 'ctlinnd rmgroup newgroup'
2) 'ctlinnd newgroupgroup'

or is there a better way?

Thank again and apologies for all my questions.