BUG : 6.50b18 NOT showing DOWNLOADED files status from 6.42

[driverdude]

Help!

I used 6.42 (00 64 88 37 3B DC) and prior to joyfully archive tens of terabytes of small test files across many groups during the past year. And relied on "old post" and "archived post" to aid in keeping track of what i saved.

BUT THERE IS A NEW HORRIBLE SAD BUG, I THINK. Downloads.db3 ignored in 6.5? (or is archived status in spools?)

Any way to help me fix this so I don't have to revert Newsbin ? I have EVERYTHING saved so i can go back to v6.42 until fixed, if needed.

I have nearly every feature disabled in this product, i use it merely to download and mark files with NTFS ADS file info, and use my own par tools, my own sfv tools, my own rar tools, my own sort tools etc.

I use it to download, but now the new 6.5 i installed for the first time, seems to not display icon or color for "archived posts" and only show "archived posts" in the list of files of a header group of files i download a second time today, as a test, such as files from mid 2008 (eweka and giga and atraweb all show headers and provide files from 2008 , even in 2013.10, though your product makes 2008 semi difficult time period to select. It also shows NEW archive status from files in 2013.

But all the countless files I must have in my gigantic Downloads.db3 is being ignored.

Its probably acting like "headers flushed" maybe? It should not be though because the headers are all there, just the post status is not honored.

It is showing old posts in a SMALLER group, so maybe post range is somehow honored, but not post header strings, which are more useful for detecting crossposted files to more than one usenet group.

I use three services for usenet , and like the new way to sort priorities other than alphabet and add tricks and limiting open connections tricks to prioritize.

I like and WANT to to download duplicates, if desired (better file group sets for example), but i just need to be informed visually in selection list if I have it already or not. Just as it did before. I dont want AUTO-duplicate avoidance turned on by default, if that has anything to do with it.

I use AgeLimit=2000000000 in the .ini for the three servers
and basically have 5000 days set (RecordPurgeAge=5000)
and (DisplayAge=5000)

I did nothing other than launch the new tool twice and open up a group and see if it was honoring "archived posts" and '''old posts".

I HOPE ITS A SIMPLE THING, but i fear the worst.

These are my newsbin settings :

[Settings]
AutoAssembleTimer=100000
AutoOLD=0
AutoSave=692802112
AutoShutdown=0
AutoShutdownMode=0
BwAutoOff=0
DataPath=D:\__VITAL_NEWSBIN\__WIN7_NEVER_MOVE\Newsbin\
DisplayAge=5000
DownloadPath=F:\incoming\misc 13\
HeaderUpdateWhenStarted=0
HideProgress=1
InitBrowsePath=1
InitDays=60
LoadSpecial=2
LogLevel=1
LowRes=0
MultiTab=1
OldPicker=0
OnShowMotd=1
PathDupBypass=0
PauseAutoOff=0
RateLimit=5462500
RecordPurgeAge=5000
RecycleServers=1
RestartPauseTime=9000
RetryBeforeAssemble=2
SaveFailedList=1
SaveFilesList=1
SavePicker=0
ShowPAR=1
ShutdownWindows=0
SigCache=0
SortIgnoreRE=0
UseBwAutoOff=0
UseBwScreenSaver=0
UsePauseAutoOff=0
UseRateLimit=0


[AutoRAR]
AggressiveAssembly=0
AutoDecode=0
AutoDelete=1
AutoFolder=0
AutoScratch=0
DecodePath
DisableAutoPAR=1
FolderPrefix=0
PathOverride=0
PausePARS=0
RemovePerfect=0
UseFilter=0
UseRecycle=0

I searched the newsbin support forums regarding this issue and saw nothing obvious.

since the product does save new status info properly, maybe it is getting destroyed upon upgrade and initial launch?

Hopefully its a simple thing to fix, or something i need to do in the .ini file.

I do not mind restoring all my files prior to 6.50b18 install of tonight, and testing a special beta build for you if required to track down this bug of not displaying status of posts downloaded in the past, and sending log files back or whatever.

I wonder if its related to new thing i saw in .ini file called "[Counters]"?

ANY IDEAS TO TRY? Please help.

Thanks for fine product, it does many things above and beyond.

[driverdude]

Not to confuse you, but in the above post when i mentioned it showed "old posts" being demarkated i meant that though not showing ARCHIVED, they showed as old coloration, because i have a habit of always as a safety measure also "MARKING ALL OLD" manually before closing a file list after selecting files to add to download list.

[Quade]

1 - Downloads.db3 only stores the download list. It has no download tracking in it.

2 - Signature.db3 is used for duplicate detection but, has no visible indication in the display. You try to download and it'll reject with a signature match.

3 - "Show posts Special" lets you load arbitrary date ranges of the groups.

4 - DownloadMarker.db3 is used to track previously downloaded files whether they come from search, NZB or posts. It only tracks the hash of the subject though. Meaning you can't tell what's been downloaded by looking at this file. Newsbin can just use it to mark something downloaded or not.

For all that you wrote, I'm not really clear what you're reporting. I think you're reporting that when you load a group, it's not showing "Downloaded" status of files you might have downloaded before?

"I used to see files marked downloaded and now with 6.50 they're not marked downloaded. New files I download with 6.50 are marked downloaded..."

Considering that a solid majority of changes in 6.50 are to improve autopar and password support for autopar and automatic watching of the groups to pick out downloads, you may simply not want to upgrade. What I suspect is that download tracking changed in 6.50 and it's not a bug so much as a change.

[driverdude]

DownloadMarker.db3 must be the culprit and i could probably just try various newsbin releases incrementally after the one (6.42) I used for a long while, to narrow down how and when the issue happened.

The hash idea you revealed is a good way to save space and protect other aspects, and is clever.

Something regarding hash might have been altered between the two versions, or the way the servers in a list work.

Glad to see i can select dates using calendar now even further back than prior releases that seemed pegged at 1500 or so, and now lets me select further back via calendar.

I will stick with this new program, mainly because of server prioritization when using 3 or more server accounts, and because I have hand written (yes a stack of paper) notes of all date ranges of all groups I have ever used, because of paranoia of a program letting me down one day, and because of habit. So I am not traumatized over this.

The 3 safeguards I used were : old post coloration, downloaded files custom coloration, and my handwritten date range notes on paper.

I lost the first two mostly in upgrading from 6.4.2 to 6.5.

That to me is a bug. However, it is not the end of the world, because of my paper notes, and at most results in duplicates for the crossover days, or duplicates from posts x-posted to other groups.

Other people might be sadder than I if they lost all history stored in DownloadMarker.db3 (or at least it being not heeded in list, except for newer 6.5+ downloads) Perhaps I am the only one to notice for now, but "download tracking changed " is probably not good if incompatible to this degree, at least without some form of migration, but I guess it is what it is.

I have tools to check for duplicates that ignore deviating mediatag headers and use just MD5 fingerprints of the audio inner stream payloads to determine if unique newly encountered encoding to archives, so the anticipated duplicates from this defect will not harm my world too much other than bandwidth, whether or not duplicates get stored.

THANKS FOR FAST REPLY AND THANKS FOR AMAZING PROGRAM

[Quade]

Something regarding hash might have been altered between the two versions, or the way the servers in a list work.

This is likely the case. A switch from MD5 to a smaller text oriented hash.

Other people might be sadder than I if they lost all history stored in DownloadMarker.db3 (or at least it being not heeded in list, except for newer 6.5+ downloads) Perhaps I am the only one to notice for now, but "download tracking changed " is probably not good if incompatible to this degree, at least without some form of migration, but I guess it is what it is.

The number of people who would actually take paper notes about their usenet downloads...is one, you. I'm not saying nobody else does this but, I'm willing to bet it's one in a million. Most people don't take it so seriously. I know I don't. I consider Usenet to be a fun playground.