That's part of the problem -- the tilde is necessary in the new system since it indicates boolean "or" of the terms. Without the tilde, you'd be searching for "and" across all terms. See the cheatsheet: http://danbooru.donmai.us/help/cheatsheet
Edit: My own favorite tags haven't changed yet, but I've also been watching RaisingK's "general" and "touhou" favorite tags lists. About 20 min ago, the newest image in favtag:raisingk:general list was post #391011 (12 hours old); post #391021 (also 12 hours old) was not in it then but has just now become the newest addition (currently still 12 hours old) Similarly, 20 min ago, the newest image in favtag:raisingk:touhou list was post #391009 (12 hours old); post #391025 (also 12 hours old) was not in it then but has just now become the newest addition (currently still 12 hours old). post #391057 will be next (currently 12 hours old)
Alright then, so the question is, why is it taking 12 hours to update? And how can we fix it?
12 hours is an atrociously large time lapse between time of upload and list update. You might as well just search your favorite tags once daily for the same effect.
Kayako said: Taking a quick scan of both of your profiles, Homo and r0d3n7z, the difference may have to do with the ~. Homo, it looks like you deleted the proceeding ~ before tags, while r0d3n7z didn't. That may be why it isn't updating for you.
Even with those, it wasn't updating. The reason I removed the tilda marks was in hopes that the posts showing up would change. The images are still the same before and after I removed the tildas.
I guess I'll add the ~ back and see if anything happens.
The 12 hour delay is also observed with posts that are properly tagged. In particular, I uploaded a whole lot of of touhou stuff the day before, tagged them correctly at the point of uploading, and watched as they took 12 hours to appear in favtag:RaisingK:Touhou and favtag:r0d3n7z:Characters (which contains several touhou characters).
albert said: the query is based on the tags when the query runs
I'm not sure what you mean by that, but there are discrepancies when I simultaneously pull a set of favorite tags and the corresponding tag query and compare the results. Eg: as I type this, there are 40+ images (all <12hr old) that are missing from favtag:RaisingK:Touhou which appear in the corresponding full query result -animal_ears -genderswap touhou. Images older than 12 hours match up almost perfectly (50+ posts), except post #391576 and post #391574 -- I assume those got in there before RaisingK changed the tags, adding -animal_ears -genderswap to what was originally just touhou.
Looks like homeless_homo's favtag:homeless_homo:General is sort of working now that he reinserted the tildes, but it's also 12 hours behind, presently lacking 8 images that can be seen in ~flat_chested ~loli.
It also appears that newly created favorite tag sets always start off populated with a bunch of random posts (both related and unrelated, including posts newer than 12 hrs), and it will remain so until new posts uploaded under the corresponding tags displace the irrelevant images. I've just created favtag:r0d3n7z:testset, which contains exactly 60 images, some of which are only minutes old, but none of which are traditional_media.
Kayako said: Alright then, so the question is, why is it taking 12 hours to update? And how can we fix it?
I'm just as dumbfounded, really.
OTOH, I may be wrong, since I'm reporting observations based on monitoring the favorite tags of only a small handful of users -- most favorite tag lists I came across have tags which are infrequently seen, and too few tags, so they're fairly static and don't yield any interesting observations.
r0d3n7z said: The 12 hour delay is also observed with posts that are properly tagged.
And just how is Danbooru supposed to automatically determine that it's properly tagged? I believe Albert is saying that there is a constant 12 hour delay built in, to give other people time to tag the post. This is necessary as an image is only checked once to determine if it fits a given tag group.
There's a background process running. Every 5 minutes this process searches for posts it hasn't checked that are more than 12 hours old. For each post, it tests the tags against each favtag. If it matches, the post id is cached inside the favtag. This is why each favtag is hard limited to 6o posts or so (because the id list is pruned). This method is very fast, scalable, and well suited for things like RSS feeds.
But it is confusing. So let me propose alternatives.
1) Treat the favtag like a bookmark. Execute the query every time someone views the page. No limits. This will potentially be slow though, especially for huge tags like touhou. 2) Run the query every time the daemon process checks each favtag. But still cache the post ids. Limited to 100 posts or so.
Choosing to disable querying to save resources can also be nice, in cases of users that are using their favtags as a quicklink/hub, like ePlus previously said. No posts would show up anyway when many unrelated tags are together.
Thanks to the new max tag limit (is there a new one or no limit?), I can now use the user corner as I wished.
The removal of the commas separating fav tags is kind of saddening, but we can manage. :P
And it seems the alphabetical auto-ordering remains, but not anymore for the tag lists when you edit them - they keep their order as you typed them. They were auto-ordered before. It isn't too important, just mentioning for your notice.
There's a background process running. Every 5 minutes this process searches for posts it hasn't checked that are more than 12 hours old. For each post, it tests the tags against each favtag. If it matches, the post id is cached inside the favtag.
It'd be better if it kept track of the internal "change ID" value, and checked posts that have been changed since last time. Otherwise you'll end up missing posts that have had tags added or removed 12 hours after posting, and in any case the 12 hour delay is very counterintuitive.
But checking all posts whose change ID is greater than the last processed change, you can then add and remove these posts accordingly, without delay. That should allow favtag results that are as good as doing a full tag query each time, both in how quickly they update and ensuring that tag changes are reflected properly.
piespy said: It'd be better if it kept track of the internal "change ID" value
Great idea; seconded! Narrowing down the search this way should allow us to execute the query on each access without taking the horrible performance hit of running the full query across all posts.
