Danbooru 2 Issues Topic

Once again Saved Searches has crapped out. Here's the error code.

Redis::CommandError exception raised
app/models/saved_search.rb:32:in `block in post_ids_for'
app/models/saved_search.rb:30:in `each'
app/models/saved_search.rb:30:in `post_ids_for'
app/logical/post_query_builder.rb:265:in `saved_search_matches'
app/logical/post_query_builder.rb:155:in `metatag_matches'
app/logical/post_query_builder.rb:94:in `block in metatags_match'
app/logical/post_query_builder.rb:93:in `each'
app/logical/post_query_builder.rb:93:in `metatags_match'
app/logical/post_query_builder.rb:474:in `build'
app/logical/post_query_builder.rb:854:in `block in exact_count'
app/models/application_record.rb:121:in `with_timeout'
app/logical/post_query_builder.rb:853:in `exact_count'
app/logical/post_query_builder.rb:830:in `fast_count'
app/logical/post_sets/post.rb:101:in `get_post_count'
app/logical/post_sets/post.rb:113:in `posts'
app/controllers/posts_controller.rb:14:in `index'

I'm new here, so I don't know if this is a persisting issue or not, but I've noticed the "Similar" button when uploading doesn't really work as intended.

It's supposed to transplant all the necessary artist and tag info from pixiv, for example, but also showing you if the image you're uploading has already been uploaded. But, it doesn't really do the latter part all that well... I've inadvertently uploaded duplicates twice now, and run into this issue at least five times.

While it's not an enormous issue, it is a little annoying and makes uploads go a bit slower than they should.

EDIT: Okay, make that....damn near constantly now. It's not showing already-uploaded images whatsoever anymore. :(

Alright, appears to be working correctly now. Thanks. :)

Gateway errors out the yin yang, right now. What's going on?

WatcherCCG said:

Gateway errors out the yin yang, right now. What's going on?

Site seems to be under heavy load right now.

Is the /posts endpoint of the api under cors now? Was that intentional?

Edit: Nevermind. It's working again.

Resolved some recent downtime. The site was experiencing very heavy load for a while, possibly because of a DoS attack. The front page was receiving 4x the normal amount of traffic. Popular tags in the sidebar are temporarily disabled.

Pixiv commentary fetch fails when encountering a closing parenthesis. The parenthesis and every character following it are not retrieved. At a minimum the commentary title is impacted, I do not know if the same thing happens with the commentary body.

Example: post #4193654. Commentary fetch retrieves "御蔵ちゃん(>ワ" instead of "御蔵ちゃん(>ワ<)とボクノオシリ"

Arcana55 said:

Pixiv commentary fetch fails when encountering a closing parenthesis. The parenthesis and every character following it are not retrieved. At a minimum the commentary title is impacted, I do not know if the same thing happens with the commentary body.

Example: post #4193654. Commentary fetch retrieves "御蔵ちゃん(>ワ" instead of "御蔵ちゃん(>ワ<)とボクノオシリ"

It's the < that does it.

I suggest using links like twitter.com/i/user/%ID% instead of twitter.com/intent/user?user_id=%ID%
For example:
1. https://twitter.com/intent/user?user_id=923611254631014400 redirect to https://twitter.com/intent/user?screen_name=danboorubot (subscribe page)
2. https://twitter.com/i/user/923611254631014400 redirect to https://twitter.com/danboorubot (profile page)

Not sure where else to put this, but I've rewritten part of help:post_relationships, specifically the part listing various ways to decide which post to parent. Some lines were technobabble with no actual meaning (like the colorspace part), others were added by mikaeri to justify having his duplicates as parents. I might just rewrite it from scratch later to make it simpler if nobody is against it, because much like other old wikis it suffers from excessive verbosity and it doesn't really help anyone who needs it.

nonamethanks said:

Not sure where else to put this, but I've rewritten part of help:post_relationships, specifically the part listing various ways to decide which post to parent. Some lines were technobabble with no actual meaning (like the colorspace part), others were added by mikaeri to justify having his duplicates as parents. I might just rewrite it from scratch later to make it simpler if nobody is against it, because much like other old wikis it suffers from excessive verbosity and it doesn't really help anyone who needs it.

I think, need use

Wiki Requests. Wiki editing general discussion.
https://danbooru.donmai.us/forum_topics/8235

Apparently, using tag script mode to add posts to favgroups adds the tag null to the posts. Not sure if it happens with pure pool additions as well.

Tag changes here.

Chaos Exia00 said:

not sure what a null tag edit means, but I was trying to use tag script mode to bulk add those pics to a fav group

I put favgroup:<group name> for the tag and the clicked on the pics i wanted in that group

Site update

Changes

• Added popular tags back to the frontpage.

Bulk update request (BUR) changes

• Added a nuke command. Can be used to nuke tags or pools. Usage: nuke touhou, nuke pool:Disgustingly_Adorable.
• Aliases can be reversed in a single step now. If you want to reverse rabbit -> bunny, you can just say alias bunny -> rabbit without having to remove the old alias first.

• New rules for requesting implications:
• Both tags must be of the same type. You can't request implications from character tags to copyright tags, for example.
• Both tags must have wiki pages. This can no longer be skipped. If a tag doesn't have a wiki, you should write one before you request the implication.
• The child tag (the lefthand one) must have at least 10 posts, and must be at least 0.01% the size of the parent tag. For example, to imply a tag to shirt, the tag must have at least 50 posts, because shirt has 500k posts and 0.01% of 500k is 50. This only apples to general tags. This will probably be raised in the future.
• The child tag can't make up more than 90% of the parent tag. For example, an implication like spider web -> silk wouldn't be allowed, because 95% of silk is just spider web. This will probably be lowered in the future.

• Other new rules for bulk update requests:
• Aliases must be used for tags with more than 200 posts. Renames can't be used for tags with more than 200 posts.
• You can't have more than 100 lines in a single BUR. Larger requests should be split into smaller chunks.

Fixes

• Fixed a bug where if a BUR contained a mass update followed by an alias, then the alias would take effect before the mass update, potentially producing incorrect results.
• Fixed the BUR rename command not moving aliases or implications.
• Fixed it being possible to request implications that already existed.
• Fixed it being possible for a large BUR to contain redundant aliases or implications.
• Fixed it not being possible to reverse an alias in a single request. Previously it would return an error if you tried to reverse an alias by removing it and recreating it in a single request.

Full changelog: https://github.com/danbooru/danbooru/compare/production-2020.11.09-193625-utc...production-2020.12.03-235411-utc

evazion said:

Aliases must be used for tags with more than 200 posts. Renames can't be used for tags with more than 200 posts.

This might be pointless since if the last post is 2+years old, they are retired by topic #15484. (reference)

Travley said:

This might be pointless since if the last post is 2+years old, they are retired by topic #15484. (reference)

It's like that because with large tags you should always assume that someone could search for the old name. If there's only old posts there's no harm, it'll be retired after a week, but if it's a tag that still gets posts then it'll prevent missed searches.

Figured out an apparent bandaid for searching for artists using weibo link, by removing the https:// from the link.

evazion said:

Site update

• The child tag can't make up more than 90% of the parent tag. For example, an implication like spider web -> silk wouldn't be allowed, because 95% of silk is just spider web. This will probably be lowered in the future.

How exactly does this 90% work? If, hypothetically, none of the images with the child tag also have the parent tag at present, would that mean the implication couldn't be proposed if more than 45% of the parent tag post-update would contain the child one, without spending a large amount of time tag scripting the parent tag onto the child before making the proposal?

evazion said:

• Aliases can be reversed in a single step now. If you want to reverse rabbit -> bunny, you can just say alias bunny -> rabbit without having to remove the old alias first.

Try use, but it's issue?
https://danbooru.donmai.us/forum_posts/177229
Not actual.

I've removed from howto:upload the parts regarding anatomy/image quality and slimmed the page a lot. Please lemme know if you think there's ways it can be improved further.
What's acceptable and what's not is already described in help:upload rules, and a lot of the paragraphs I removed made no sense or were extremely subjective.

Trying to describe the threshold for quality has always been impossible, so I don't think there's much else that can be offered to new users other than making them look at status:active approver:any for a sample of acceptable quality. The alternative is writing up a wall of text that nobody will ever read (and that will eventually become obsolete, as the previous page did).