Ok,cool.Iāll keep an eye on it and report back if this happens again. Thanks!
I just updated from commit c8cc845d5b1c64ea259667c01a9591a04e0e4e98 to ac17ded854557e77840bf99ec48e736a2586f7e4 and again 889 articles got their read status reset.
They again consist of various sources: Reddit topics, forum topics, GitHub RSS feeds, and blogs (including the one I described above)ā¦
search before posting, there were guid changes some time ago
I know that, itās been discussed here. But those changes were not between c8cc845d5b1c64ea259667c01a9591a04e0e4e98 and ac17ded854557e77840bf99ec48e736a2586f7e4.
hmmmm
ah right, enabling or disabling plugins causes a rehash, which is what you probably did
this kind of stuff is why I wouldnāt recommend this option
Ouch! That is indeed what I did, to test for Prefs: TypeError: App.isCombinedMode is not a function, and what I had to do again just now, right after cleaning up the messā¦
Imho this is unexpected behavior, whatās the reason behind it?
plugins might change article content so when you enable something this lets the plugin do its thing transparently
this was the reason, idk if its a worthy one
Hereās my 2ct.
Iām trying to think of a use case where the end user would want to re-read a whole bunch of articles, just because a plugin has now handled the respective articles differently. I canāt think of a reason t.b.h.
I think it would be the responsibility of the end user to first mark articles unread if they wanted those articles to be re-read after some plugin went over them (or stopped doing so).
The option to āMark updated articles as unreadā to me reads as an update of the source, so the article itself, not what tt-rss does with it.
An RSS feed doesnāt provide the entire article in the feed, only an excerpt. The user enables af_readability to replace the excerpt with the full article.
Every user is different. It makes sense that when enabling a plugin that modifies article content that TT-RSS would consider the article content changed.
But only because thatās how youāre thinking. Iām not saying itās not a valid opinion, but I am saying itās just as valid as: āI think it would be the responsibility of TT-RSS to mark articles unread after some plugin went over them.ā
Internally TT-RSS does a lot of work to figure out what the source being modified is, but plugins can intercept and change that at multiple points. Given that users doesnāt often toggle plugins on a daily basis, the current approach makes sense. The alternative makes sense, too. Thereās no right or wrong here, just the way TT-RSS does it.
The one I can think of is if they subscribed to a bunch of feeds that donāt include the articles and then enable something like readability or af_comics.
i think this (rehash on active plugin list change) is one of those things that might go here or there, arguments might be made for both ways to behave.
if i was implementing this now, i might have chosen differently, but since this how this has already worked for years and the only arguably strange synergy is with the redheaded stepchild option (mark unread on update) iām not sure if its worth it to suddenly change it.
also, remember that changing this would ALSO rehash everything AGAIN.
@JustAMacUser and @ovalwonder I think those are valid points, too, sure. The thing is that āMark unread on updateā, be it the āredheaded stepchildā or not, is imho a great feature to keep track of changes in blog (and forum) posts, so you wonāt miss the latest edit.
I agree that this would be tailored more to the way I look at it and how Iām trying to use this feature, but I still have trouble thinking of a use case where the end user would like to have almost all its articles, dating back years and years, marked unread, because they tried en-/disabling a certain plugin.
Ah, Iām thinking I might be able to āhack itā to my personal needs in my updater script. First gotta find it in the code, thoughā¦
Wait! What!? You donāt purge articles?
Hehe fair point! Got some really old articles starred/published, though. Plus, when following topics, the amount of articles that are marked unread goes well beyond a 1000 at times.
https://git.tt-rss.org/fox/tt-rss/src/master/classes/rssutils.php#L19
see, it joins calculated value with the list of loaded plugins. you can replace that with sha1($tmp)
etc
Thx for pointing this out! Iāve added it to my little script, all good now
Is it possible that changing the hash calculations causes the following problem by any chance?
Since doing so, I regularly see that āFresh articlesā does not list all articles that fit the criterium. For instance, an unread article that is only an hour old is not listed among the Fresh articles, but the Fresh articles count in the navigation bar does include that article (e.g. the count is 2, but only 1 article header is shown).
E: the unshown item can be from a feed that has other items that are shown in Fresh articles.
I just updated to the latest commit and changed the rssutils.php line 19 return sha1($tmp);
again (before replacing the files), just like it was before this update. Now, Iām again stuck with thousands of articles that are marked unread again for no reasonā¦
why are you doing this to yourself?
The simple reason is that I want to know if someone edits their blog post or changes their comment in a topic. This happens all the time and and is always contributive to the topic, and I would miss the updated info if I didnāt set the āmark unread on updatedā to true.
Thatās a very good reason for trying to use it, Iād say
But Iāve found now that the new $enclosures has caused the hash recalculationsā¦