I have a registered version 3.9 of NewsPro and have been working with it sucsesfully for a couple of month. Since a month it started to produce the above error (20020). At first I thought it was due to my newsgroup provider, but out of frustration for not being able to download I installed Usenet Explorer and see... I was able to download the very articles which were not downloadable with NewsPro. So Houston, we have a problem with NewsPro... Tried to reinstall and reset the database, with no result. And for some reason the problem seems to get worse everytime I use NewsPro, the last time I was not able to download any file, with or without .nzb file. So Alex... any ideas?
w.r,
Ad
NewsPro Error - Bad Message-Id in the retrieved article
-
sigmund_fruit
- Posts: 2
- Joined: Tue Feb 28, 2006 8:03 am
I got several similar complaints from Netherlands, it seems there is a problem with some ISP there.
When you download something with NewsPro or Usenet Explorer it checks the downloaded body message-id against message-id from its header database. If they are not the same it means the server didn't return the right article.
You can disable the check in edit menu->properties->articles->detect bad message-id. Then try to open individual article (parts mode in UE or disable autosupport for partials) and check what server returned, probably it is a different article, so then it is the server to blame and certainly you don't want wrong articles to be downloaded instead of what you want.
With nzb files the picture is all the same since the program downloads by message-id.
With usual groups NewsPro downloads by article number, to trick it to download by message-id, create another copy of the server (you can use ip address or hosts file since NewsPro doesn't allow duplicate names differently from UE) make it message-id direct and check "don't download bodies" for the original server, although if the same happens with nzb when you didn't download the headers directly it is not article number problem with the server, but the problem happens with retrieval by message-id as well.
In UE you can set how it downloads bodies although the usual way is through message-ids since UE doesn't keep article numbers except for RAM a inefficient article numbers newsgroup type.
In short try to investigate what article bodies it downloads after downloading parts which failed with the error and subsequently temporarily disabling "detect bad message-id" to download them and check what is in them. if you see a different article contact the server support and report about the problem. you may also see an empty article or some garbage inside, then it means something corrupted in their article storage.
I think it is some newsserver (i don't have any idea what exact brand) update which introduced the bug and maybe several ISP are using the server, but then it is likely they'll fix it since it is an apparent problem.
When you download something with NewsPro or Usenet Explorer it checks the downloaded body message-id against message-id from its header database. If they are not the same it means the server didn't return the right article.
You can disable the check in edit menu->properties->articles->detect bad message-id. Then try to open individual article (parts mode in UE or disable autosupport for partials) and check what server returned, probably it is a different article, so then it is the server to blame and certainly you don't want wrong articles to be downloaded instead of what you want.
With nzb files the picture is all the same since the program downloads by message-id.
With usual groups NewsPro downloads by article number, to trick it to download by message-id, create another copy of the server (you can use ip address or hosts file since NewsPro doesn't allow duplicate names differently from UE) make it message-id direct and check "don't download bodies" for the original server, although if the same happens with nzb when you didn't download the headers directly it is not article number problem with the server, but the problem happens with retrieval by message-id as well.
In UE you can set how it downloads bodies although the usual way is through message-ids since UE doesn't keep article numbers except for RAM a inefficient article numbers newsgroup type.
In short try to investigate what article bodies it downloads after downloading parts which failed with the error and subsequently temporarily disabling "detect bad message-id" to download them and check what is in them. if you see a different article contact the server support and report about the problem. you may also see an empty article or some garbage inside, then it means something corrupted in their article storage.
I think it is some newsserver (i don't have any idea what exact brand) update which introduced the bug and maybe several ISP are using the server, but then it is likely they'll fix it since it is an apparent problem.
-
sigmund_fruit
- Posts: 2
- Joined: Tue Feb 28, 2006 8:03 am
It is not a problem with my Isp nor with my pay-newsserver. If it were, I would not have been able to download the same articles with UE at the same providers. So, I am positive, we have a problem with NewsPro.
The suggested disableing 'bad message Id headers' gives absolutely nothing to save(although my DuMeter indicates I am downloading the complete article...)It is no longer a problem for me since I use Usenet Explorer now, but I know a lot of other guys, who still have this problem.
So I hope you will reconsider checking newspro for us..
The suggested disableing 'bad message Id headers' gives absolutely nothing to save(although my DuMeter indicates I am downloading the complete article...)It is no longer a problem for me since I use Usenet Explorer now, but I know a lot of other guys, who still have this problem.
So I hope you will reconsider checking newspro for us..
it is not a bug in newspro. we are talking about a problem with the server, so the question is what is the exact problem and what settings should be adjusted to deal with it (since both newspro and ue can deal with malfunctioning servers in certain degree and this is the case here).
default download body methods are different in newspro and usenet explorer so you get different results with default settings.
right now i rechecked the latest newspro version there is an option edit menu->properties->articles->"download by article number when possible", if the option is checked NewsPro will work closer to the way as Usenet Explorer does, if the option is unchecked (it is default) it tries to download by message-id right away first, and probably the server bug is the global message-id server index is corrupted (if server would just return "no such article" instead of returning wrong article newspro would proceed in Usenet Explorer way).
so in your case if you check the option maybe it should work then and it will work the same in Usenet Explorer and NewsPro for nzb files unless you have the same headers downloaded directly (NewsPro will try to retrieve by article number first, but anyway it should work since it is unlikely the server is malfunctioning in different ways in the same time).
in any case you can deal with the bug from NewsPro settings, just in Usenet Explorer I made the download body method option more straightforward. there are might be different server bugs depending on what index gets corrupted on the server and in this case NewsPro settings are still adequate.
if it is the server bug what i described above (it seems it is the only possible scenario based on your report), if you set in Usenet Explorer edit menu->properties->articles->download body method to "msg-id direct" it should "acquire" the same problem as well (you may set it so temporarily to verify it will trigger the server bug) and, again, in NewsPro to get rid of the problem you need to check "download by article number when possible" (but it is only to confront the server bug so it is not needed to be done for all users).
default download body methods are different in newspro and usenet explorer so you get different results with default settings.
right now i rechecked the latest newspro version there is an option edit menu->properties->articles->"download by article number when possible", if the option is checked NewsPro will work closer to the way as Usenet Explorer does, if the option is unchecked (it is default) it tries to download by message-id right away first, and probably the server bug is the global message-id server index is corrupted (if server would just return "no such article" instead of returning wrong article newspro would proceed in Usenet Explorer way).
so in your case if you check the option maybe it should work then and it will work the same in Usenet Explorer and NewsPro for nzb files unless you have the same headers downloaded directly (NewsPro will try to retrieve by article number first, but anyway it should work since it is unlikely the server is malfunctioning in different ways in the same time).
in any case you can deal with the bug from NewsPro settings, just in Usenet Explorer I made the download body method option more straightforward. there are might be different server bugs depending on what index gets corrupted on the server and in this case NewsPro settings are still adequate.
if it is the server bug what i described above (it seems it is the only possible scenario based on your report), if you set in Usenet Explorer edit menu->properties->articles->download body method to "msg-id direct" it should "acquire" the same problem as well (you may set it so temporarily to verify it will trigger the server bug) and, again, in NewsPro to get rid of the problem you need to check "download by article number when possible" (but it is only to confront the server bug so it is not needed to be done for all users).
ok finally i got a sample from news.tweakdsl.nl, in some articles there are random characters above headers, thus to use such a server one needs to uncheck properties->articles->detect bad message-id (and use par2 recovery):
l
÷
aý
Path:
feeder3.cambrium.nl!feeder2.cambrium.nl!feed.tweaknews.nl!193.201.147.81.MISMATCH!feeder.xsnews.nl!news.astraweb.com!newsrouter-eu.astraweb.com!border1.nntp.ams.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 13 Apr 2006 10:29:12 -0500
From: ViP@FTACLUB.NET (ITSREAL)
Sender: ViP@FTACLUB.NET
Newsgroups: alt.binaries.boneless
Subject: !!FTACLUB.NET!! ViP ITSREAL POST # 55744
"M.O.D.nicabovthela.r09"ITSREAL (07/87)
X-Newsposter: YENC-POWER-POST-A&A-v10A (Modified POWER-POST www.CosmicWolf.com)
Message-ID: <IuqdnZ5XBMzV86PZnZ2dnUVZ8qKdnZ2d@giganews.com>
Date: Thu, 13 Apr 2006 10:29:12 -0500
Lines: 4584
X-Trace:
sv3-bEmG8NJj+FY8yqqmGXNelkRXogePQQ95y7yWpEl0ylt0MQh0P978hCfAFaHbTtiPqbUuRewINq1ng4J!iU6R3LbCKLqgpECwudim6lZs4HoOkkFc7N6F93lnDa5Toi+0I3hD8ULnjVgiQqws3wAYR3xEN7k=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint
properly
X-Postfilter: 1.3.32
l
÷
aý
Path:
feeder3.cambrium.nl!feeder2.cambrium.nl!feed.tweaknews.nl!193.201.147.81.MISMATCH!feeder.xsnews.nl!news.astraweb.com!newsrouter-eu.astraweb.com!border1.nntp.ams.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 13 Apr 2006 10:29:12 -0500
From: ViP@FTACLUB.NET (ITSREAL)
Sender: ViP@FTACLUB.NET
Newsgroups: alt.binaries.boneless
Subject: !!FTACLUB.NET!! ViP ITSREAL POST # 55744
"M.O.D.nicabovthela.r09"ITSREAL (07/87)
X-Newsposter: YENC-POWER-POST-A&A-v10A (Modified POWER-POST www.CosmicWolf.com)
Message-ID: <IuqdnZ5XBMzV86PZnZ2dnUVZ8qKdnZ2d@giganews.com>
Date: Thu, 13 Apr 2006 10:29:12 -0500
Lines: 4584
X-Trace:
sv3-bEmG8NJj+FY8yqqmGXNelkRXogePQQ95y7yWpEl0ylt0MQh0P978hCfAFaHbTtiPqbUuRewINq1ng4J!iU6R3LbCKLqgpECwudim6lZs4HoOkkFc7N6F93lnDa5Toi+0I3hD8ULnjVgiQqws3wAYR3xEN7k=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint
properly
X-Postfilter: 1.3.32