Version 6.73 Beta 1

[dexter]

While version 6.72 has been very reliable with few complaints, we have found some minor issues to address. If you have been bothered by any of the below issues, please give this one a try and let us know if it resolves your problems.

Changes in 6.73:

• Fixed issue where the $(SEARCH) path variable wasn't working for local searches.
• Fixed issue where "All groups" wasn't actually selecting all groups in local search.
• Fixed issue where Filter Profiles weren't applying during watch list rescan.
• Add RAR/ZIP/GZ decode to NZB's downloaded using Sonarr/SickBeard. The NZB's now get sent to the "Nzbs" folder in order to implement this.
• Changes to how re-scan works resulting in less disk access.
• Addressed issue with $(FILENAME)path variable not working with automatic download modes. Only works for .rar files.

The download link is on the Newsbin Beta Page. If you find any issues, please reply to this thread or use our Technical Support Contact Form.

[grantboucher]

I'm seeing definitely faster drive access reading the headers into group windows, etc. Well done!

To be honest, your program has been so perfect for so long, the only feature I can imagine to improve would be multi-threading the header importing. Header downloading is fast and clearly multithreaded, but processing the headers once downloaded still seems to work with just one thread at a time.

If multithreading an imported header file is problematic, perhaps one thread per group could be done instead, just like the header download is done? That would still mean that the biggest groups would still take the longest time to import, but the advantage would be that all of the other groups would finish in the interim, instead of waiting in what appears to be an alphabetical file cue in the /Import directory (I'm looking at you a.b.Boneless!).

But that's a real nit to pick as Newsbin has been one of the best software purchases I have ever made!

[Quade]

I'd have to make it optional.

It's just too much load for many machines. One per group is a good idea because the database used doesn't really benefit from multiple writers.

It's worth considering though.

[grantboucher]

And that's why you are the man!

[tl]

I'd have to make it optional.

It's just too much load for many machines. One per group is a good idea because the database used doesn't really benefit from multiple writers.

Yeah, people with physical disk may well not see much benefits and could even regress. But these days SSDs are getting common, "bulk" storage on SSD is still expensive but headers would normally be on the OS disks which is increasingly often SSD.

It probably makes sense to limit the maximum number of group importers running even on fast SSDs, I doubt running more than there's cores will be beneficial (the OS will waste time moving things in and out of cores).

If was coding it, I'd probably use something like MAX(1,ROUND(#CORES*0.) to set the default number of simultaneous group importers to account for high-core count machines with hyperthreading. Limiting it somewhat below the max tends to be beneficial to UI responsiveness even with the importers running at "below normal" or "idle" priority, especially with hyperthreaded cores and even AMD is going to have that soon (Zen).

But some would argue for running up to #CORES importers by default and trust the OS scheduler to not mess it up, it's more a matter of taste and/or style than hard rules.