newsbin.com

Here's B11. The main complaints in B10 were pathing issues so, I attempted to address them here.

http://downloads.newsbin.com/downloads/beta/nb690B11-5388.exe


- Download: When a server is completely dead and/or say has a password problem. The server needs to be taken offline for awhile. Dead servers will now sit in jail for 5 minutes before being retried.
- Download: Download to folder named for subject, New folder and Existing Folder currently uses the unrar folder for the group. Change so that if the download path is overridden, so is the decode path. Meaning even unrars will stay in the same path.
- Download: The right click download modes for subject, new path and existing path now set the Unrar/Decode path to be the same as the download path. I assume when people pick folders, the final files they want the unrared results in that folder too.
- Download: The menu option to "Download to Folder named for Subject" is not working for me with this beta. It downloads the selected files to the Main Data Folder. Confirmed working
- Download: Make sure pathing for sonarr and watch lists sets the unrar path to the download path for the watch if there is no unrar path set.
- Display: Making a new GOG doesn’t seem to work. It doesn’t display.
- Display: Improved progress bar during header loading. Multithreaded header loading broke it.
- Display: When doing local search the progress bar doesn’t stay up.
- Search : “Show older files” will clear the current searches of your next search comes up with nothing.
- AutoPAR: Pure QPMS with no pars seems to leave source files behind
- AutoPAR: Verify which default unrar path is used when none is defined for watch lists and Sonarr.
- NZB Files: Report that you can’t make an NZB from headers in a group. - no repro so far. Tried search, watch list both search and header based.
- Sonarr: Support for “LocalNZB” mode where the name field has the full local path
- Sonarr: Some communication fixes
- Watch: Reports that a 20 gig min size filter on a watch list is missing downloads. Confirmed

This latest beta is still downloading double-clicked NZBs even though I have that setting unchecked.

When I load an NZB I grabbed from binsearch.info I see different files that when I just download the NZB (it seems it shows me files from several NZBs that I have loaded recently) and also the descriptions get screwed up with all files getting the same description as one of the files (maybe the first one in the NZB?). Other NZBs did load up fine.

Edit:
Deleting the NZBs storage.db3 in the spool folder seems to have fixed the loading issue. I know see the files I expect to see when I load the NZB.

Modern NZB's need to be fed directly to the download list if you want them to work. The obscuring has gone to absurd lengths. Many don't even list PAR files anymore, even though they're in there.

So you have removed the choice of loading NZBs to a post list on double-click?

I'm thinking about adding it back but changing the option so it re-defaults to "feed download list". You can still load them with "Load NZB" from the file menu.

Currently double-click and D&D goes right to the download list.

It would be nice to get the choice back whichever way it defaults to. I am too used to double-clicking to load NZBs.

The NZB download folder seems to be used when double-clicking on an NZB but if you load the same NZB and queue from post list the files are downloaded to the main download folder. NZBs downloaded from a watched folder also seem to use the main download folder unless a download folder is defined in it's properties.

The NZB download folder seems to be used when double-clicking on an NZB but if you load the same NZB and queue from post list the files are downloaded to the main download folder. NZBs downloaded from a watched folder also seem to use the main download folder unless a download folder is defined in it's properties.

I'd say yes that's how it's working now. I don't really have a feeling one way or the other about how it should work. I'm willing to listen to what most people want to happen there.

Past 2 beta's have lad long lags between double clicking on a GOG and it appearing on screen, 10+ seconds

B11 is better at showing the progress bar. How many days worth of headers are you loading?

You use Linux which is quite aggressive about paging stuff out. If you see no activity at all in B11 after a double-click and sitting idle for awhile, I'd assume it's getting paged back in.

I've been testing it in Linux lately. It's how I test the installer. I'm not see any delays. It's not a particularly beefy linux box too.

Quade wrote:

The NZB download folder seems to be used when double-clicking on an NZB but if you load the same NZB and queue from post list the files are downloaded to the main download folder. NZBs downloaded from a watched folder also seem to use the main download folder unless a download folder is defined in it's properties.

I'd say yes that's how it's working now. I don't really have a feeling one way or the other about how it should work. I'm willing to listen to what most people want to happen there.

My main download folder is based on the GOG and group, my NZB download folder is based on the NZB name.

I think anytime you download from NZB the NZB download folder should be used by default. Watched folders allow you to set an alternate download folder which should override the default.

Quade wrote:B11 is better at showing the progress bar. How many days worth of headers are you loading?
You use Linux which is quite aggressive about paging stuff out. If you see no activity at all in B11 after a double-click and sitting idle for awhile, I'd assume it's getting paged back in.
I've been testing it in Linux lately. It's how I test the installer. I'm not see any delays. It's not a particularly beefy linux box too.

Normally just the one day. with 3 days shown,
I have paging set to minimal, and plenty of ram/processor.
As I say only 10/11 are showing this previously it was instant. I might do a db check on the GOG's and purge them.

OK trying to purge to display age, returns "Thread died" on GOG or individual group.

Right moved the .wine folder to a different drive, down to 3 sec now, must have been the drive that was the problem/.

Any luck on the posting problem?

Any luck on the posting problem?

I've been working on something else at the moment. Some NZB problems. I will look as soon as that's fixed.

The lockout poster issue?

Same. It's high on my list but NZB issues are higher.

Something I've done lately is add a header filter to downloaded headers. I've been filtering out a bunch of the spam subjects that way.

"Poster Lockout" simply doesn't work anymore in many groups. Some groups still have good content but there's a flood of random encrypted posts too, My header filters have been tossing the encrypted spam before it's written to the DB.

DownloadFilter=X

X being the name of the filter. You can add this per group or to a topic.

I have a filter that subject rejects
"[a-z0-9]{24}.*[a-z0-9]{24}"
and
"[.]exe[.]rar"

Quade wrote:DownloadFilter=X

X being the name of the filter. You can add this per group or to a topic.

I have a filter that subject rejects
"[a-z0-9]{24}.*[a-z0-9]{24}"
and
"[.]exe[.]rar"

A set of these should be stickied somewhere.

I'm seeing an issue with "Download Special" with some (I haven't tried them all yet) groups, where I'll select Download Special: 50,000 older posts and it gets added to the downloading queue but stays at 0/0 forever (I've wait an hour and it never changes). Download All and Download Latest work properly.

Here's an example of alt.binaries.anime "Download Special: 50,000 older posts":

Stuff does appear in the log but it seems like the same stuff repeating (there are a lot of these, all the same two messages):

Code: Select all

[06/22 11:07:07]  HIGH  Giganews alt.binaries.anime GROUP alt.binaries.anime|211 29624417 465577060 495201476 alt.binaries.anime
[06/22 11:07:07]  ALWAYS Giganews GROUP alt.binaries.anime | 211 29624417 465577060 495201476 alt.binaries.anime
[06/22 11:07:07]  HIGH  Giganews alt.binaries.anime GROUP alt.binaries.anime|211 29624417 465577060 495201476 alt.binaries.anime
[06/22 11:07:07]  ALWAYS Giganews GROUP alt.binaries.anime | 211 29624417 465577060 495201476 alt.binaries.anime
[06/22 11:07:07]  HIGH  Giganews alt.binaries.anime GROUP alt.binaries.anime|211 29624417 465577060 495201476 alt.binaries.anime
[06/22 11:07:07]  ALWAYS Giganews GROUP alt.binaries.anime | 211 29624417 465577060 495201476 alt.binaries.anime
[06/22 11:07:07]  HIGH  Giganews alt.binaries.anime GROUP alt.binaries.anime|211 29624417 465577060 495201476 alt.binaries.anime
[06/22 11:07:07]  ALWAYS Giganews GROUP alt.binaries.anime | 211 29624417 465577060 495201476 alt.binaries.anime
[06/22 11:07:07]  HIGH  Giganews alt.binaries.anime GROUP alt.binaries.anime|211 29624417 465577060 495201476 alt.binaries.anime

If you have them all already there won't be any "older" to download.

I'll give'er a try. Thanks.

looking for some help. i keep having issues where a file is dl'd but it also goes to failed. shows retry count exceeded. my retry count is '2' and it has been set this way for quite some time. i have this issue with everything from sonarr, radarr & nzb's autoloaded. it is creating problems with radarr/sonarr since they get a 'failed' response & they think they need to dl another copy of a file. thank you.

Posting is working now. I'm looking at poster lockout. Probably have another beta on IRC in a day or so, then here if it looks OK.

i keep having issues where a file is dl'd but it also goes to failed. shows retry count exceeded. my retry count is '2' and it has been set this way for quite some time. i have this issue with everything from sonarr, radarr & nzb's autoloaded. it is creating problems with radarr/sonarr since they get a 'failed' response & they think they need to dl another copy of a file. thank you.

Someone reported it on IRC and I've since fixed it for B12. What's happening is a new breed of NZB's that don't even have PAR filenames in the subject so, there's no easy way to ID PARS. The last file downloads and triggers the fail even though Newsbin does unrar the file. The only way to ID what file is what would be to download the first chunk of each then re-organize the download. B12 isn't going to do that but it's not going to fail the download when it runs out of files either. There are probably other ways for me to handle it too but for now, getting something that works out is the current goal.

Someone reported it on IRC and I've since fixed it for B12.

thanks quade, sounds like a tricky fix. i appreciate the workaround in b12.

It's a real fix in B12.

I was just thinking if I want to minimize PAR downloads I'll need to re-work how download works. I'll have to probe each file to ID the contents before the real full bore download starts.

One goal is to not start a repair while it's still possible for more files to download. That's why Newsbin watches whether all the files have downloaded or not even if the PAR + repair block say I could fix any missing files into existence.

Quade wrote:It's a real fix in B12.

I was just thinking if I want to minimize PAR downloads I'll need to re-work how download works. I'll have to probe each file to ID the contents before the real full bore download starts.

One goal is to not start a repair while it's still possible for more files to download. That's why Newsbin watches whether all the files have downloaded or not even if the PAR + repair block say I could fix any missing files into existence.

oh cool. i'll wait for b12 then. i was starting to think it was because i'm using sonarr v2 at first. so this is also motivating me to setup sonarr v3 in docker on my nas. i am running radarr v3 so after i saw it do the same thing, i was wondering if there was some funky nzb issue going on.