newsbin.com

Just about ready for final release of 6.61. The known critical issues in 6.60 have been resolved. Quade is eager to get started on the next evolution of Newsbin.

This release has two more changes:

• Fixed memory leak that was occuring when a certain style of rar file was in the NZB Autoload folder.
• Changed Sqlite caching. Improves import performance.

You can download 6.61 Release Candidate 1 from the Newsbin Beta Page.

Download issue.

All parts of download except nfo were downloaded on first pass. Newsbin then went on to get every par file for the download. Continued retrying 7 times till I got bored 15+ minutes later.

By then Quick par was already identifying all parts available.

"Assemble Incompletes" doesn't assemble incompletes: Incompletes move to the "Failed Files" tab, then selecting them and clicking "Assemble Incompletes" moves them to the "Downloading Files" tab where apparently the entire download process is repeated. Eventually the incompletes move back to the "Failed Files" tab, and no incomplete files are assembled/written to disk. Rinse and repeat as many times as desired, apparently. If, while they're on the "Downloading" tab, I re-select and again click "Assemble" THEN they are assembled and written.

This has been going on for a while, but since I'm using RC1 I'm posting this here.

Not had any issue (so far) with 'Assemble Incompletes' in 6.61RC1 b4242. In fact, just done one now and it assembled without a problem, this was from an NZB!

Still seeing an issue with compacted posts though, each individual file shows as the total of all the posts in the set! So, if the post is 10GB made up of 10 x 1GB files when each file is clicked on it shows 10GB, not 1GB. If I select them all it shows 100GB in the 'Selected Data count and size' box bottom right, been like this for many betas!

I think he's talking about assembling from the failed list. The problem is, it doesn't work. I thought I'd have it fixed for the release, then forgot.

In my own case all parts were in the download list. Even after right click auto par assembled the missing nfo when newsbin downloaded all the par's, it still just kept retrying.

One other factor it didn't happen in all downloads, so maybe something peculiar in this case.

RC1 keeps Unpausing my Paused session. I Pause a session because the headers still load, but it prevents files (SPAM) from D/Ling. I then Cull the D/L list before Unpausing.

I didn't notice this before but B1 and B3 does the same thing.

I went back to 6.60 and it's doing the same thing - didn't before. Some global setting has changed.

bertm wrote:RC1 keeps Unpausing my Paused session.

Make sure you didn't accidentally turn the scheduler on. It can be toggled by clicking in the wrong place in the Status bar. It's the 2nd element from the right if you have Newsbin maximized. You can either click on that to toggle between enabled/disabled or go under Options/Scheduler to see if it is on.

That did the trick - Thanks.

I just DLed SHaPlus Bandwidth meter to measure my usage (w/o Usenet) to consider getting a smartphone. It seems 4Gb-10GB still would not be enough for me. Anyway it resides initially in the lower right hand corner of my screen. I always "tack it" to top of the screen. I just figured out how to use Remote desktop on my 8.1 tablet. The screen is so small that I must have clicked under the BW meter.

Thanks again

I have NB stalling on pars that are separate from there main files. They sit in the list and keep retrying regardless of the number of retries set. These files have red parts and for all I know have no "main files" to attach too(I have just grabbed 30k files from a group and let them download overnight)

thx

Yeah, the logic is that they'll slowly end up downloading all the PAR files and then leave the download list. The assumption is you have loose files and don't have all the par blocks for it.

The reason retries don't matter is each time a retry counts down, the next par downloads which resets the retries.

main problem is it stopped downloading full stop, my download list just came to a halt

I doubt this is causing the download list to stop by itself. I'd check memory usage. It might be hunting down all the files associated with the PARS too.

FYI, the massive memory leak I've reported several times in before in 6.6x is still there in 6.61RC1 (build 4242).

Based on discussions on the forum I tried specifically to download with the Speed Limiter enabled and that's definitely a required part for the leak to happen, I'm fairly certain all the times I've seen it I've used the speed limiter at least part of the time. It also explains why I don't see the leak most of the time, I usually run without speed limiter.

I first downloaded some headers (without the speed limiter, memory usage looked normal afterwards), then enabled it and downloaded ~2500 files totaling ~2.6 GB, during which period the memory usage grew fast.

It's now been idle for many hours, after running Help->About it reports 200/200 (0) in cache use and the NB Pro process has a Virtual Size of 7.2 GB and a working set of 6.7 GB, definitely not normal.

OS is Windows 7 Pro, 64-bit. Statistics from Help->About, perhaps it'll help you pinpoint it.
Sqlite Memory Usage: 25847928
Sqlite High Water Mark: 54696848
Normal Blocks: 1 Memory:140312577
CRT Blocks: 0 Memory:8791768957168
Client Blocks: 1201136 Memory:0

I'll leave the process running for a few days in case you want me to check anything, the machine has 16GB RAM and it'll be fine for a while even with ~7GB "wasted" memory.

Normal Blocks: 1 Memory:140312577
CRT Blocks: 0 Memory:8791768957168
Client Blocks: 1201136 Memory:0

These numbers aren't meaningful in a release build.

Sqlite Memory Usage: 25847928
Sqlite High Water Mark: 54696848

These are and they suggest it's still importing the GZ files.

I'm specifically wondering about the size task manager reports.

I'll check out the speed limiter connection. I never use it. Thanks.