Version 6.62 Beta 1 Available...

[dexter]

We've made changes to 6.61 to try to address issues people have been reporting about assembly of incomplete posts failing. This seems to be exacerbated by what looks like propagation delays with some of the news servers. It also looks like people running watch lists are getting hit pretty hard by it.

Summary of Changes:

• Changed how assembly mode works, now tied to the retry counter. After retries run out on an incomplete post, Newsbin will assemble.
• Added option to turn on strict yEnc checking. In the Performance section. It is off by default.
• Fixed issue where small single post non-files were not incrementing the retry counter.
• Fixed issue where a connection failure when performing an Internet Search would display the wrong error.
• Fixed the ability to create an NZB from wish list.
• Fixed issue loading GZ encoded NZB's. It was broken.
• Fixed issue where the "Show Filenames" setting was not being honored in expanded files.

The download link is on the Newsbin Beta Page.

[gquiring]

Downloading via NZB's (not the watch folder) it's not downloading any pars. I have to manually tell newsbin to download them to fix/complete the file. Logging is showing no errors.

[jackholexxxx]

"Added option to turn on strict yEnc checking. In the Performance section. It is off by default."

Can you explain this a little more?

[dexter]

Downloading via NZB's (not the watch folder) it's not downloading any pars. I have to manually tell newsbin to download them to fix/complete the file. Logging is showing no errors.

Look at the Retry counter in the Status column. Is it counting up to whatever you have retries set to? If you have Max Retries set higher than the default of 2 then it is probably still cycling through retries before it goes on to PAR files. If you are saying the file is failing without downloading any par files then that would be an issue.

[gquiring]

Downloading via NZB's (not the watch folder) it's not downloading any pars. I have to manually tell newsbin to download them to fix/complete the file. Logging is showing no errors.

Look at the Retry counter in the Status column. Is it counting up to whatever you have retries set to? If you have Max Retries set higher than the default of 2 then it is probably still cycling through retries before it goes on to PAR files. If you are saying the file is failing without downloading any par files then that would be an issue.

Yeah that's the issue I will bring it back down to 2.

[dexter]

"Added option to turn on strict yEnc checking. In the Performance section. It is off by default."

Can you explain this a little more?

There is a standard for posting yEnc encoded files for Usenet. If that standard is not followed, it sometimes means it's a spammer. We're finding more and more it means someone just isn't following the standard. We've decided to change the default action to allow these posts through. If you turn strict yEnc checking on, Newsbin will fail posts that are not following the yEnc posting standard as it did before.

[Quade]

The benefit of strict checking is that it'll try any alternate servers. Before it just accepted the bad data. Over the past couple days I've been seeing more poorly formatted yenc posts than ever. It's not clear if it's the poster or the server. It's not clear if it's server specific. With strict turned on though, you'll get more tries at getting good data.

[gquiring]

Last night it downloaded both NZB's in the watch folder without any issues.

[dexter]

Last night it downloaded both NZB's in the watch folder without any issues.

Sweet! Thanks for confirming.

[Quade]

Last night it downloaded both NZB's in the watch folder without any issues.

The whole issue seems to be a combination of more aggressive assembly in Newsbin and slow server updates. For whatever reason completion of many files in certain groups is much more delayed than normal. I saw in one case 30 sets of files were incomplete for a long period before they completed. I think 6.60 and 6.61 would have been fine if this server issue hadn't popped up.

[UPdown]

Data point: 6.62 worked where mere minutes before 6.61 had not. Took a while, but we all appreciate sticktuitiveness. Odd thing, the R: counter never budged off 0. Not for the three files in question. FEELS a little better to double click and have NewsBin play set it and forget it. No, feels a LOT better. Thanks for taking the time to pull something together to make things work almost like normal, especially since you were having difficulty duplicating things.

[Quade]

Thanks for the feedback. I have one user claim it's not helping him but most other people are saying it's working again.

Retries reset to zero every time a new chunk of the file downloads. As long as new chunks keep downloading, it'll keep trying Until the file completes or new chunks stop downloading.

[gquiring]

I checked my Sickbeard list, it downloaded two more last night with no issues. I'm pretty sure you got it fixed.

[Axthor]

Hi

6.62B1 - Build 4314

With previous versions I've never had a problem.

Ctl-R and selecting Read Post Body both appear to be failing all attempts to read. Red progress and Status ends at "[1 files, 0 pars] D:0 DL:1 Retry:0 N:0" after retries.

An example Message-ID: aoWdnVTHGsE-N77LnZ2dnUU7-VOdnZ2d@giganews.com Group: alt.binaries.british.drama

(Possible typo as couldn't copy/paste from the properties)

Thanks

[dexter]

Had another report about this. Has something to do with how it was posted. Newsbin should still be able to handle it. We're looking into it.

Thanks for the report.

[Obecalp]

Nice thanks, will hopefully help with the issue I've been happening where releases include an nfo in the file list but don't include the nfo in the actual release for some reason, get about 10+ instances of that a week (three this morning), have my retries set to 5, should I lower it to 2?

[dexter]

We have a beta 2 being tested on our IRC channel that has the Read Post Body fix. Will probably release it this afternoon.

We were including the .nfo files in the compacted file sets and people complained about it. So now there is a .nbi option to separate them out or include them. If you set CombineMeta=1 in the [SETTINGS] section, Newsbin will combine all .nfo, sfv, and .srr files along with the set. This should be the default behavior so if you don't have this variable explicitly set to 0, it means either the poster used a different subject for the .nfo that didn't match the rest of the files in the set or they included it in the PAR files but it didn't get uploaded for some reason. Newsbin should still repair these files into existence in this case. If you decide to modify the .nbi file, be sure Newsbin is closed before you edit it. Information about doing this is under Hidden Settings in the Advanced Usage section of our help wiki.

As far as the number of retries to use, the default is 2 and should be fine for most people. The higher the retries, the longer it'll sit around trying to download.

[Obecalp]

So if I read that right, if I set it to CombineMeta=0 it will extract archives which are uploaded without the nfo even though the parset says the nfo should be there?

[Quade]

All combine meta does is change how the files are displayed when you download headers. If you download headers and combine meta is set to zero, the meta files are kept out of the compacted sets so you can look at them. It has no impact on unrar or repair.

[Obecalp]

Oh, so no fix for the issue I'm having (and presumably thousands of other people who'll be downloading the same "things" from Usenet), shame

[Quade]

Nice thanks, will hopefully help with the issue I've been happening where releases include an nfo in the file list but don't include the nfo in the actual release for some reason, get about 10+ instances of that a week (three this morning), have my retries set to 5, should I lower it to 2?

I don't actually know what this means. You know the NFO is often embedded in the SRR file these days too?

[Obecalp]

I don't actually know what this means.

I'd emailed Dexter about it last week and we discussed it backwards and forwards but haven't heard anything since.

You know the NFO is often embedded in the SRR file these days too?

No idea, but if you know how to tell Newsbin to find the Nfo in the SRR so it will recreate the NFO thus pass the par check thus unrar the archive, instead of waking up each day to a number of "things" sat in the download queue despite all the rars+pars being downloaded I'm all ears!

[dexter]

I'd emailed Dexter about it last week and we discussed it backwards and forwards but haven't heard anything since.

Ball was in your court. Last email from you said you were were going to upgrade to the latest beta.

[Obecalp]

I'd emailed Dexter about it last week and we discussed it backwards and forwards but haven't heard anything since.

Ball was in your court. Last email from you said you were were going to upgrade to the latest beta.

Aha, well latest beta didn't fix it, 2 "things" from last night stuck in the download tab because of missing Nfo's, manual parcheck recreated the par and renamed the files to the correct names for extraction...

[dexter]

You know those NZB's you sent me didn't even have .nfo files referenced in them. If they are referenced in the PAR files then Newsbin will create them into existence after it downloads enough blocks. I've tested this several times and it worked for me in both 6.62B1 and 6.62B2. Since Newsbin has to use the PAR files to create the .nfo it does set the bar higher for number of blocks it needs to download successfully. If you are still seeing the issue, send me another example NZB. The ones you sent last week have been DMCA'd.

[Obecalp]

You know those NZB's you sent me didn't even have .nfo files referenced in them. If they are referenced in the PAR files then Newsbin will create them into existence after it downloads enough blocks. I've tested this several times and it worked for me in both 6.62B1 and 6.62B2. Since Newsbin has to use the PAR files to create the .nfo it does set the bar higher for number of blocks it needs to download successfully. If you are still seeing the issue, send me another example NZB. The ones you sent last week have been DMCA'd.

Well unless I've done something weird in my config it's definitely not working for me I'll send you the next Nzbs where this happens, shouldn't take long.