Version 6.82 Beta7 Available...

[dexter]

Beta 7 has improvements to Sonarr Category support. If there are no showstoppers found, this will likely become the production release. You can download it from the Beta Page and let us know if there are any issues either by replying to this thread or through our Technical Support Form

[Elastic]

I downloaded and installed this morning (from 6.82 Beta 3) just for kicks, but it reads "6.82B6" in the titlebar and Help --> About Newsbin Pro also reads "6.82B6". Was there a compile problem in getting this one to Beta7, or is the "Beta 7" in this forum topic a typo and it's "Beta 6"?

[kirm]

I downloaded and installed this morning (from 6.82 Beta 3) just for kicks, but it reads "6.82B6" in the titlebar and Help --> About Newsbin Pro also reads "6.82B6". Was there a compile problem in getting this one to Beta7, or is the "Beta 7" in this forum topic a typo and it's "Beta 6"?

Confirm the same. Even though the file nb682.5109.B7 is slightly larger than the previous nb682.5103.B6 it is not reflecting current build anywhere.

[dexter]

Sorry about that. I just re-built it, downloaded and tested and it really is B7 now.

Thanks for letting me know.

[depredador]

I presume from looking at the improvements that NBP and Sonarr should now work together properly for files with no pars?

[Quade]

1 - I tested with a RAR set and no PARS over the sonarr interface. It downloaded an unrared with no issue.

2 - I tested with a mildly obscured set meaning the filenames of the rars has no identifiers but the rar extensions were there (.rar,.r01). It downloaded and unrared with no issue. This one had an SFV in it too.

3 - Heavily obscured, meaning no extensions and random filenames won't work without pars. Because there's no information about what the filenames should be without the PARS.

There might be some way to make #3 work in the presence of an SFV file. Typically with #3, it's not obvious what file is the SFV if there is one.

[ItsMe]

When you click on Help -> View the MOTD archive...

It is hard coded to take you to 2018 archive instead of the 2019 archive...

[Quade]

I'll mention it to Dex. Thanks.

[dexter]

When you click on Help -> View the MOTD archive...

It is hard coded to take you to 2018 archive instead of the 2019 archive...

It's actually a redirect, I just fixed it. Thanks for pointing it out.

[tongueboy]

It changed my download path.
In the settings it is still the same as it always was, E:\Downloads\$(LONGGROUP)\$(NZBFILE)\
Now it just places the files in the main download folder instead of in group folders.
Nothing on my end changed other than the new beta.
Also seem to be having more problems with encrypted files but will give it another try tonight.

Went back to 6.81 and the download path works just like it used to.
May not be a problem for most but definitely a problem for me.
I'll wait for the next beta and try again or just stay with 6.81.

[wissertje]

Sins a few latest beta's, if i load a nzb and newsbin opens, my CPU fan spinning on full speed. If i look in newsbin, i see instead of the filename, display update pending: followed by a number, but the number is every time different. The download speed is very low as you can see in the screenshot. Once display update pending is gone (after seconds of 10/15) and i see the filename again everything is normal and going full speed. If i install 6.81 everything is working normal. I have a 750/750 Fiber connection. Newsbin downloads the files on a M.2 SSD Samsung 960 EVO, system is Core i7 7700K, 16GB RAM.

I made the filename black. I don't want to bring you in any problems. It happens on all nzb's i download.

[Quade]

You've got the cache set to use at least 8 gigs of RAM it might be as high as 16 depending on the chunk size. The newest versions don't really benefit too much from monster caches so, you might want to try setting it to maybe 400.

You have all the symptoms of either running out of RAM or some sort of disk issue. The reason I say that is slow download, slow access to the download DB (which is why you see the "Pending" messages suggests something disk related.

I'd probably start by using the "Open Data Folder" option in the options, exit Newsbin then delete "DownloadsV2.db3" and maybe "Downloaded.db3" then restart. You might want to check the other DB3's in this folder too. None should be very big. If that doesn't solve it, I might make your virus scanner ignore the data folder. You don't seem to have much in the download list so it's probably safe to wipe it.

[DrMASE]

Hi All,

I am really confused about something in 6.82B7. For some reason I am now getting files saved in the $longgroup ("alt.binaries.e-book" for example) if I understand the variable correctly, rather than $group ("a.b.e-book" for example). I checked my settings and it still has "O:\Program Files\Newsbin\Main\$(GROUP)\" in the main download folder. I tried adding "O:\Program Files\Newsbin\Main\$(GROUP)\" to properties for "a.b.e-book" and it still downloaded to "alt.binaries.e-book".

I was not getting this behavior from beta 5. I am using still using Newsbin on Windows 7 x64, so that might have something to do with the change.

Is there a variable I can change to get the short folder names?

Thanks!

DrMASE

[Quade]

It's broken. I've already fixed it. It'll be in the next beta or final release whichever one comes first.

[DrMASE]

Awesome! Thank you!

[stavros]

Sins a few latest beta's, if i load a nzb and newsbin opens, my CPU fan spinning on full speed. If i look in newsbin, i see instead of the filename, display update pending: followed by a number, but the number is every time different. The download speed is very low as you can see in the screenshot. Once display update pending is gone (after seconds of 10/15) and i see the filename again everything is normal and going full speed.

Another cause of the 'update pending' is when the d/l file is password protected and the number of passwords stored in the NB password file (RarPasswords.txt) is large and the password is not in the list (or maybe near the end of the list).
The gui seems to be unrepsonsive while NB is trying the passwords to unpack the file.
I don't know what threshold starts to slow things down - probably different on each system - (> 20,000 about 2mins delay on my system).

I'm not sure if this might be the case here, but perhaps something to check.

regards
Stavros.

[Kraut2003]

Hi Stavros

thx for the tip - this may be the reason why my Newsbin on a fast RYZEN System with 32 GB RAM WIN 10 64 Bit needs so much time when I use NZBs with PW protected Files behind
may be a reason for me to clean up the PW list from time to time bec. the sources I get my nzbs from always suply the pw within the nzb so there is no need to keep up a big list

Greetings from Germany

Thomas

[mxrevolution]

this beta 7 is really a pain

it takes minutes until downloads start and when it auto imports nzbs,
it sometimes lags for 20+ minutes - completely frozen

there must be something with the database
queue has 2000 entries but all are paused, chunks folder is empty

system is rock solid win10 with 16gb ram and corei9

[Quade]

The gui seems to be unrepsonsive while NB is trying the passwords to unpack the file.

Password checking is happening in a thread but both the thread and the GUI are contending for the disk. Honestly anything over maybe 50 passwords is probably going to cause some slowdown. It doesn't have to unrar much to check the password but 1000's of passwords = 1000's of unrars.

At one point posting groups might use the same password for awhile. Now it's looking like maybe "a password per posting" so maybe the old way needs to change so, essentially the password list goes away and you have to assign a password per download. Or the list needs to note the age of the password and throw the old ones away.

Is there actually a need to keep old passwords around anymore?

[Quade]

it takes minutes until downloads start and when it auto imports nzbs,
it sometimes lags for 20+ minutes - completely frozen

This beta isn't that different than the last. It's just got a couple bug fixes from the prior version. I'm not seeing any slowdown so, you might be right that your download list DB has gotten screwed up. Deleting it will wipe the download, wish and failed lists. You might make any virus scanner ignore the Newsbin data folder too. A new beta probably requires you to reset any special security changes you added for Newsbin.

As stavros pointed out, if you use passwords, it might be time to clean the password list out.

[Kraut2003]

Is there actually a need to keep old passwords around anymore?

may be put in an option to clean out the PW List after X Days automaticly in the settings

Greets

Thomas

[mxrevolution]

it takes minutes until downloads start and when it auto imports nzbs,
it sometimes lags for 20+ minutes - completely frozen

This beta isn't that different than the last. It's just got a couple bug fixes from the prior version. I'm not seeing any slowdown so, you might be right that your download list DB has gotten screwed up. Deleting it will wipe the download, wish and failed lists. You might make any virus scanner ignore the Newsbin data folder too. A new beta probably requires you to reset any special security changes you added for Newsbin.

As stavros pointed out, if you use passwords, it might be time to clean the password list out.

i keep passwords, but my file is only 47kb large and has only 1600 passwords
i just deleted the old databases and cleaned the chunk dir, checked the virus scanner is off ...
importet nzbs ...
but newsbin starts dl with 30 mbit... and stops for no reason again ..

this behavior is NOT new to me, since i tried many 6beta versions, and had always to go back to a stable one ...
what freshly installed runs in a second with 55mbyte/sek dl

but that stable one is kinda outdated now and i am suffering more and more coz of this stupid
new confuscated files nonsense ... the last days i had 50% not unpackable files..

i am on a 400/40 mbit line

[Quade]

keep passwords, but my file is only 47kb large and has only 1600 passwords

That's way too many. Try to keep it under 100. With 1600 passwords, that means on average it'll have to try unraring 800 times to find the password.

but newsbin starts dl with 30 mbit... and stops for no reason again ..

I get a constant 120 Mbps. Constant. I have to turn the bandwidth limiter on to slow it down. As an experiment, you might remove any non-microsoft virus scanners and firewalls, then reboot and try some downloads to set a baseline. Then add them back in till something slows it down. You ought to be getting close to 400 Mbps. Several of my users get twice that speed.

[stavros]

At one point posting groups might use the same password for awhile. Now it's looking like maybe "a password per posting" so maybe the old way needs to change so, essentially the password list goes away and you have to assign a password per download. Or the list needs to note the age of the password and throw the old ones away.

Is there actually a need to keep old passwords around anymore?

Keeping old passwords is essential if one goes back and downloads old stuff every now and again. Trying to find an old password is really difficult after a couple of years!
I'd really not like a forced automated tidy up of passwords, without the option to switch it off.

If it is just disk contention, is there a way to 'pace' or 'throttle' the password checking thread, so that it allows the gui thread a go at the disks every now and again? Maybe every 10 (20?, 50?) attempts at checking a password?

thx for the tip - this may be the reason why my Newsbin on a fast RYZEN System with 32 GB RAM WIN 10 64 Bit needs so much time when I use NZBs with PW protected Files behind
may be a reason for me to clean up the PW list from time to time bec. the sources I get my nzbs from always suply the pw within the nzb so there is no need to keep up a big list

You're welcome, Thomas. I hope it helps.

What I do at the moment is have a 'master' list of passwords and a 'current' list. The 'current' list is the one actually used by NB most of the time, and I switch in the 'master' list when needed.
This is a bit cumbersome, and maybe a slicker way to manage this would be useful, but it keeps the impact of a large password list down to a minimum, while keeping the usefulness of a large list available.

regards
Stavros

[Kraut2003]

Hi Stavros

for me it seems to work with a cleaned up Password list and Beta 7 for now - I will watch it for now - I do not need to keep my pws bec. I get the pws with the nzbs I use.

Greets

Thomas

[Quade]

If it is just disk contention, is there a way to 'pace' or 'throttle' the password checking thread, so that it allows the gui thread a go at the disks every now and again? Maybe every 10 (20?, 50?) attempts at checking a password?

There are simply practical upper limits to how many passwords you can keep. There's no fixing it. The more passwords you have, the slower it'll be. It's simply the nature of the beast.

If you want to keep the old passwords, you should maintain you own copy of the passwords someplace else that you can copy into place if you want to resurrect an old file set.

[stavros]

If it is just disk contention, is there a way to 'pace' or 'throttle' the password checking thread, so that it allows the gui thread a go at the disks every now and again? Maybe every 10 (20?, 50?) attempts at checking a password?

There are simply practical upper limits to how many passwords you can keep. There's no fixing it. The more passwords you have, the slower it'll be. It's simply the nature of the beast.

Thanks, but it doesn't answer my question - I was just trying to ask about a possible way to alleviate the symptoms arising from disk contention between the two threads causing the gui to appear unresponsive. I wasn't suggesting or trying to make the password check thread go faster, just trying to make the user experience better. I'm no longer a programmer, so if it isn't feasable to do this, for whatever reason, so be it.

If you want to keep the old passwords, you should maintain you own copy of the passwords someplace else that you can copy into place if you want to resurrect an old file set.

This is exactly what I currently do, a bit cumbersome, but effective.

regards
Stavros.

[Quade]

Faster disks? Having the data folder and download/unrar folder on different drives maybe? If you're using a non-Microsoft security package, that might be killing performance too.

1000 passwords = about 500 unrars before the password is found. The model breaks when you go over 100 passwords or so.

The only "fix" is probably to note older passwords and purge them from the active password list.

[Benjy]

It changed my download path.
In the settings it is still the same as it always was, E:\Downloads\$(LONGGROUP)\$(NZBFILE)\
Now it just places the files in the main download folder instead of in group folders.
Nothing on my end changed other than the new beta.
Also seem to be having more problems with encrypted files but will give it another try tonight.

Went back to 6.81 and the download path works just like it used to.
May not be a problem for most but definitely a problem for me.
I'll wait for the next beta and try again or just stay with 6.81.

I can confirm this bug on my end too.