newsbin.com

Fixed a crash problem and added a new feature

Summary:

• New Message ID Filter has been implemented. Instructions for setting it is here
• Fixed crash issue when checking properites from a post list.
• Fixed issue renaming watch list items.
• Fixed issue where running out of searches on an Internet Search would clear the list.

Many more details and the download link for Beta 16 is on the Newsbin Beta Page.

Reply to this thread or contact us through the Newsbin Support Form for bug reports or issues with this release.

NOTICE: B16 was temporarily pulled this morning to fix a couple of bugs that got through. As of 10:30pm EST, it is back up, still B16, but the build number is now 3030. If you are running 6.50 Beta 16, make sure it is Build 3030

Using 650b16, I did a "Test Download Files" on some posts (from headers, not nzb) and I'm getting a lot of the following errors, I've never seen this error before:

[19:55:37] ERROR DG - Connection Failed: AstrEuSSL Index:5 X-Trace: DXC=OJ4Maj]NgHl92gaK\0;3cnL?0kYOcDh@j<mEa9SiZCMeRd3Bgg=O`PeVDlMZ9=:3jckgniFnhd1gen?[ik1hCkZgI^gfT:3QNdnK_YN?m^Z;:j

I'm getting them on all the Astra servers US and EU, SSL and non-SSL. I suspect the articles don't exists, since propagation to Astra has been terrible lately, but I just want to verify what the error is. The post is about 1 hour old, doubt very much it has been DMCA'd.

I'm seeing it too. Astraweb might be having some temporary issue.

I switched to another server and it took off running.

EDIT: It's possibly a B16 issue with the Test Files function. I can't get it to fail with B15. You might want to go back to B15 and see if you get the same results. Quade will look into it as soon as he gets a chance.

I found a problem in "Testing" files in B16. It's fixed now. Might try to get dex to put up a b17 pretty quickly.

I asked Dex to pull the beta while I investigate an issue with header downloads. I'll either be back up or B17 will be back up.

I'm not sure there's a problem but, I saw what looked like missing headers this morning and I was able to get the missing ones by "Use Download Age" and re-downloading the past 10 days worth.

The Watch Topics "From Poster" does not automatically display results. I see a count under the new files, but entering the topic yields no results.

This is consistent with all topics of "from Poster". A click on the magnifying glass (search) yields results. Many of the results are current, so I know it's not a timing issue.

I just keep using the search function for now.

This was true with B15, too.

So, they're there but, they just don't display when you initially load?

If beta 16 isn't available it might be a good idea to rename the thread, no?

Just for the record I had it, installed it, encountered issues (slower, wasn't connecting to Astraweb for some reason on port 443 but 563 was fine - and SABnzbd was connecting just fine on 443 at the same time), etc, so I scrapped it and went back to beta 15. Actually about to do yet another clean install but this one is for a good reason: got a new laptop... and not the same old reason of just having something crap out my install forcing a clean one.

Beta 6 was taken down once but when a major bug was discovered the took it down quickly to patch the major bug and reupload B16 as a working copy. Its back up on the main pages if you didn't know.

Yah, I see that now, just got put back up while I was offline, no worries. I'm guessing whatever glitch it had was addressed, but if that's the case and there was a fix, why not push the build number to beta 17 ?

Just curious...

Yah, I see that now, just got put back up while I was offline, no worries. I'm guessing whatever glitch it had was addressed, but if that's the case and there was a fix, why not push the build number to beta 17 ?

Because we're lazy and not many people had downloaded it yet.

Quade wrote:So, they're there but, they just don't display when you initially load?

Yes, they must be because a search displays them.

All my from poster/field Watch Topics work that way.

So, they're there but, they just don't display when you initially load?

And your answer tells me where to look.

I just did a double click on "Watch Topics" (for all lists) and ALL, including the from poster/file, are listed.

I think it's a function of the from filter.

Quade wrote:

Yah, I see that now, just got put back up while I was offline, no worries. I'm guessing whatever glitch it had was addressed, but if that's the case and there was a fix, why not push the build number to beta 17 ?

Because we're lazy and not many people had downloaded it yet.

You? Lazy? Pffttt... you've been working on this program (almost called it an "app" there but caught myself) for what, 15+ years now, and it gets better with each new version (give or take a little backsliding for bugs sometimes but that's normal). Your efforts (and the support staff and Dexter as well) have always been appreciated.

So far so good...

Something a bit strange happened after updating to beta 16 (3030)

I have now two watch topics, one is called "Watch_Topics" and seems to be the "real" watch topic (but is now empty)
The other one is called "Watch Topics" and contains all my former "from" filters but seems to behave like a regular "folder" (gog). If I click on one of the lines it contains, I have the options I would have in a regular group, not the ones of a "watch topic" line
(I hope it makes sense, sorry, English isn't my native language )

Not a big deal but I thought you might want to know

Editing the Newsbin.nbi file and replacing the "Parent=Watch Topics" line for each former "from" filter with "Parent=Watch_Topics" seems to have solved the problem for me and moved all my "from" filter back to the real "Watch_Topic" group

This was mentioned in the release notes. The Watch topics got kind of messed up with the transition to B16. You could try this.

Glad you were able to fix it.

Hello,

I just updated from 6.41 to 6.50B16 build 3030

I am experiencing a major issue with loading headers. Some groups will not display and even when one does it takes a very long time. I only really upgraded to take advantage of the larger limit "Failed Files" list (a feature I had requested, thank you!) and hadn't been having any issues with the older version.

There doesn't appear to be any rhyme or reason to it...sometimes the headers will display, other times they won't. It even appears to be "processing" the headers if I try to load a few days in a group I know had no headers during that time, ie. the name tab for the group opens but comes up with no post count (other groups like that will sometimes at least show the correct "0" post count in that name tab)

Oh, and my CPU usage is insignificant when it is having the issue

Look at the "Cache" section of the Status Bar at the bottom of the Newsbin window. It should look something like "Cache: 90/100 (0)". If there are numbers in the parenthesis, then hold off loading groups until that number counts down to 0. It represents headers being processed in the background. That may be your issue.

Upgrading from B14 to B16 cleared my Files List, even though it isn't a big deal

Yeah, files are stored in a different database table no so, the old list was no longer compatible.

Look at the "Cache" section of the Status Bar at the bottom of the Newsbin window. It should look something like "Cache: 90/100 (0)". If there are numbers in the parenthesis, then hold off loading groups until that number counts down to 0. It represents headers being processed in the background. That may be your issue.




Well, I'll keep that in mind. I actually ended up just installing 6.42 and everything is working normally again.

A few questions tough. I noticed my "Failed Files" list reset when I updated. I had my data files backed up though, but what actual file name is that list? Also, in 6.50 is there a way to get back the old visual look of the gray with white lines display? That made things much easier to read. I couldn't find where to change that.

"Cache: 90/100 (0)". If there are numbers in the parenthesis, then hold off loading groups until that number counts down to 0.

This is sort of misleading. Hold off "Downloading more headers" for this group. If you load the group. 6.50B16 actually prioritizes the import so, the currently visible tab loads the headers faster than any other tab. It's faster and fairer than 6.42 so, I'm surprised switching back would be better. That suggests something else is going on.

"Failed Files" are in the downloads.db3. "Files" are in the downloaded.db3.

Quade wrote:

"Cache: 90/100 (0)". If there are numbers in the parenthesis, then hold off loading groups until that number counts down to 0.

This is sort of misleading. Hold off "Downloading more headers" for this group. If you load the group. 6.50B16 actually prioritizes the import so, the currently visible tab loads the headers faster than any other tab. It's faster and fairer than 6.42 so, I'm surprised switching back would be better. That suggests something else is going on.

"Failed Files" are in the downloads.db3. "Files" are in the downloaded.db3.

Well, I copied over my very recent backups of downloads.db3, downloads.db3-shm, and downloads.db3-wal which did bring back my list of "Failed files" however doing that messed up my displaying list of subscribed groups from showing 289 groups to 70. Not sure why that happened as my "groups.db3" in my Data folder didn't change. I know I can manually add (subscribe) to each group that is missing and they will load since the data is still in the Spool folder, but is there an easier fix to load the "groups.db3"?

Actually, I see now..."groups.db" is the complete group list available from the servers, right? Is there a file that holds subscribed groups?

***Well, I assume I clicked on a very old copy of an .nbi file which launched the program. I see now that Subscribed groups are simply stored in the .nbi config file. I guess I lost track of what folder I was in

Oh, and installing the current beta I still have the issue loading some groups. Tab shows "Cache: 200/200 (0)".

Also, sorry but for some reason quoting messages doesn't seem to be working correctly for me.

Oh, and installing the current beta I still have the issue loading some groups. Tab shows "Cache: 200/200 (0)".

This means it's essentially idle and nothing is importing. I'd pick one of these groups, right click "Post Storage/Use Download Age" set some reasonable download age and re-download that number of days of headers with a "Download latest". Then see what happens. If your storage age is short, Newsbin might be throwing away records before you can see them.

Honestly you have too much going on at once to know if your problems are real or self induced. Using an old NBI, maybe using old data folder. There's really no telling what state you install is in right now. You shouldn't have had to mess with any of these files to install the new beta or re-install the older full release.

Quade wrote:

Oh, and installing the current beta I still have the issue loading some groups. Tab shows "Cache: 200/200 (0)".

This means it's essentially idle and nothing is importing. I'd pick one of these groups, right click "Post Storage/Use Download Age" set some reasonable download age and re-download that number of days of headers with a "Download latest". Then see what happens. If your storage age is short, Newsbin might be throwing away records before you can see them.

Honestly you have too much going on at once to know if your problems are real or self induced. Using an old NBI, maybe using old data folder. There's really no telling what state you install is in right now. You shouldn't have had to mess with any of these files to install the new beta or re-install the older full release.

I'm sorry for posting questions before really sitting down and trying more things to answer them on my own. I actually found Newsbin had been placing a copy of my .nbi file in "C\Users..." besides where I had moved my Data folder to. Even with all my fiddling that .nbi had last been updated and overwritten an hour previous unlike the other. I now have everything back the way it was on 6.42

Anyways, getting back on topic, even with a clean install and everything acting like it should, 6.50B16 is still having issues with loading and/or sorting headers. Performing the exact same tasks (loading the same group and sorting the messages) I have noticed that 6.5B16 is using over a 1GB more of memory than 6.42 during the task. Sorting by "Status" seems to be the issue on large groups in 6.50. It is understandable that it takes more time than by something like "subject" but in 6.42 even large groups sort by "status" quickly.

I believe the group header loading issue was occurring as some groups I was trying to open were trying to open with the messages sorted by "status" (loading and sorting at once) Also, closing a group tab isn't freeing up memory and the process of trying to sort seems to be continuing which prevents loading of other groups. I have to close the program and restart.

Sorry if it is confusing, but anybody else have issues sorting large groups by "Status?"

*Update, ok I see this was an issue already viewtopic.php?f=44&t=32391&p=195763&hilit=status#p195760

Sorting by "Status" seems to be the issue on large groups in 6.50. It is understandable that it takes more time than by something like "subject" but in 6.42 even large groups sort by "status" quickly.

Status sorting is exceptionally slow. It used to be fast but, not particularly accurate but, people complained. Now it's slow but, 100% accurate. The problem is some of the status is dynamically generated so, it's slow by its nature. I believe 6.42 has the slow but, no correct sorting.

I believe the group header loading issue was occurring as some groups I was trying to open were trying to open with the messages sorted by "status" (loading and sorting at once) Also, closing a group tab isn't freeing up memory and the process of trying to sort seems to be continuing which prevents loading of other groups. I have to close the program and restart.

This is very good point that I didn't factor in. I should really prevent persistent sort on status. Maybe if it's sorted on status on load, I need to switch it to date.

Hi,

It looks like the 'Header Database Compaction' doesn't work anymore my spool dir is now over 2 Gb and still growing.

A test with the vacuum option from SQLite3 management studio compacted a storage.db from 70 Mb to 47 Mb



Regards

Jan

That's pretty small. I think mine's 60 GB. I noticed the first time I compacted, the file size got bigger, I think the DB is relaying itself out the first time and then subsequent runs, it doesn't expand anymore. The database version has changed multiple times not only that, the page size of the database between old and new versions changes.

Before it vacuums, it does at "analyse" which adds some indexes it they're needed to improve performance.

Still, I'll investigate. I always pick performance over size simply because disk space is so cheap.

Edit: Actually it's 180 GB.

Thnx for the explanation but i mentioned it because i think before B13 or B14 my Spool_v6 dir size always was around 700-800 Mb


Jan

Quade wrote:That's pretty small. I think mine's 60 GB. I noticed the first time I compacted, the file size got bigger, I think the DB is relaying itself out the first time and then subsequent runs, it doesn't expand anymore. The database version has changed multiple times not only that, the page size of the database between old and new versions changes.

Before it vacuums, it does at "analyse" which adds some indexes it they're needed to improve performance.

Still, I'll investigate. I always pick performance over size simply because disk space is so cheap.

Edit: Actually it's 180 GB.

Thnx for the explanation but i mentioned it because i think before B13 or B14 my Spool_v6 dir size always was around 700-800 Mb

Just had to check mine and I'm sitting at 318Meg. I am using B16 but I only have about 15 groups, with retention set at 7 days. Just curious though, looking in my Spool_v6 dir, there is now a directory called "Basic", with one file "Storage.db3". When did this file come to be? It appears to be current date and time wise.

Forgot that I just dl through search, is that where the Basic folder got created?

The redesign to make persistent search work in the watch lists (you can search in a watch and then later re-load the results without searching again) requires that I save the results to a DB3. In the case of regular search, it saves them to basic. Regular search overwrites basic each time so, it'll never grow.

Quade a couple of thoughts for the sort on status. I like the fact you can now do it and it works, and on my machine it is very quick even with hundreds of thousands of headers.

The reason I tend to use status, is so I can delete those that have been downloaded, which I assume may be the same reason many do this

Maybe only allow sort on status when downloads paused ?
or
Give us a right click option to delete all downloaded, which means it wouldn't need to sort. Assuming everyone is using it for the purpose I do

I think I upgraded from a few betas ago so I don't know when this changed. It's only a small thing but I'm not keen on having just one colour for the download progress of individual files. Whereas if you have a nzb containing a bunch of rars download progress shows, by colour, which pieces are being downloaded by which server.

If I have say a couple of hundred files I'm downloading from a group's headers I quite like knowing which server is doing the job. Any chance of a reverse back?

IdontexistM8 wrote:I think I upgraded from a few betas ago so I don't know when this changed. It's only a small thing but I'm not keen on having just one colour for the download progress of individual files. Whereas if you have a nzb containing a bunch of rars download progress shows, by colour, which pieces are being downloaded by which server.

If I have say a couple of hundred files I'm downloading from a group's headers I quite like knowing which server is doing the job. Any chance of a reverse back?

I do not think there has been a change here recently. The single colour is used when the number of chunks in a file exceeds a threshold (I think something like 200).

itimpi wrote:

IdontexistM8 wrote:I think I upgraded from a few betas ago so I don't know when this changed. It's only a small thing but I'm not keen on having just one colour for the download progress of individual files. Whereas if you have a nzb containing a bunch of rars download progress shows, by colour, which pieces are being downloaded by which server.

If I have say a couple of hundred files I'm downloading from a group's headers I quite like knowing which server is doing the job. Any chance of a reverse back?

I do not think there has been a change here recently. The single colour is used when the number of chunks in a file exceeds a threshold (I think something like 200).

Ok, I'll double check.

Testing by DL'ing a single rar from a rar set, it shows only a single color in the 'Current Progress', DL'ing the entire rar set, it will show the colors of the individual servers for the same file. Same file, just added to the download list differently. I agree with the request it show the colors of the servers independent of how it is added to the DL list.

Sounds like it's just broken but, it does depend on how many chunks there are. At some point it's too expensive to paint 400 lines for 400 chunks. 400 lines you can't see anyway.

Just checked, downloaded about 30 items between approx 20 and 60MB, nothing over 100 parts, all had the same single 'download' colour.

NB - the colour used isn't one of my servers.

Are these single files, or collapsed entries (with a + at the start)? I think collapsed entries always show single colour.

Single. The collapsed do show.

IdontexistM8 wrote:Single. The collapsed do show.

Strange. I DO get coloured segments for single files with the latest beta.

itimpi wrote:

IdontexistM8 wrote:Single. The collapsed do show.

Strange. I DO get coloured segments for single files with the latest beta.

Just to avoid confusion on my part.

Single = same one colour
Collapsed = same one colour
Expanded = individual server colours.

Installed latest Beta 16 build and it blew away my .nbi in the "program files" directory. Newsbin starts up with all group settings and history gone. Pretty frustrating...

optiman wrote:Installed latest Beta 16 build and it blew away my .nbi in the "program files" directory. Newsbin starts up with all group settings and history gone. Pretty frustrating...

That's a strange place to keep a .nbi file - one normally does not want programs to have write access to the Program Files area. I keep my .nbi file in the Newsbin DATA folder.

Having said that have you tried using the Options menu->Load a Backup Configuration on Restart? I would have thought that would get back your previous configuration.

The NBI shouldn't have never been in program files in the first place. In the options, you can select "Load Backup Config on Restart" then restart. You should be presented with a list of old NBI's.

My answer is "don't do that". It's ALWAYS a mistake to save any data files to "Program Files" so, I recommend saving the NBI someplace else. Maybe in your documents folder.

Didn't know newsbin stored backups! Very cool. Restored. No idea how the .nbi was placed in the program files; I'll try to store it elsewhere.

I just upgraded to B16 and I'm getting a bunch of

Code: Select all

[hh:mm:ss]  DEBUG DbWorker: Db Gz to Db  Failed: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-#######-#######.gz

errors. What's the reason for this? Is it important? Anything I should/could do about it?
OMG

Cosmetic bug in B16 Build 3030: If I leave a multi-part download expanded, after autopar unrar's and deletes the successful download, it leaves a blank line behind in the download list with a red exclamation icon. I can manually delete the line, but it threw me off the first few times it happened. If the download is collapsed, there is no strange behavior after successful download.

[Newsbin Pro 6.50B16 build 3030 (x64) on Win 7 Pro x64]