newsbin.com

Getting pretty close to done....RC3 is here.

http://downloads.newsbin.com/downloads/ ... 3-5462.exe

MP3 Parser: APIC fields could prevent the reading of ID3 frames that follow. Meaning sometimes Newsbin couldn’t find the ID3 fields for using them to name folders for MP3's

AutoPAR: Solved another new type of obscured files not renaming.
AutoPAR: More rename modes for more kinds of obscured posting.
AutoPAR: Some renames didn't work because Newsbin wasn't look at the first chunks for the filename.
AutoPAR: Files with no extension now get probed and extension added. Some case where the unrar produces files with no extension at all. This is in addition to normal rename modes. It applies to all files types.

Display: Remove force compaction from loading NZBs or conversely make it smarter.
Display: “delete all posts” from post listing was using wrong delete. Switched it to only deleting headers and not rangeDB. This means "delete all" from a post list won't trigger downloading older headers.

Download: 0/1 parters linger in the download list.
Download: DNS errors cause a strange error report
Download: Re-implemented support for old header formats. If you tried to queue a local file and it didn't enter the download list, this is probably the fix you need.

NZB: Remove force compaction for “Load NZB”.
NZB: Make sure samples don’t get mixed in when doing forced compaction.

I discovered something late and didn't want to hold this up. Make sure you set proper download folder in the "Remote NZB (which is the Sonarr stuff". I noticed the default unrar path doesn't seem to be full path. It could just be cosmetic though.

There's really only one more thing I want to implement before release. A fix for a potential problem when an NZB describes a file that's not on your server yet.

Apologies, but I'm confused. I just checked, and with both RC2 and RC3 one still can't successfully post to a group unless there is an attachment (reported with RC1). Given this, is the problem unique to me and/or not duplicatable? Just checking that I've not missed a discussion or decision on the topic....

Regards.

I just haven't gotten to it yet. I'm aware of the report though.

Hi Quade,

Many thanks for this update :

Display: Remove force compaction from loading NZBs or conversely make it smarter.
....
NZB: Remove force compaction for “Load NZB”.

It makes the Load NZB function usable again for me

One thing I have noticed is that when I d/l from an NZB via "Load NZB", Newsbin 6.90RC3 is no longer obeying the NZB Download folder from settings
- it is putting the downloaded files in a strange folder. e.g.

My DL folder for NZBs in settings is "F:\DL\_NZBs\$(NZBFILE)\"
In the Files list, as the files are being downloaded, they are going, in my case, to "F:\DL\a.b.misc".
Then they're being unrared to the correct unrar target of "F:\DC\$(NZBFILE)\$(GOG)\$(GROUP)\",
which in my case is "F:\DC\$(NZBFILE)\unsorted\a.b.misc\".

Not a great issue, my only (minor) concern is that if the unrar fails for some reason, then the downloaded rar files end up in a strange place,
and mixed up with other files in the selected directory.

I think that in the past, the NZB download folder in the settings was obeyed.

regards
Stavros.

Apologies, but I'm confused. I just checked, and with both RC2 and RC3 one still can't successfully post to a group unless there is an attachment (reported with RC1). Given this, is the problem unique to me and/or not duplicatable? Just checking that I've not missed a discussion or decision on the topic....

By any chance, are you using Newshosting. Have not run rc3 yet, installing now. This posting to group has not worked for me as well for some time. Posting is enabled on their web site. It's one of those features I rarely use, so not positive when this started to fail.

Regards,

Still downloads sample only when using with Sonarr sometimes. Back to 6.82.

I'll send you the file.

The file you sent me last time didn't have any samples in it. As far as I could tell. It was just a bunch of obscured files.

Anyway, appreciate the NZB when you send it.

I still have your old one too. I'll check it again. I have a theory about what's going on.

Quade wrote:The file you sent me last time didn't have any samples in it. As far as I could tell. It was just a bunch of obscured files.

Anyway, appreciate the NZB when you send it.

Sent.

Got it. Thanks.

All the ones that are samples only come from the same indexer, but 6.82 works fine with it

If you wouldn't mind, could you PM me the name of the indexer?

Honestly there's nothing wrong with these NZB's and they don't contain any samples so, what I think is happening is the indexer is either sending down a combined NZB and Newsbin is splitting the samples out into two distinct NZB's or that Sonarr is sending 2 distinct NZB's down. I actually believe it's the former.

So basically two sets of files are coming down from the indexer in a single NZB. 6.90 is assuming a single set per NZB. Which is the most common. The reason 6.82 isn't impacted is it makes no effort to group these obscured files before download. The grouping is what leading to the smaller set finishing and pulling the larger set out. The files are obscured so there's no easy way to remove the samples before the download starts.

The change I made to remove samples, assumes you can ID the samples from the subject, which you can't when everything is obscured.

1 - A quick fix would be to remove forced compaction from Sonarr downloads.

2 - The longer term fix might be to change how download works so Newsbin downloads the first chunk of every file and find the filenames, either from the subject or PARS, then cleans the grouping using the resulting filenames. Before the full power download starts.

I'm leaning toward #1 for now. The whole point of grouping is to minimize PAR downloads and minimize repairs.

kirm wrote:

Apologies, but I'm confused. I just checked, and with both RC2 and RC3 one still can't successfully post to a group unless there is an attachment (reported with RC1). Given this, is the problem unique to me and/or not duplicatable? Just checking that I've not missed a discussion or decision on the topic....

By any chance, are you using Newshosting. Have not run rc3 yet, installing now. This posting to group has not worked for me as well for some time. Posting is enabled on their web site. It's one of those features I rarely use, so not positive when this started to fail.

Regards,

===

Hi - and no, I've not tested with Newshosting. Pls. check the RC1 comments/thread on posting for more on the topic. From what folks have written I'd speculate that Newshosting is having a unique issue.

Regards.

ccarlin wrote:

kirm wrote:

Apologies, but I'm confused. I just checked, and with both RC2 and RC3 one still can't successfully post to a group unless there is an attachment (reported with RC1). Given this, is the problem unique to me and/or not duplicatable? Just checking that I've not missed a discussion or decision on the topic....

By any chance, are you using Newshosting. Have not run rc3 yet, installing now. This posting to group has not worked for me as well for some time. Posting is enabled on their web site. It's one of those features I rarely use, so not positive when this started to fail.

Regards,

===

Hi - and no, I've not tested with Newshosting. Pls. check the RC1 comments/thread on posting for more on the topic. From what folks have written I'd speculate that Newshosting is having a unique issue.

Regards.

Quade says he is still aware of posting issues. It's NOT newshosting as I have access to several newsservers all with posting ability. My solution always works, go back to 6.82, you will find u can post to any group anyway u want on any newsserver with posting abilities. I did with either rc1 or rc2 try adding attachment and that did not work for me as some others said. Newsbin at least then does show it's trying to post but it never goes. Without adding the attachment Newsbin does not even show it attempts to post. I also have other ways to post to usenet and I think with the other issues the rc's have it's most like low priority.

I’ve noticed that in the last few builds NB will hang if it finds a file that it ''doesn’t like'' – I’ve assumed this is because it is old & close to retention limit / partial deletion etc.

However, whilst this is a factor, NBP will hang until exited/restarted even when there are newer & fully available files in the queue.
I can move newer nzbs or files from headers to the top of a stalled queue & they will only start leeching after a restart.
But I’ve also found that sometimes they will not start even with multiple restarts & cleaning the chunks before starting NBP.

Is there anything I can do about this other than wiping the queue & reloading ? (Which does work most of the time once I remove the problem posts) Or is this something you are aware of in these betas & will be fixed?

I've not seen that happen. I'll have to try to reproduce it.

If you turn on "Show server Commands" in the network options, what errors do you see when this happens?

Are you using multiple servers? I wonder if both actually work? Your symptoms could be caused by a dead server. One that's active but Newsbin can't connect to.

Quade wrote:I've not seen that happen. I'll have to try to reproduce it.

If you turn on "Show server Commands" in the network options, what errors do you see when this happens?

Are you using multiple servers? I wonder if both actually work? Your symptoms could be caused by a dead server. One that's active but Newsbin can't connect to.

Thanks for the reply Quade.
I am seeing the expected 430 no such article comments in logging. I have turned on the "Show server Commands" & will report what appears.

I have several providers with long retention & use multiple locations & ports on each.
I can see the server totals for each connection block & they appear to be leeching & increasing their tally in the 'downloaded' column.
IPv6 is failing tho.
Could the IPv6 be an issue as whilst I can see these have been used successfully in the past they are currently showing 'Failed to Connect'?

Could the IPv6 be an issue as whilst I can see these have been used successfully in the past they are currently showing 'Failed to Connect'?

How about disabling this server and see if it still stalls when you 430?

Quade wrote:

Could the IPv6 be an issue as whilst I can see these have been used successfully in the past they are currently showing 'Failed to Connect'?

How about disabling this server and see if it still stalls when you 430?

Doh! Should've done that at the time I saw it!!
Now to find some dubious files to test
Update
Nope still hangs...

& BTW I'm back to the login dance:
You exceeded the maximum allowed number of login attempts. In addition to your username and password you now also have to solve the CAPTCHA below.
You need to login in order to quote posts
You exceeded the maximum allowed number of login attempts. In addition to your username and password you now also have to solve the CAPTCHA below.

When I log in, I click "they logged in" and never have to log in a second time.

I might disable all the servers. Restart. Enable one, try to download a bad set, enable a second server. See if there's any specific server that triggers the hang.

Quade wrote:When I log in, I click "they logged in" and never have to log in a second time.

I might disable all the servers. Restart. Enable one, try to download a bad set, enable a second server. See if there's any specific server that triggers the hang.

Thanks Quade. I will try selective enabling/disabling.
& OT again...
This is how it's gone today - I never see "they logged in":-

Login [http://forums.newsbin.com/ucp.php?mode=login]
You exceeded the maximum allowed number of login attempts. In addition to your username and password you now also have to solve the CAPTCHA below.
You have been successfully logged in
>> return to topic hit 'quote' - >
You need to login in order to reply to topics within this forum.
>
You need to login in order to quote posts within this forum.
You exceeded the maximum allowed number of login attempts. In addition to your username and password you now also have to solve the CAPTCHA below.
You have been successfully logged in
>> return to topic hit 'quote' - >
You need to login in order to reply to topics within this forum.
>
You need to login in order to quote posts within this forum.
You exceeded the maximum allowed number of login attempts. In addition to your username and password you now also have to solve the CAPTCHA below.
You have been successfully logged in
>> return to topic hit 'quote' - >
You need to login in order to reply to topics within this forum.
>
You need to login in order to quote posts within this forum.
You exceeded the maximum allowed number of login attempts. In addition to your username and password you now also have to solve the CAPTCHA below.
You have been successfully logged in
>> return to topic hit 'quote' - >
>> Reply dialog with quote - enter reply
>> Hit Submit
>
You need to login in order to quote posts within this forum.
You exceeded the maximum allowed number of login attempts. In addition to your username and password you now also have to solve the CAPTCHA below.
You have been successfully logged in
>> Reply dialog with quote - previous txt lost.
> start over...
>
You need to login in order to quote posts within this forum.
You exceeded the maximum allowed number of login attempts. In addition to your username and password you now also have to solve the CAPTCHA below.
You have been successfully logged in
>> Reply dialog with quote - previous txt lost.
> start over...

>>>>& see I need to edit...

In order to edit posts in this forum you have to be registered and logged in.You exceeded the maximum allowed number of login attempts. In addition to your username and password you now also have to solve the CAPTCHA below.You have been successfully logged in
>> Edit dialog
>> Hit Submit
>
In order to edit posts in this forum you have to be registered and logged in.You exceeded the maximum allowed number of login attempts. In addition to your username and password you now also have to solve the CAPTCHA below.You have been successfully logged in
>> Edit dialog - previous txt lost
>> Hit Submit
>
In order to edit posts in this forum you have to be registered and logged in.You exceeded the maximum allowed number of login attempts. In addition to your username and password you now also have to solve the CAPTCHA below.You have been successfully logged in
>> Edit dialog - previous txt lost
>> Hit Submit

Sorry I mean "Stay Logged In". I see that as a checkbox in the login screen. Beyond that I don't know. I believe Dex thinks it's some security issue.

Quade wrote:Sorry I mean "Stay Logged In". I see that as a checkbox in the login screen. Beyond that I don't know. I believe Dex thinks it's some security issue.

Odd that it isn't consistent. Doesn't happen all the time.
Log me on automatically each visit ineffective
3x today

Is anyone having Internet search issues on this build?
It doesn't seem to clear the search results and just adds new search results to the previous ones. Closing Newsbin doesn't clear them either, they seem to be cached somewhere.

One positive is the progress bar seems to be showing which server which part is coming from, I seem to recall that never worked properly in WINE before (so possibly a fix in WINE rather than Newsbin).

I had my autopar set to pause pars and d/l only those needed. I unchecked that because it seemed the hidden archives from the next file were running into each other creating "copy of..." causing problems for the subsequent unrar.

This group is a.b.moovee so the unrars are hidden, all with the same name "archive.rxx. Again, for me the simple solution is d/l all pars, then unrar.

If there's a better solution let me know, but it's not a big deal. I just thought I would bring it to your attention.

It doesn't seem to clear the search results and just adds new search results to the previous ones. Closing Newsbin doesn't clear them either, they seem to be cached somewhere.

Go into the data folder "spool_v6" and delete "BASIC_SEARCH" then see what happens. This folder contains the historical record of the last search.

This group is a.b.moovee so the unrars are hidden, all with the same name "archive.rxx. Again, for me the simple solution is d/l all pars, then unrar.

Are you downloading using headers or NZB Files? Downloading each set to a unique folder would solve this. If it's NZB's I'd suggest using the $(NZBFILE) in the download path. If it's headers, maybe $(SUBJECT) in the download path. Dumping sets with identical names into a common folder will always be problematic.

for moovee I'm d/ling headers (there are no NZBs) I can see where separate folders would work. thanks

Quade wrote:

It doesn't seem to clear the search results and just adds new search results to the previous ones. Closing Newsbin doesn't clear them either, they seem to be cached somewhere.

Go into the data folder "spool_v6" and delete "BASIC_SEARCH" then see what happens. This folder contains the historical record of the last search.

Tried that and while it wiped the results, its still adding each new search to the results from the prior one.

Tried running from the command line and WINE isn't saying anything out of the ordinary, neither is there anything about IO in the Newsbin logging.

The only IO message is 0024:fixme:ntdll:NtLockFile I/O completion on lock not implemented yet which I think has always been a WINE thing.

The only other messages are:
0024:fixme:msg:ChangeWindowMessageFilterEx 0x1009a c097 1 0x212808
0024:fixme:msg:ChangeWindowMessageFilterEx 0x1009a 111 1 0x212808
0024:err:header:HEADER_WindowProc unknown msg 2008 wp=0000 lp=00000000
0024:err:header:HEADER_WindowProc unknown msg 2007 wp=0006 lp=00000000
0024:fixme:richedit:ME_HandleMessage EM_SETMARGINS: stub

I'll try it in wine and see what the results are. What version of wine are you using?

I test the installer under Wine since it's so easy to wipe the windows folders.

Quade wrote:I'll try it in wine and see what the results are. What version of wine are you using?

I test the installer under Wine since it's so easy to wipe the windows folders.

Well that's interesting, seems I was on Wine Staging 5.8 yet Fedora are up to 6.16 now. I remember switching to WineHQ because of some issues at the time breaking Newsbin, time to switch back I guess.

Sorry for wasting your time, it seems moving to 6.16 fixed the problem and Newsbin seems MUCH faster to boot.

When downloading binaries, the progress bars are a bit wonky and not as smooth as they used to be. While downloading, the progress bar gets to about 75% and then suddenly jumps to extracting, and the extraction progress bar is already at about 50% and then it's done.

I've noticed this in both RC2 and RC3. Newsbin works just fine, this is purely a cosmetic issue.

I have a feeling the progress bar thing is because I'm counting the PAR files too but, they typically don't download. So you see progress which includes the PARS that never actually download.

I'll have to think about how to address it. Thanks.

Quade wrote:I have a feeling the progress bar thing is because I'm counting the PAR files too but, they typically don't download. So you see progress which includes the PARS that never actually download.

I'll have to think about how to address it. Thanks.

Maybe make the PARs a different colour so at least visually we can see it?

My goal is to show how much of the file sets download from each server. So if you have 2 equal servers you'll see the bar grow with 2 colors, 1 per server. If you have a primary server and a secondary, you should primarily see the main server color.

The problem with the PARS is that it's not always clear they are PAR files. With obscured downloads, you might not know what kind of file it is till the download commences.

Hi Quade,
Something I've noticed, not sure if it is relevant here, but...

When a file is downloading and there are not enough PARs (or they are damaged), the file fails and ends up on the Failed List - as it should.
But, on the one I've just seen, there is no reason supplied for the failure and the download status says "[1 Files, 7 Pars] D:0 DL:0".

I had to hunt around in the debug messages to find the reason for failure:
[10/08 22:58:40] DEBUG CNNTPRepairFailedNeedPARSException - Repair Failed Needs more pars:

On looking in the DL folder, and running Quickpar manually, all the files were downloaded, including the PARs,
but they were damaged and 6 additional PAR blocks were needed but not available.

File DL was via NZB into the watch folder.

regards
Stavros.

Hi Quade,

Some strange behaviour when loading an NZB via the watch folder.

I put several NZBs in the NZB watch folder and they were imported by newsbin and started downloading.

I noticed that one NZB was setup in such a way that the PARs were split out into separate download entries and that newsbin started to download them,
(*edit* - example sent) even though the main file was OK and being extracted.

So I deleted the downloading PARs and, by mistake, also the remaining NZB entries that had not yet started to download.

No problem - I just added them back into the NZB watch folder and waited for them to start downloading, and waited, and waited....

They were not imported by newsbin and just sat there in the NZB watch folder...
It has been over 10 minutes now and still nothing.

Is this expected behaviour? and how do I over-ride this?

regards
Stavros

Is this expected behaviour? and how do I over-ride this?

Yes. Newsbin won't re-import the same NZB file within that session. It's not just the NZB files. It won't look into RAR files it's already looked into. I had to implement this filter because some people use their download or unrar folders as the autoload folder. Newsbin rescanning all the files for NZB's caused performance isues.

You could restart Newsbin to make it forget you loaded those NZB's or tweak the filenames. A rename is enough to re-import.

I just fixed an NZB formatting problem because one of the NZB sites changed how they name PAR files. It was "...vol-XX.par2" instead of the standard PAR file naming. Someone suggested the change was so the NZB sites could figure out who was scrapping NZB's off the site.

RC4 has the fix. It's in testing right now.

Thanks Quade. I'll try restarting next time

Something else I noticed while investigating this NZB feature was that the NZB files looked like they are stored in the "Main Download folder"
from "Basic Settings" while they are being downloaded, in my case F:\DL\$(GROUP)\
rather than the "Download folder for downloads from NZB Files", in my case F:\DL\_NZBs\$(NZBFILE)\,
before ending up in my "UnRAR Folder": F:\DC\$(NZBFILE)\$(GOG)\$(GROUP)\

Not a major problem, but could easily lead to confusion if downloads fail to complete the entire process and/or newsbin crashes.
This would be even worse if more than one download of a similar NZB set fails, leaving multiple sets of partially downloaded/extracted files in the same "Main Download folder".
Also, what about filename clashes with files already in the "Main Download folder", especially common files like info.txt, read.me etc?

Should any NZB related download files be using the "Download folder for downloads from NZB Files" entry from "Basic Settings"?

regards
Stavros

NZB's fed to the post list didn't seem to use the NZB download path. They do now.

If you're concerned about collisions, you can add $(NZBFILE) to the main download folder. It's simply ignored if there are no NZB's.

Thanks Quade, adding the $(NZBFILE) to the main download folder did the trick

This version seems to auto download any NZB i drag and drop on it, even if "automatic download for loaded NZBs" is unchecked.
Could this be fixed?

OMG2k11

Could this be fixed?

That's how it works now. Modern NZB's work best if they go directly to the download list. Dex and I are talking about whether I should remove the option or change it to default to direct to download list but allow you to override.

Quade wrote:

Could this be fixed?

That's how it works now. Modern NZB's work best if they go directly to the download list. Dex and I are talking about whether I should remove the option or change it to default to direct to download list but allow you to override.

Please leave it! There are tines when all you need to do is redownload one rar. It would be very inconvenient if I have to download the entire nzb especially if it's very large

Please leave it! There are tines when all you need to do is redownload one rar. It would be very inconvenient if I have to download the entire nzb especially if it's very large

You can always "load" the NZB from the file menu if you need to just download one rar. This always sends them to a post list.

I've discovered a minor issue with Newsbin Beta 6.90RC3 - build 5462.

Changing the download paths for files displayed in the "Downloading Files" tab results in the affected files then being downloaded to the new download path, but such changes are not then displayed in "Download Path" column of the "Downloading Files" tab.

The "download path" column is showing the decode path now. The path the files will unrar to. It's on my list to change the column name.

Maybe if I notice you change it, and the download and decode paths are the same, I should change the decode path at the same time? Typically, I consider the download path to be not particularly important. Not as important as the decode path.

Thanks.

Lately when I download an NZB by clicking on it to open in Newsbin, it downloads successfully but auto-downloads all the par files whether it needs them or not. Is there a setting I have misconfigured? It deletes all the downloaded pieces after assembly but leaves all the par files.

Might already be fixed in RC-4. One of the NZB sites has recently changed to non-standard PAR naming format. So, RC3 doesn't combine them.

I noticed that when I have nzb's in the download tab that these split into several lines, 1x the mkv and several lines for the pars. Is it possible to hide these extra lines with just the par info ?
When I have several nzb's in the download tab then when I change the order (select + ctrl-up, or ctrl-home) that the pars remain in the download list even after the mkv is completely downloaded.

When I download a mkv and I see several par2 lines below it, then even during the time the green unrar progress bar shows, the downloading of these remaining par2 files will still continue.
I think nzbgeek uses this new nzb file format that I have read about.

I really like the colouring of the download progress showing my 4 usenet servers It looks nice and shows me clearly which provider is fastest and which providers do not have the file anymore

My answer is the same for the other poster. I believe RC-4 fixes the current par grouping problem because 'geek changed to a non-standard PAR format.

It's on IRC. Assuming nothing comes up. I'll probably post it here tomorrow.

Indeed now that you mention it, all these par parts were staying behind and weren't deleted.
Thanks for the heads up. I will try RC4 when it becomes available.