newsbin.com

I just installed the newest build a few days ago, and it eating my 8gb up! I just did a test, were I loaded just the prg and did NOT click on any newsgroups, and let it sit for 3 5 hours. When i came back the PC said memory low, and newbin was at 5.5+ gigs of memory! WHAT?? Anyone else having this problem? I have been using Newsbin for more years that I can remember, and I have never had this problem. Also been using 6.6 since it came out with no problems. Just with this latest build... HELP!!

I've seen a couple other reports of that. Trying to remember the solution. I think it involved removing most of the DB3 files from the data folder. I'm running the 32 bit version here. it's been running for about 8 hours and it's using 200 megs of RAM. In the options select "Open Data Folder". Then exit Newsbin. I'd delete the "Import" folder then move all the DB3 files out of the data folder. Then restart and see what happens. If that doesn't work, I might re-install from scratch.

You're not running the release I don't think. You should be on 4166.

I just downloaded and installed the version off of the website, and its Build 4163. I did not have a Data directory, but I did delete the files in the Chunks folder. and that did not work either. Almost up to 2gigs of memory..

You need to follow my directions. Or reinstall from scratch.

1 - In the options select "Open Data Folder".
2 - Then exit Newsbin.
3 - Delete the "Import" folder then move all the DB3 files out of the data folder.
4 - Then restart and see what happens.

I did what you said, and its now up to 2gb of memory and slowly rising... So it did not work...

I don't know. Have probably 4000 downloads of 6.60 now and I think 2 reports of this.

I suppose a re-install from scratch is in order now. If that doesn't solve it, I might remove all your security software from scratch, reboot. Try Newsbin. If it's not growing, re-install the security software.

I really have no idea why it's consuming ram. Something is stuck.

Okay, i will re-install it tomorrow and report back. Thanks for the help!

I would like to add the same issue on my end. After leaving NB 6.60 build 4163 running for a day or two my memory usage goes into the 2-5 GB range.

I un-installed the program, and deleted all the directories. And then installed it. Set everything up. And now it works fine! Wohoo!! Thanks Everyone for your help!

I wish I knew what was happening. Oh well. I'm glad it's working for you.

Yodster - this might be the answer for you too.

Thanks Quade,
I will certainly try that, I just thought you might want to use another example to try to isolate the issue before I redo the install. Let me know if you care to have me do any testing for you.

As far as I can tell Chaz did everything I could think of. If you want to repeat what I suggested to him something might come up. I still believe there's something going on with the data files in the data folder. You can essentially delete everything except the NBI file.

I'm having the same problem, hadn't updated newsbin in a long while, downloaded and installed 6 last week. It's using memory like crazy, eventually crashing everything else running, while it still tried to soldier on, having used up 16 gigs of ram and filled the cache (it even crashed windows core processes and kept running, so I had hard rive errors the next day the first night I left it running like usual). I figured it out over the next couple days, and realized it was the new newsbin, so came here.

Anyways, I'm about to uninstall and reinstall, sbut ince I have a dozen servers in the list and don't want to have to re-input everthing, I would rather save my config .nbi and use that afterwards. For those of you who already did this and it worked, did you manually re-enter everything and set up options or use your old config file...

I'd save a copy of the NBI. Then re-install. Get it working. Then edit the new NBI and paste in the server information. You need:

[SERVERS]
List of Servers

and

[SERVER NAME1]
...
[SERVER NAME2
...

Each of these sections too. One per server.

You know, I don't know how many servers Chaz had but if you find the re-install eats RAM to. Delete all but one server from

[SERVERS]
Server Name1

Then try again. I'm wondering it a bad server could cause the appetite for RAM. Then maybe try each of the servers in turn and see if one seems to eat RAM.

10-4 thanks, I'll report back in a couple of days with my findings.

Just make sure Newsbin is closed before you hand edit the NBI or the changes will be lost.

So the full reinstall unfortunately didn't help, copying over the server info from old config files. So I did a second full uninstall (removed everything, registry, config, everything), then reinstalled clean, manually set up my options, manually input my servers. I started with just my main server, but it still had the problem, so I put in all three that I now use, (one main server with 20 connections, a 2 connection fill, and 40 connection fill server). I tried disabling each server in turn, to no effect.

I have
i7 2700k (8 core ~3.8GHz), 16gb ram, a 20 GB pagefile, system runs off a SSD.

Newsbin installed to the C: drive,
C: drive (SSD) used for the data
D: drive is another SSD, it's where the pagefile is.
E: drive another SSD not used by newsbin or system (games)
F: drive is a 10k rpm HD, not used by newsbin or system (more games)
G: drive (regular HD) used for download drive.
H-Q are more regular HDs, storage. V-Z are network storage drives mounted.

So some things to note:
- I'm not in any groups, don't download headers, I use nzb files exclusively.
- It uses more and more memory whether downloading or finished downloading. Even if the file finishes, all connections to servers are closed, no messages, nothing happening, the memory use goes up and up until...
- It will get to about 1.7 gigs used, my system monitor will say there's still plenty of memory all over available, but every other program running (explorer, chrome, various tasks) will say out of memory and start crashing when newsbin hits about 1.6-1.7 gigs memory used.
- Newsbin stays running, but isn't really working once it hits that point, files stop downloading, anything currently being unrared or par'd will stop halfway through.
- The memory use isn't linear... it'll gain 100k-1000k memory use every few seconds, sometimes not increasing for a good 10-20 seconds, sometimes increasing constantly and rapildly for 20-30s.
- Takes about 1-3 hours to crash everything.
- If you close it and restart it every hour, it works fine, downloads work, everything goes fine.
- I've tried disabling other running programs that interact with network info (netbalancer, avast, etc), no effect on the issue.

So it opens up, empty and no files at 40 mb use of memory.. slowly climbs. Adding an NZB will jump it's memory use up to about 200-300 megs right away, but then the increase is the same. But even if you open it, empty, nothing downloading, servers not connecting, nothing happening, still leaking.

*edit*
Just tried opening it with no nzb's loaded, all logs and files cleared, all three servers disabled, still leaking.

So it opens up, empty and no files at 40 mb use of memory.. slowly climbs. Adding an NZB will jump it's memory use up to about 200-300 megs right away, but then the increase is the same. But even if you open it, empty, nothing downloading, servers not connecting, nothing happening, still leaking.

I can't repro this part. 200-300 megs while downloading isn't unusual. The creep thought is. At this point I don't know what's causing it and why it's not happening to me. I wonder if a clean NBI would reveal it? Might clean out my NBI and try.

If you look in the options, is the remote control interface enabled? If it is, how about disabling it and restarting and see if the memory use still grows.

Remote NZB integration and Remote Control both disabled. Scheduling disabled. It's pretty close to a default install, except changing the download folders, and putting in the server info, but like I said, it's leaking as soon as it's opened, even with all servers disabled and absolutely nothing going on whatsoever.

Would you like me to pm you my current nbi file for you to take a look?

*edit*
Also, pulling up the resource monitor for more details, when I open an otherwise idle newsbin, I see some wierd behaviour.

Commit starts way small, down at about 85mb, working set, about 25mb, shareable 18mb, private 44mb.
The commit starts to grow VERY fast. (mb, i'm converting the KB)
For the columns commit - working set - shareable - private
Within 1 min, i'm seeing 264 -68 - 18 - 50
at 2 mins, I'm at 398 - 70 - 18 - 53
at 3 mins, I'm at 532 - 76 -18 -59
at 5 mins, I'm at 801 - 87 - 18 - 68
at 10 min, I'm at 1561 - 119 - 18 - 100

So it was the commit that was causing all my other programs to crash out, since it's reserving all my virtual memory eventually. It shouldn't be growing that fast, and neither of course should the working set really be growing at all, nor the private like it is when newsbin is completely idle. Just double checked my pagefiles, they're spread on three disks, none C drive, from 16mb to 8 gigs range, starting out at 528 mb total, and growing as needed to a max of 18 gigs. With newsbin running about 25 mins earlier, it's up to current paging file of 4 gigs.

I tried doing the help-about mentioned in the other thread, it had no effect on my leaking, idling newsbin numbers. I'm also using win 7 ultimate x64

Yeah, this leaking is totally out of the ordinary. Even the one time I detected a leak, it was nothing like this. I tried a clean NBI file too.

In task manager, you can turn on a column that shows "Handle Count". Might be interesting to see if the handle count goes crazy too. Is your windows install on the C drive? Might be interesting to see if the thread count is going up too.

What I'm guessing at this point is that something is happening over and over again which shouldn't. Like a file is being opened but not closed.

Do you see anything in the logging tab?

When I'm idling, and this is happening, there's nothing visible in logging, nor are any servers connecting, it's truly just sitting and idling as far as I can tell. Is there any cache or download area or anything on C:/ that might not have gotten reset with the full uninstall?

Win 7 is installed to C:

Both Handles and threads are steady and holding at 835 and 79 respectively. If they're going up, it's much slower than the various memories.

Appreciate the feedback. I'm looking at it.

So I was going to simply revert/use the 32 bit version of newsbin as you suggested in the other thread (I've gotten tired of closing an opening newsbin every 30 mins); however, the installer autodetects 64 bit. If I use the alternate installer, it contains both 32 and 64 bit, but then detects 64 bit and installs that on install. In the archives, I would have to go back to 5.54 to get a 32 bit only installer... is there a standalone 32 bit installer somewhere that I'm missing on the download page?

Are you on Win7 64? I've been trying to track this down. One person this was happening to, it went away when they upgraded to Win10.

I'll have to check with Dex on the installer. I thought you could override the bits. That might be on fresh install though.

win 7 x64 ultimate

Definitely not upgrading to win 10 :p

Didn't get an option to override the bit choice, it just starts in on the 64 bit version.

I've got a machine to install Win7 on. I'll try that next. I'm skeptical of a Win7 connection but that's all I have to go on right now.

I disabled the option to force a 32 bit install on a 64 bit system. It was surprising how many people would get confused, not know if they were 32 or 64 bit, and send in tech support requests asking what they should do. If you still want to force 32 bit I'll upload a rar file for you somewhere so you can extract the 32 bit executables.

I'd appreciate it, I understand the reasoning too, lots of people click through installers without reading anything.

PM'd a link

Experiencing the same thing. Here's a quick snapshot of the resource usage:



That's just opening Newsbin and sitting there. It'll continue like that until it uses up all available paging space, and then Windows will crash.

I'm going to try some of the solutions above. I'll report back with any findings.

dexter wrote:I disabled the option to force a 32 bit install on a 64 bit system. It was surprising how many people would get confused, not know if they were 32 or 64 bit, and send in tech support requests asking what they should do. If you still want to force 32 bit I'll upload a rar file for you somewhere so you can extract the 32 bit executables.

Dex, I think disabling the 32-bit Install Option on a 64-Bit OS does a disservice to the more advanced users and to some degree penalizes them. I have mentioned this to Quade before as well. I also understand you guys are probably driven nuts by the less experienced users and it takes a lot of time and effort to bring them along. I, for one, read what is placed on the screen by Installers, so please think about us other guys.

Will also say that offering a 32-bit Install on a 64-bit OS can be a very good thing. I have read where Installing MS Office in 32-Bit Mode on the 64-Bit OS can help with compatibility issues with other software and internal MS Office operability.

Just my 2 cents

Thanks

I'm going to try some of the solutions above. I'll report back with any findings.

What's the lower trace showing? There seems to be a connection between those spikes and the memory usage.

Is this Win7?

TBlack wrote:Dex, I think disabling the 32-bit Install Option on a 64-Bit OS does a disservice to the more advanced users and to some degree penalizes them.

The tradeoff is this: Answer 10 tech support requests per week telling people to ignore the option to install the 32 bit version and let Newsbin figure it out for itself or supply the 32 bit version separately to the one person per month or so who asks for it. It's like a 40:1 kindof decision.

If you want the 32 bit version, let me know and I'll send you a link.

Dex,

I understand the complications (or think I do ) because I used to administer a very unique Access Database App at my former company. Just thought I would share an opinion. You guys do a great job of educating and bringing users along and you post helpful tips on the Forums. Hopefully, some users will read and research before asking some questions and/or complaining.

Appreciate the offer for a shortcut, but am good to go. I run a 32-Bit OS so rarely do I have a conflict or issue between 64 & 32-bit. Also run an i7 machine so the real difference between 64 and 32-Bit performance is minimal and not worth worrying about compared to struggling with potential software issues between 64 and 32-Bit.

Thanks

Unfortunately using the standalone NB661B3 32 bit version I was sent... same problem.

Commit grows rapidly, working set less so, but eventually crash and burn. I didn't actually leave it open to the point of crashing though, just watched it eat up to 2 gigs. I'm leaving one open now to the point of crashing, I'm hoping that a 32 bit version would stop at the 4 gig barrier???

I might just write a script that will close and open newsbin every 30 mins when activated... though that seems like a terrible workaround to have to use.

I have a Win7 ultimate VM I made. First I ran 6.60 before patching it. Then I ran update, let it update and ran it again. In neither case does the ram climb.

I'm thinking it's got to be something in the NBI file. Wonder what a re-install from scratch would do?

Didn't work, remember I did the full uninstall and clean install. Also didn't make a difference for 32 bit, went right through the 3.5 gig barrier and I stopped it a couple mins ago at 10 gigs commit.

I can send you my NBI file for you to check out if you like.

Could it be related to having different drives doing different tasks (download drive, working drive, and install drive all separate)?

Quade wrote:

I'm going to try some of the solutions above. I'll report back with any findings.

What's the lower trace showing? There seems to be a connection between those spikes and the memory usage.

Is this Win7?

CPU, Memory, Disk, in order. Disk spikes were mostly reads. Theorizing that something is reading from disk cache every 10 seconds or so, but never clears what it loads.

Running Windows Server 2012 (64-bit).

Nothing I tried (reinstall, clearing out the data folder, modifying cache settings) prevented the issue. I eventually grabbed 6.56 from the download archives and am currently using that without issue.

FatalXception wrote:Didn't work, remember I did the full uninstall and clean install. Also didn't make a difference for 32 bit, went right through the 3.5 gig barrier and I stopped it a couple mins ago at 10 gigs commit.

I can send you my NBI file for you to check out if you like.

Could it be related to having different drives doing different tasks (download drive, working drive, and install drive all separate)?

Possibly anecdotal, but I have the install, data, and download locations on different drives as well.

We looked at someone's NBI file and they had the NZB Autoload folder set to something that might have been a large folder. I'm leaning in the direction of something like that. That Newsbin is set to scan some large folder with many files that's what it's doing. It would explain why it's not happening to me. The disk spikes suggest it's related to that too.

Quade wrote:We looked at someone's NBI file and they had the NZB Autoload folder set to something that might have been a large folder. I'm leaning in the direction of something like that. That Newsbin is set to scan some large folder with many files that's what it's doing. It would explain why it's not happening to me. The disk spikes suggest it's related to that too.

Tested and confirmed. Had an autoload watch setup for a big unsorted download folder. Removing that solved the memory leak.

Sweet, that's good to know. Now I just need to come up with a fix. I can throw a file count limiter on it but I'm not sure that's a good solution.

Yup, got back today.. deleted the auto-loading directory, immediate result, no longer growing commit. So that's the thing then, Just have to click on the nzbs after downloading now, much easier than closing and opening newsbin.

Of note, the monitored directory didn't change when I went to build 4163, it didn't used to exhibit this behaviour.

Just have to click on the nzbs after downloading now, much easier than closing and opening newsbin.

The problem isn't monitoring a folder. It's monitoring a folder with many files in it. If you change the autoload folder to smaller folder or cleaned out the old folder by moving the files out of it, it wouldn't grow like that. Newsbin must be finding a bunch of files in that folder for this to happen.

It is, it's my default download folder for browser downloading.

It's also something new, since the older versions had no problem with the directory, and it was bigger than it is now (I did try cleaning it out some earlier, before i just turned off monitoring). It's rather annoying to switch back and forth choosing different download folders based on nzb or exe or other files from the web, everything just goes there when I download while browsing. That said it's only about 350 megs in 120 files, so it's not really that big, it's got a bit of everything though, jpg, zip, exe, bin, pdf, etc etc. I wonder if it's a specific file or type of file that's causing a problem, like one of the zips, since I know the monitor would get multiple nzbs inside an archive when they're downloaded that way.

I'm monitoring a folder with 14,000 files in it. Normally I don't have any files there but I threw some in because I suspected autoload.

How many files are in this folder and subfolders?

If you include all subfolders, it's 557 files and 601 MB

I'll note that one sub-folder is the 'loaded' NZB folder where newsbin put the loaded NZBs with the autoloader.... it used to have thousands and thousands of NZBs and be hundreds of megs, though I cleaned it out a few weeks ago hoping it was the issue, it's now 126 files, 33 megs.

I'll try emptying it out and turning back on monitoring.

*edit* nope, even empty, so there's no nzb files in downloads or sub-directories, either alone or in zips, it still grows as soon as monitoring is turned on. That also makes the total of directory + all subs now a smaller 431 files and 564 MB

EDIT2
Just found out a big one.. If I remove the 7 .rar files from my downloads directory, with monitoring on, the leak stops. They're all between 1kb and 5.3 megs (7 files, 15.7 MB). So it's .rar files. I'll test to see if it's one, all, or any single files doing it.

EDIT 3
http://s000.tinyupload.com/index.php?fi ... 6221176859 <-The 1k rar file I'm talking about.
After some moving of .rars in and out, I find the memory grows VERY slowly with .rars in (but it IS growing).. unless you put this tiny 907 byte rar'ed text file in... then it'll grow 20-40 MB a second. It's literally a switch. Put in tiny 1kb .rar file, memory usage grows, take it out, it stops. I'm going to guess it's reserving memory rounded up to the next 32k or 64k or whatever, then not releasing that each time it looks at .rar files, which is why larger rar files grow the memory much slower?

Thanks for the file. The bug is in the winrar code itself. Every time it tries to unrar this 1K file, it consumes 35 megs of memory. Looks like I might need to update to the latest RAR code and hope they fixed it (or track it down myself).