Version 6.80 Beta 9 Available...

[dexter]

Quade added a new feature to Beta 9, the search history is now saved and displayed separately depending on if you are searching on subject or searching on poster. Other than that, more tweaks and fixes.

Summary:

• Fixed issue with Sonarr communication with Newsbin.
• Updated Zlib, Prce and SSL libraries.
• Fixed issue in Sonarr interface where it wasn't saving the NZB's to the NZB Folder as it should.
• Fixed internal crash issue with certain really old GZ files.
• New feature, choosing "Subject" or "Poster" searching now has separate histories displayed instead of all combined in one list.
• Fixed crash issue when trying to hit help from options menu.
• Fixed issue with "Load Older Posts" replacing instead of adding to search results.

Download from the Newsbin Beta Page.

If you find any issues, please reply to this thread or use our Technical Support Contact Form.

[wiggins09]

Had problems with headers in B8, B9 seems to have the same issue. (i.e. Downloads but doesn't store/display)
Having deleted all the old .db3's I found most of the header d/l's would again read.
But not all.
I have been unable to read headers from some groups (e.g. a.b.teevee) - I see 400k+ headers d/l'd but the tab reads 0 & shows nothing. The db3's in the folder total 56k after 2 days of this.

What to do?

-----------
Did a clean install seems to have sorted it out...

[kirm]

So far so good with the sticking gz files that appeared in B8. Sites pretty quiet this weekend so will see what next week brings.

[tl]

Had problems with headers in B8, B9 seems to have the same issue. (i.e. Downloads but doesn't store/display)
Having deleted all the old .db3's I found most of the header d/l's would again read.
But not all.
I have been unable to read headers from some groups (e.g. a.b.teevee) - I see 400k+ headers d/l'd but the tab reads 0 & shows nothing. The db3's in the folder total 56k after 2 days of this.

a.b.teevee (and a.b.multimedia) is under attack again, this slows down B7 and earlier but B8 & B9 totally grinds to a halt, you can see it in the Cache number, the number in parenthesis is the number of header files to parse.

Downgrading to B7 makes it move forward again, albeit slowly. If Quade or Dexter wants it I have a number of header files that will stop B8 & B9 in it's track, the first one was stuck (one core at 100% ) on a i7-6700 for 15+ minutes before I gave up this time but I think it was stuck multiple hours on it before, in contrast B7 parses that downloaded header file in about a minute on the same machine (which is slow but not a problem).

I've not figured out a pattern to reject the posts that are breaking NBP's parsing this time, I do note that downloading headers again using an header Subject Accept filter with "#a.b.teevee@EFNet" (IE reject everything else) in those groups makes it work in B9 which rules out about 50% of the headers... Then I found that B7 didn't have the issue so I've not digged deeper.

Did a clean install seems to have sorted it out...

I suspect that's because you've not downloaded older headers, these kind of attacks tends to come in waves and it's not currently "on". But will probably be again soon if history is any guide.

[Quade]

Going back and forth between B7 and B8 is going to cause a grind. B7 deletes an index and B8 puts it back in place. So, you really don't want to do that. If you're going to experiment b6 to b8 would probably be better.

As for the grind, I'm not seeing it in Teevee. Are you re-downloading headers for the entire group?

[RayMark]

Thanks for the separate search by poster field history.
Very very helpful feature!

[DaveXVI]

Multi-part files still not clearing from the download list when complete.

[Quade]

Multi-part files still not clearing from the download list when complete.

I wrote myself a more specific note so I remember, Autopar enabled, unrar disabled.

[DaveXVI]

Multi-part files still not clearing from the download list when complete.

I wrote myself a more specific note so I remember, Autopar enabled, unrar disabled.

No, autopar is disabled, send Pars to Wish List is enabled.

[Moondawgie]

Just an observation of something with no obvious detrimental effect on the use of Newsbin Pro Version 6.80 Beta 9.

After exiting from Newsbin after it has finished processing the importation of new message headers, the downloading and processing of all downloads, and with the cache displaying 200/200 (0), the following files remain in the Newsbin Data folder:

DownloadMarker.DB3-shm
DownloadMarker.DB3-wal
DownloadsV2.db3-shm
DownloadsV2.db3-wal

I know that they are sqlite3 files created during the processing of the DownloadMarker.DB3 and DownloadsV2.db3 files, but I don't remember ever before seeing those files in earlier versions of Newsbin after it's been closed.

Why do they remain after Newsbin has been closed?

[Quade]

Why do they remain after Newsbin has been closed?

As you point out, they're used by Sqlite. As for why they remain, it's because Sqlite wants them to remain. If you delete the WAL files you'll probably corrupt the DB's.

[kenr]

Issue with autopar, might be Wine related but doubt it as b8 was OK.
It completes the autopar successfully but leaves the pars in the download list.

[cathaven]

I'm currently seeing a new problem with quite a few posts reported as incomplete when they aren't. If I right-click on the incomplete posts & select properties, it shows all parts available. I'm using 6.80B9 Build 4978 on 32bit Windows 10.

[itimpi]

Not quite sure what you mean by saying that they are incomplete but properties shows they are not. It is worth pointing out that just because you have headers for a post it does not mean that the underlying files they refer to are actually present on a server.

[cathaven]

In the headers list, a number of headers are marked as "Incomplete. Missing information needed for download, [* files, * 7pars]", with an exclamation mark in a yellow triangle.
When I right click on the supposedly incomplete header and select Properties, I get, "All Posts Available" in the "Missing:" box. If they are all available, then it shouldn't show as incomplete in the list.

[shsmith]

Twice now 6.80 beta 9 has crashed.
Both times crash happened when minimized and I was away from the PC.
Everything seems ok when I re-launch.

Here are the details from Reliability History:
Description
Faulting application name: newsbinpro64.exe, version: 6.8.0.0, time stamp: 0x59c57725
Faulting module name: ntdll.dll, version: 10.0.15063.608, time stamp: 0x8274fd8b
Exception code: 0xc0000374
Fault offset: 0x00000000000f775f
Faulting process id: 0x1228
Faulting application start time: 0x01d33e3f75f2d9a6
Faulting application path: C:\Program Files\Newsbin\newsbinpro64.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: b32a49a8-eb3a-4a80-8378-9f831dc0ac14
Faulting package full name:
Faulting package-relative application ID:

Description
Faulting application name: newsbinpro64.exe, version: 6.8.0.0, time stamp: 0x59c57725
Faulting module name: ntdll.dll, version: 10.0.15063.608, time stamp: 0x8274fd8b
Exception code: 0xc0000005
Fault offset: 0x0000000000018344
Faulting process id: 0x2490
Faulting application start time: 0x01d33fc94a54d675
Faulting application path: C:\Program Files\Newsbin\newsbinpro64.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: 8b4f20ef-a014-4220-88b6-090b1faf7209
Faulting package full name:
Faulting package-relative application ID:

[dexter]

Twice now 6.80 beta 9 has crashed.
Both times crash happened when minimized and I was away from the PC.
Everything seems ok when I re-launch.

What CPU and how much RAM does your system have? How many items in your download list?

We do tend to see more crash issues with AMD CPU's...

[kenr]

OK issue with autopar, If you have unrar enabled and a rar is part of the par set then it is unpacked BEFORE it is checked (by autopar). Doesn't affect zip's just rar's.
I have some files that are doing that. Several files with a support rar (containing images) the rar is unpacked resulting in the autopar failing.

[Quade]

Yeah, that's a hard problem. You want singletons to unrar but you don't want them unraring if they have a par file backing them. I haven't come up with a good solution. I could avoid deleting singletons rars which would allow a later PAR file to catch them but that means no cleanup for singletons that have no PAR files. If I did that, I'd have to somehow figure out how to not unrar twice. The other option is to simply not unrar if there are no PARS present.

[kenr]

Or wait for result of par before you unrar if single ?

[Quade]

Or wait for result of par before you unrar if single ?

That depends on download order. With grouped files it's easy to associate files with PARS. When the files aren't grouped, it depends on whether the PAR downloaded before or after the file.

"Waiting for a PAR" is the same thing as simply not processing the file in cases where no PAR exists.

[kenr]

Don't you have some flag that shows whether par's are included in the current download set? If so you could use that as a wait.
But your call as you know the s/w.

[Quade]

Don't you have some flag that shows whether par's are included in the current download set?

You need the PAR to determine if a file belongs to the PAR set so, as long as you download the par first from the set of files, it should ID them as having a par and not unrar till the end. Note the "Should". I haven't tested it recently.

[kenr]

I think I still have par's first set. Don't remember changing it.

[wiggins09]

NB 6.80 Beta 9 b4978 W7x64

I just wanted to let you know about a few things I've been noticing before I try b10.

Watch topics - selecting don't unrar doesn't always work. I found a pre-existing watch with no unrar would not disable unrar after the upgrade to b9; tried making a new watch with same parameters - sometimes it works, sometimes not & sometimes it does some unraring.

Downloading nzbs - some files are bounced to 'failed' tab saying "already d/l'd" when they are in fact totally new. This has been happening with some TV shows this week.

Merging identical file-set d/l's - previously if I have two nzbs with same files (eg in different groups, with some missing/broken) NB has merged them to prevent duplicate d/ls & creates a unified single output. I just saw that I'd d/l'd gigs of dupes. What's annoying was once I realized that this was occurring I paused & selected 'pause' on blocks of files that had already been leeched - so that only non-dupes would be grabbed afterwards.
NB then decided it would d/l them all anyway.
Weird, as NB had stopped, leaving only the paused files in the queue. I'd manually merged the folders, manually ran the par & it was all OK.
But I'd begun a header d/l while doing this. NB started leeching the paused dupe files as well. Took me a while realize this...

So it looks like for some reason the dupe detection is not 100% for me, amongst other things.
Hopefully b10 will have addressed all this

[dexter]

So it looks like for some reason the dupe detection is not 100% for me, amongst other things.

New stuff wasn't getting added to the duplicate detection database. This has been fixed in B10

[Quade]

I just ignored this post since you posted about B9.

[wiggins09]

NP I just wanted to keep the feedback in the right thread.