newsbin.com

Version 6.70 Beta 9 fixes a download issue that was occurring on very high speed connections (> 300mbps) as well as some smaller cleanup-type issues.

Here are the changes:

• Changed "Assemble Incompletes" option to force assembly of any file that has at least one chunk downloaded.
• Fixed compaction issue with some rar/par sets.
• Fixed issue with some packets getting lost on very high speed connections. Needs more testing.
• Fixed issue using remote NZB interface pertaining to certain NZB filenames.
• Changes to improve missing status text for failed list. It's better but some are still missing when pushed hard.

The download link is on the Newsbin Beta Page. Any questions, comments, or bug reports can be made by replying to this thread or by using the Technical Support Contact Form.

1. The "Free space available in the Data/Download folders" still shows a value higher than actual. For an empty partition the space available is larger than the whole partition. Versions 6.62 and earlier show the correct size.

2. File Descriptions / Log Group: descript.ion files still show the GOG rather than the Group. Not sure when this started but pictures I downloaded just a couple of weeks ago show the group (but I may not have been using the current beta at that time). I can test earlier versions if that will help.

1. The "Free space available in the Data/Download folders" still shows a value higher than actual. For an empty partition the space available is larger than the whole partition. Versions 6.62 and earlier show the correct size

That's odd. Mines dead nuts on. I do "properties" on the drive itself and it's showing exactly the same number for "free space". I wonder if this is some recycle bin issue because the recycle bin takes up space on disk that will eventually get recovered?

I haven't looked at the GOG thing yet. Hopefully it's fixable. How I track groups has changed.

"Changed "Assemble Incompletes" option to force assembly of any file that has at least one chunk downloaded."

This sounds like a pretty significant change. (edit: just to be clear, it sounds so much more convenient!)

JW since I've wondered it before, once I assemble an incomplete (say before it's finished downloading all the available parts), how can I force it to re-download/re-check that file, without having to load the entire NZB again?

edit: I can confirm the discrepancy in free space numbers, Newsbin is reporting I've got about 2GB more free than properties of the C:\ is (with the Recycle bin empty)
edit2: To clarify again, it seems to be exactly 2GB more. I've got 16.9GB free on C:\, Newsbin is saying 18.9.

JW since I've wondered it before, once I assemble an incomplete (say before it's finished downloading all the available parts), how can I force it to re-download/re-check that file, without having to load the entire NZB again?

Once you "assemble incompletes" the file is done. Nothing more will be added to it. I wouldn't use it till you're sure you've got enough of the file to repair because IF assemble incompletes is needed, it means the file will be damaged.

You could assemble incompletes before but it wouldn't do it if parts of the files were still downloading. The change is to remove the "nanny". Now if you tell it to assemble, it'll assemble. That means if you tell it to assemble pre-maturely there's a good change you might make the file unrepairable.


The "Free Space" field in the disk properties exactly matches up. The "free space" in the free space column in explorer doesn't match. In my case there's a 45 gig difference between what "free space" in the disk properties and what explorer is showing. Nothing's really changed with the free space checking recently. The fact the actual "Free space" in the properties of the drive matches up suggests there's nothing really wrong. I'm just not sure why Windows is reporting 2 different sizes for free space.

can confirm the free space "issue".. explorer shows 1.52TB in normal view or DRIVE PROPERTIES. NB is showing 1.72TB

BZee wrote:1. The "Free space available in the Data/Download folders" still shows a value higher than actual. For an empty partition the space available is larger than the whole partition. Versions 6.62 and earlier show the correct size.

I'm not comparing Newsbin's readings with Windows' readings. I'm comparing between different versions of Newsbin. 6.70b9, b8, b7, b6, b5, b2 all report 225.6 GB / 225.6 GB. Newsbin v6.62, 6.62RC2, 6.61, 6.60, and 6.56RC1 all report 210.10 GB / 210.10 GB. All these versions are installed and I can switch between them via a shortcut. (All use the same data folder so they are not run at the same time).

Hey man, I mentioned this in one of the last beta release threads but sometimes I get an NZB that doesn't complete downloading and repairing even though it's repairable. It'll retry download the red/missing sections a couple of times, but then IDK what happens. A while later, I look in the Newsbin folder and none of the "corrupt" files are there. Reloading the NZB, the data from the corrupt files gets "downloaded" instantly (because the data is still in the Newsbin AppData (or wherever) folder) and if I manually assemble incompletes, the file can be repaired...but again, it doesn't happen automatically. Can I send you or direct you to an NZB in which this occurs? This is on the latest 6.70B9.

Quade wrote:Once you "assemble incompletes" the file is done. Nothing more will be added to it. I wouldn't use it till you're sure you've got enough of the file to repair because IF assemble incompletes is needed, it means the file will be damaged.

You could assemble incompletes before but it wouldn't do it if parts of the files were still downloading. The change is to remove the "nanny". Now if you tell it to assemble, it'll assemble. That means if you tell it to assemble pre-maturely there's a good change you might make the file unrepairable.

I understand but from time to time I do (by mistake) assemble files before they're done downloading (usually when I am individually selecting multiple rars at once (oxymoron?) to manually assemble incompletes). I always try to right click the rar and press "retry download" it just seems intuitive to me that it would start downloading that rar from scratch (delete it first, then re-download?), but obviously that doesn't work. Any chance you could make it work like that? Maybe I should add this as a feature request?

Thanks

. I always try to right click the rar and press "retry download" it just seems intuitive to me that it would start downloading that rar from scratch

Retry download just re-tries chunks that failed to download. Most people don't want to re-download something they already downloaded.

Newsbin assumes "one and done" so, there's no mechanism to restart a download from scratch. You can do it manually by deleting the RARS you assembled by mistake and restarting Newsbin. I've never needed to re-start a download from scratch. That's why there's no built in mechanism to do it.

There are some oddball NZB's running around. Some have completely random subjects and some won't compact into a single line when downloading. Both types will need some more tweaking to the "automatic assemble incompletes" mode which was built with standard "pars and rars grouped together" mode.

It's on my todo list to re-visit it.

You can email an nzb to "ts@newsbin.com". Dex or I will look it over.

I think we're talking about different things maybe? I almost never interact with the files I'm downloading as a single line. I always open up the + and deal with the list of 100 rars "individually" (still grouped together under the +/- obviously). It just easier and more helpful to see the individual rars downloading (and how many red/missing parts each rar has) in my opinion. So when I assemble incompletes for instance, I don't click the top-single line download/file, I select incomplete rars (meaning both rars with red/missing sections and true incomplete/"black" sections) individually and assemble in groups of 5-10 at a time (usually anyway, but like I said, sometimes I just leave it and it doesn't always repair the first time). Likewise, I pause, resume, etc "individual" rars (or more importantly, pars) the same way.

So I'm not looking to "restart a download from scratch," just restart a single rar that I may have inadvertently selected when assembling incompletes, or has been deleted, etc. This seems so much easier than having to reload the entire NZB, and then go through and select+pause 99% of the files so that just that single rar is downloaded.

Latest Beta.

Assemble incomplete anomaly.

Downloaded a file which had a couple of segments incomplete so clicked on Assemble incompletes and files greyed out but file segment count total did not increase and nothing else happened - all file segments marked as downloaded and par segments paused.
Right clicked on largest par and clicked on resume download - a couple of seconds later par segment marked as downloaded but nothing was downloaded. Tried all the rest of the par segments with the same result. As it was late, I shut NB and the PC down.
Rebooted the next morning and after downloading the latest headers noticed that the file had finished downloading and compiling.

Downloaded another file that had a couple of incomplete segments and went through the same thing with as above. Shut NB down and restarted it a few minutes later the file in the download list re-loaded with the incompletes showing blacked out blocks again and the par files showing paused.
This time I resumed the download on the largest par file - it downloaded - then I clicked on Assemble Incompletes and the file repaired itself.

Sad to receive the news that Newsbin will abandon Win XP luddites in this and all future releases. I, as one of millions of XP users, have no intention of handing over megabucks to Microsoft for yet another operating system I don't need or want. I do hope that I won't receive the notice someday that versions of Newsbin 6.62 & earlier will no longer work. I've already switched most of my online computing to the Ubuntu FREE operating system and it works very well. Perhaps Newsbin will have a version for Linux by then.

Runs damn well under Wine. The only issue I know of is that expanding the + icons requires a key press instead of the mouse. For whatever reason Wine doesn't deliver the mouse click properly. If I was a Linux guy, I'd run Newsbin under Wine over XP.

Downloaded another file that had a couple of incomplete segments and went through the same thing with as above. Shut NB down and restarted it a few minutes later the file in the download list re-loaded with the incompletes showing blacked out blocks again and the par files showing paused.
This time I resumed the download on the largest par file - it downloaded - then I clicked on Assemble Incompletes and the file repaired itself.

I'll see if I can reproduce it.

gkar wrote:can confirm the free space "issue".. explorer shows 1.52TB in normal view or DRIVE PROPERTIES. NB is showing 1.72TB

Here also...

HDD:



Newsbin Pro:



It's not converted.

Here also...

HDD:

You can see it exactly matches the first number though which is what I've said all along. I'm not sure how MS is coming up with that number. If you take 341.8 gigs and divide it by 1024 it still doesn't equal the right hand number. The fudge factor seem to be 1.074.

So Newsbin is showing the ACTUAL free bytes on the disk and MS is reporting...some other number.

Hi,

I've just upgraded to latest beta from 6.62.

Has the handling of the Age filter changed when 'show posts' is done on a group?

When I do 'show posts' on a group, the age filter is remembered and displayed in the drop down as 1 days, but the headers displayed are up to 7 days old.
This matches the global default from the options -> setup -> Dispaly Age field = 7.

If I use the drop down to set the age filter to 1 days again, the headers are filtered correctly, down to 1 days of data.

This is repeatable in other groups and with other initial/remembered age fitere settings (e.g. 3 days).

I beielve that in the past, the age filter was not only remembered but also applied when doing a 'show posts' on a group.

regards
Stavros.

This is repeatable in other groups and with other initial/remembered age fitere settings (e.g. 3 days).

I reproduced it too. I'll have to check it out.

Quade wrote:

Here also...

HDD:

You can see it exactly matches the first number though which is what I've said all along. I'm not sure how MS is coming up with that number. If you take 341.8 gigs and divide it by 1024 it still doesn't equal the right hand number. The fudge factor seem to be 1.074.

So Newsbin is showing the ACTUAL free bytes on the disk and MS is reporting...some other number.

Divide 341803566864 bytes by 1024 x 1024 x 1024 and get 318.3293685913086 GB
Newsbin v6.70 series is using 1KB = 1000 bytes, etc. Newsbin v6.62 and prior used 1KB = 1024 bytes etc. I can live with this.

My concern: I download picture groups to a 10GB Truecrypt container. With the container empty, Newsbin v6.70 series says 10.60GB are available on the 10GB drive. If I add 10.3 GBs of data to the download list Newsbin thinks there is enough room on the 10GB drive - could this cause a problem?

My concern: I download picture groups to a 10GB Truecrypt container. With the container empty, Newsbin v6.70 series says 10.60GB are available on the 10GB drive. If I add 10.3 GBs of data to the download list Newsbin thinks there is enough room on the 10GB drive - could this cause a problem?

It's not a problem till you get close to empty. I think you're asking for trouble if you run any drive short of space though. I don't recommend it.


You're right about 1024 but the sizes listed in the posts list also use 1000 so they match up. Still I have no problem switching it back to 1024.

Quade wrote:

My concern: I download picture groups to a 10GB Truecrypt container. With the container empty, Newsbin v6.70 series says 10.60GB are available on the 10GB drive. If I add 10.3 GBs of data to the download list Newsbin thinks there is enough room on the 10GB drive - could this cause a problem?

It's not a problem till you get close to empty. I think you're asking for trouble if you run any drive short of space though. I don't recommend it.


You're right about 1024 but the sizes listed in the posts list also use 1000 so they match up. Still I have no problem switching it back to 1024.

MS is displaying the number in Gibibytes (the old 1,024 bytes = a kilobyte) not the 'con you out of 24 bytes' kilobyte = 1,000 bytes that the industry now uses, so it's not consistent! I'd prefer to see sizes in old money.

And, while we're on about sizes, there is still an issue with NB showing incorrect size of files in a compacted post when opened and a file/s tagged. NB is adding the size of the compacted post to each file tagged, not the actual file size of the file. I had a post that was 1.35GB compacted, when opened and all files inside tagged the post was 14.83GB not 1.35GB.

Quade wrote:Runs damn well under Wine. The only issue I know of is that expanding the + icons requires a key press instead of the mouse. For whatever reason Wine doesn't deliver the mouse click properly. If I was a Linux guy, I'd run Newsbin under Wine over XP.

I've been doing this for many many years now.
Apart from a couple of minor issues it works fine.

Quade wrote:

My concern: I download picture groups to a 10GB Truecrypt container. With the container empty, Newsbin v6.70 series says 10.60GB are available on the 10GB drive. If I add 10.3 GBs of data to the download list Newsbin thinks there is enough room on the 10GB drive - could this cause a problem?

It's not a problem till you get close to empty. I think you're asking for trouble if you run any drive short of space though. I don't recommend it.


You're right about 1024 but the sizes listed in the posts list also use 1000 so they match up. Still I have no problem switching it back to 1024.

I won't worry about it then. If the free space gets low but I want to keep downloading, I always just move some finished files to another drive. It just kinda bothered me to see 10.6 GB available when I knew the drive was only 10 GB.

Used Beta 9 for a few days with no problem, today it triggered an NZB as an archive containing SPAM, while it was not, and I had to bypass filters to force-download it. I have no custom settings in the filter, it is just the default filter you get when installing. Shall I send the NZB to you?

Sure ts@newsbin.com. Last report like this it was "large rar inside rar" triggering it. The spam filters are a moving target.

Thanks.

. Shall I send the NZB to you?

Got it thanks. I'll be checking it out.

Hi,

Not sure if this is related to the 'show posts' problem reported above.

When trying to do a 'load older files into the list', more headers are not added to the displayed headers already in the list (initially this is the most recent 7 days worth of headers for the group).
I can click the button multiple times, waiting 5 - 10 seconds between clicks, without more, older, headers appearing.

If I use the 'reload from Disk' button instead, going back to the beginning of the month, I get thousands of additional headers older than 7 days loaded. The loaded headers age nicely, without time/date gaps.

This is repeatable in other groups.

regards
Stavros.

It's working now. Thanks.

It doesn't look like anyone mentioned this before, but the Find history has been broken on the Files List tab in these betas. The entry box is also shorter than in the other tabs.

It doesn't look like anyone mentioned this before, but the Find history has been broken on the Files List tab in these betas. The entry box is also shorter than in the other tabs.

Got it. Thanks.