6.90 RC1 5424 - Mark as Old not "sticking"

[rh]

Just noticed this in B10, figured I'd try RC1 before posting.

First, loading the group seems too quick. Not that this is bad, just that I thought something was broken because the status bar barely had time to show itself

So, Mark as Old - this has worked forever, for me. But now Mark As Old only works temporarily. Once you load the group again, those post marked old are new again. When I do Mark as Old, it does happen instantly - unlike a scenario I read in another post. So it's acting like mark-as-old for display purposes only and is not physically marking the post as old.

I usually always have Hide Old enabled and mark posts as old as I sift through them - so I don't see them again, but they're not physically deleted in case I do want to see them again.

FWIW, this is in a newly created Watch Topic.

[rh]

ok, Shift-DEL does not work either

1. Select some posts
2. Shift-DEL then confirm
3. Close tab
4. Open group

Deleted post remain intact.

[rh]

...both methods (mark old / DEL) work fine in ordinary individual groups. So it's only a problem in Watch Topics.

[Quade]

I have a "no repro" note on my bug note for this.

I have a header based watch list which loads up naturally as headers download. You're not re-downloading header for any of these groups are you? For shift-del, if you re-download and re-feed the headers, they'll show back up after a "Shift-delete". A rescan will feed them again too.

I just "shift-delete" the top 10 newest items in my favorite watch topic and when I reloaded the group, they didn't show back up. This was with no header downloads between the delete and the re-load.

It sort of sounds like you're re-feeding the files to the watch. Try my experiment. shift-delete, wait 20 seconds then re-load with watch with no header downloads and see if they're still gone.

[rh]

Yeah, I wasn't sure if my experience was the same, but I did see an earlier thread this year where you mentioned not being able to repro.

My watch topics only refresh every 6 hours. Can I assume that means no header downloads occur during that time?

It's currently showing 1h 45m since the last update. So I loaded the group, removed some easily recognizable posts, closed the tab, waited 20 seconds, opened the tab, those post are back, new again.

Where is the old "mark" made? IN a DB? Someplace I can look to see if the bit is set? As I mentioned, they instantly go away. I just now turned off hide old to make sure they did adopt the proper "color" for old posts, they did.

I'd been on B10 since May and everything worked normally. Mark Old just always worked. The only thing that changed recently was (for a specific WT) to create a new WT. Which solved my other mysterious problem. https://forums.newsbin.com/viewtopic.ph ... 90#p231720

Just picked another random WT to exclude the new one as somehow related. Same thing. Remove a half dozen new post, close the WT, wait 20 seconds, those same post are still new. While in my a.b.mp3 test, it works like it always has - mark as old does just that. I can turn off hide old and see them in the different "old" color too.

So, for me, only Watch Topics are presenting this problem. I don't recall from the other post (Jan I believe) that it had any relation to Watch Topics.

Since you mentioned "feeding". Just tossing this up for thought. My other problem that I recently solved with WT's simulated an unexpected feed - in a way. Recall that a.b.misc was removed from the GOG used by the WT - yet the next day (having left the tab open) I would see a.b.misc posts from 90 days ago reappear. Now that I think about it, I suspect mark old and delete were not working then either. Because I'd go through those steps, then visually parse the group for topics. But I don't "remember" reloading the group and actually verifying if my mark-old/del was working.

BUT, creating the NEW WT DID stop a.b.misc from coming in.

I assume that if ANYTHING is being "fed" in, that I should be able to find that in the log? My log is usually just filled with this...

[08/22 20:10:29] DEBUG NZB File Load Checking
[08/22 20:10:37] DEBUG Periodic Search: Waiting for next Period 14880 Secs

[Quade]

My watch topics only refresh every 6 hours. Can I assume that means no header downloads occur during that time?

Double-clicking to look at the group also triggers a header download.

"Remove" meaning Shift-Delete? or just delete? The two are quite different. One just tags the files, one removes them from the DB altogether.

Where is the old "mark" made? IN a DB? Someplace I can look to see if the bit is set? As I mentioned, they instantly go away. I just now turned off hide old to make sure they did adopt the proper "color" for old posts, they did.

I don't remember to be honest. "Old" is probably "DownloadMarker.db3". In the past it was in the header database. I have to look to see if "DownloadMarker" replaced using the header DB for this. At one point it depended on whether it was headers or "Search/NZB" but I don't remember where I left it.

[rh]

I never double-click - remember, I'm the ONE other person that 'wished' for an option to disable that because my mouse can be erratic

But when those accidents happen, I know because I can see the header download start.

I've tried BOTH methods of Remove. Mark as old and literally delete. Neither work in Watch Topics now. Only in ordinary groups.

I see

DownloadMarker.DB3-wal
DownloadMarker.db3
DownloadMarker.DB3-shm

[rh]

Does this answer the DownloadMarker question?

https://forums.newsbin.com/viewtopic.ph ... b3#p231717

Presumably IsOld_V1 is the table that controls what is considered old. But I don't know how to compute the SubjectHash

[rh]

Ok, wow, go back TEN years, same problem. But the "switch" to fix it no longer exists

https://forums.newsbin.com/viewtopic.ph ... v1#p174226

[rh]

any other thoughts Quade? This is super easy to repro now. ANY Watch Topic I load exhibits this problem. Mark old simply does not work.

<update> in 6.82 5142, mark old works for Watch Topics.

[Quade]

None of my watch topics have this issue.

When you select files and hit the delete key, do the files turn gray?

Might be worth picking one, right click "Post Storage/Delete Stores Posts" then rescan the group to re-feed the watch and see if the symptoms change.

I'm wondering if it's an old header format versus new header format issue. I'm not aware of one marking old though.

[rh]

Just picked another random WT to exclude the new one as somehow related. Same thing. Remove a half dozen new post, close the WT, wait 20 seconds, those same post are still new. While in my a.b.mp3 test, it works like it always has - mark as old does just that. I can turn off hide old and see them in the different "old" color too.

Regarding turning gray - yes - see above from my prior long winded post. Clarifying that, in the Watch Topic (with Hide Old active) marking old caused them to disappear. If I then those None for Display Setting, I see the gray. But those same ones become green upon reopening the Watch Topic.

It's just that they are no longer old once you reopen the group. I'm using 6.82 now. Was that the last GA release? I didn't realize that was the same one on the current download page.

Not sure what else I broke, but going back whacked my Files List - though that's really harmless and not too surprising.

I'll need to setup a duplicate installation to do testing in. Does NB use the registry in a way that would prevent me from switching between two different installed versions in two different Program Files folders that use unique .nbi files and unique DataPath?

[Quade]

I only test with 6.90. 6.82 is soon to be superseded. Yeah, the files list was forward compatible but not backwards.

[rh]

I'll need to setup a duplicate installation to do testing in. Does NB use the registry in a way that would prevent me from switching between two different installed versions in two different Program Files folders that use unique .nbi files and unique DataPath?

Is that feasible ^^^ ?

[Quade]

You can do it by using two shortcuts each passing a different NBI in the command line. Make sure they don't share data folders.

Even easier, you could copy folders in spool_v6 so you can experiment and restore. Say you want to wipe and restore a watch list but not lose any data. Just make a copy of the folder containing the watch data then work on the copy.