Hi,
The usual dnews.in and dnews.log should contain information on why these
messages were rejected assuming they made it as far as your server. The
output of tellnews stats_in will show you the number of articles rejected on
each feed.
Are you using multi-part completion? If so, the buffer may be too small and
dnews may simple be throwing away articles as it is unable to obtain the
completed parts quick enough.
The usual cause of binary-related problems with sucking feeds is the setting
of item_max/real_max, or renumbering problems.
Assuming you aren't using multi-part completion, the status isn't showing
any problems, and item_max is large enough, then I'd first investigate
possible issues with the server you are sucking from. Actually confirming
the messages are there, and that the article numbering hasn't been changed.
(Although the header information may show the item is there, the article
itself may not be).
Occasionally Dnews may request an article number, and get an error from the
server saying it is not present. If this is the case, dnews.log should
contain this information.
If an upstream numbering issue has caused dnews to become confused, you can
use the getold command to instruct DNews to resuck old items, and hopefully
obtain the missing articles.
tellnews getold groups.name.* 10000
The above would lower the counter by 10000 and resuck those items.
Please let us know if you are still having problems. Generally very little
can go wrong with sucking feeds, so the above checks should turn up the
problem. If not, an indexing problem may be the cause, but this is less
likely.
- Roydon L.
<[EMAIL PROTECTED]> wrote in message
news:<3e1849af$1@netwin1>...
>
> I'm seeing a lot of incomplete multipart binaries on Dnews for the last
few weeks. The articles are complete on my suck feed's server however.
>
> Any pointers on where to look for problems?
>
