newsbin.com

The big news for Version 6.40 Beta 3 is that it has the ability to apply variables to create download paths. Anyone that uses Folder Mode will need to update their download path. For example, you'll stick a $(GROUP) variable in the path to get the newsgroup included. There are many more variables allowed now. Quade has outlined them in this forum post

Summary:

• Path variables can be applied for custom download path assignments.
• Re-arranged options menus to group related options together and simplify the look.
• Fixed performance option to disable file write during unrar/repair. Got broken in 6.40B2
• Fixed issue with "Assign a New Path" not remembering the last path used.
• Other enhancements and bug fixes

Many more details and the download link are on the Newsbin Beta Page.

For some reason, Got a Crash on exit the 1st time I closed it.

And I don't crash any more if I run NBP 6.40 Beta 3 and exit without downloading anything.

I'm having a small problem with beta 3: any folder to which NewsBin downloads something, has a CHUNKS-subfolder which doesn't get deleted, not even when NewsBin is finished (empty download window) or even shut down. I've taken a look at the Options, but can't find anything related.

If memory serves, this started with 6.40 beta 2 but not before.

What could cause this?

Edited to add: I found this in Newsbin.nbi:

Code: Select all

[Performance]
...
SaveChunksMode=1

...which probably means it's caused by Options > Performance > Write Downloaded files with No memory buffering. If that's the case, would it make sense for NewsBin to, even with this option set, delete the CHUNKS-subfolder when downloading to that folder is finished?

hmz, found a little bug.

I download to the root of a partition. My download path is just E:\
Doubleclicking an NZB opens it in Newsbin (so far so good), then I doubleclick the set of files that I want and it used to start downloading.
Not anymore.
I can doubleclick, rightclick->download, rightclick download bypass filters. Nothing happens.

Change my downloadpath to E:\SomeDir\ and it's fine.. it somehow refuses to download to the root of a partition.

That's a good one. Thanks.

Pause Download during UnRAR/Repair appears to work as I would expect. In the test I did, an Unrar started, the cache filled up till it was at 2/100, then downloading stopped till the unrar finished and the cache didn't try to write to disk during the unrar. And everything resumed nicely after the Unrar was done. Very nice! Thanks.

Quade wrote:That's a good one. Thanks.

Gets weirder..
I changed the downloadpath to E:\$(NZBFILE)\
It now downloads to E:\

And the NZB does have a name, so something's not right.

possamai wrote:

Quade wrote:That's a good one. Thanks.

Gets weirder..
I changed the downloadpath to E:\$(NZBFILE)\
It now downloads to E:\

And the NZB does have a name, so something's not right.

That IS strange!

I have it set to U:\DOWNLOAD\$(NZBFILE)\ and it appears to be working or me. I assume you added the relevant NZB file AFTER changing the download path? Just checking as items already in the queue would not have thier path changed.

Yes, before adding the nzb
I'll try pinpointing the issue some more..

Could you perhaps set the download path to U:\$(NZBFILE) to see if that gives the same issue as I have?

I'm trying an internal version with the nzb extract to the root of a drive and it works fine, it's pretty recent so it's possible it's been fixed already. Given you're getting odd behaviour extracting at the root of a drive with the version you're using, I wouldn't blow your brains out on this until the next version is released. It seems ok here, but never would have thought to test that.

DT

Hi

The problem that NB stops downloading (writing to disk ????) still exists.

the following warning occurs in the logging tab when i use debug logging and keeps repeating
[07:16:14] DEBUG - Cache Miss: Larger chunk cache might perform better

My my chunk cache is 200 i will try again with a larger chunk cache and report the results

looked with the resource monitor from window an NB has no files in use anymore

regards,

Jan

Is there anything special about the drive it's writing to? Sounds like writing just stops. Either the worker thread that does the writing dies or there's just some problem writing the files. Do you have "disable download while unrar/repairing" set?

tried both options on and off made no difference nothing special an the drive its writing to NB 6.3 and before are working without any problems the problem began with version 6.4

At the moment i'm using a chunkcache=1000 and it is now stable stable for just about 12 hours i will continue testing this setting en let you know the results

regards,

Jan

Quade wrote:Is there anything special about the drive it's writing to? Sounds like writing just stops. Either the worker thread that does the writing dies or there's just some problem writing the files. Do you have "disable download while unrar/repairing" set?

Why change a perfectly working program again!

I was asking myself that this morning too.

The answer is that people want more control of where the files are unrared and downloaded and the current scheme using checkboxes for every option had become too complicated for anyone to understand. Even me. Nearly impossible to test too. I do believe that you'll find the new way to be easier to use in general even though it's probably going to take some learning curve. One of the common complaints from users is that Newsbin is too hard to use. I think this change will make it easier to use. It's just not quite there yet.

I'd suggest not running the beta if you need things to be perfect. It's a big change and it's not 100% yet.

You don't HAVE to upgrade. 6.33 is pretty good.

Well, time will tell... majority of users decide. Or? We'll see.

Why doesn't it include the name of the NZB in the foldername?

Code: Select all

D:\Newsbin Downloads\$(NZBFILE)\

Because it's beta and that part is broken.

= Display: NZB Files in the post lists don't seem to include the NZB in the pathing.

It's fixed in the internal beta.

I don't know if this is the same problem the poster further up in this thread had... but:

My standard DL-path is D:\ which was working fine until this beta. Now when I add a NZB it will get queued but it has no path assigned, I have to do that manually. If I forget the files will be skipped and I'll get an error message saying nb2 could not be written.
Also: When browsing a group and trying to add a post to the queue via double-click or enter it will not be added. It only works if I right-click and assign a path myself.

Yeah. "can't download to root path" is a known problem in the beta. Fixed in my internal beta which will eventually get punched up. You can revert to an older beta or add something to the download path like "D:\DL\"

It just happened again

[15:07:34] DEBUG - Cache Miss: Larger chunk cache might perform better

It looks like NB consumes all the cachechunks and then stops
With chunkcache=1000 its a bit more stable

Reagards,

Jan

JanJonkman wrote:tried both options on and off made no difference nothing special an the drive its writing to NB 6.3 and before are working without any problems the problem began with version 6.4

At the moment i'm using a chunkcache=1000 and it is now stable stable for just about 12 hours i will continue testing this setting en let you know the results

regards,

Jan

Quade wrote:Is there anything special about the drive it's writing to? Sounds like writing just stops. Either the worker thread that does the writing dies or there's just some problem writing the files. Do you have "disable download while unrar/repairing" set?

It looks like NB consumes all the cachechunks and then stops
With chunkcache=1000 its a bit more stable

Reagards,

Jan

Yeah, I didn't think this was a fix. You're just putting off how long it takes before it runs out of buffers. What I'm not clear on is why the buffers are leaking away for you. Apparently something about how you download or your system is making Newsbin leak packets. I'm not saying it's your fault. Just that there seems to be some specific path that lets them leak.

A bug in Newsbin for sure. I'm just not sure how to reproduce it.

As an experiment, how about checking the "don't use memory buffers" box in the performance options. Restart Newsbin and see how it works.

Can anyone tell me how to enable debug mode again?
I can't find it with the search...
Using beta versions it may be wise to enable it

I don't think you can do that as an end user, needs to be compiled that way, no? AFAIK debug mode has serious performance hits which would make it impractical to implement on a release, even a beta.

DT

There's a debug logging level in the advanced options. It just turns up reporting.

As D says, actual debug mode, like I work with has to be compiled in.

I download and extract everything to "F:\Usenet Downloads" I also have a third party program detect, rename and move files that are extracted into specific folders depending on what the file is. In the latest beta I found a lot of the time (I can't remember the exact procedure now as I've reverted to 6.33) once the "Usenet Downloads" folder is emptied newsbin will delete the folder (which then causes problems for anything else trying to access that folder). Is this a bug or is there an option with the new folder settings in newsbin that I need to enable/disable?

It's by design. It's in the releasenotes.
I think it's great I no longer have to manually delete the empty folders.
I love it!