Danbooru 2 Issues Topic

evazion said:

This is longstanding problem, discussed in issue #1039. Basically, the problem is that for mutually exclusive tags (tags that independently have a large number of posts, but that when combined together produce few-to-no results), searches become very slow and likely to time out. Some other examples: solo multiple_girls, banned_artist -status:banned, highres lowres, long_hair no_humans.

There is a trick, however: add order:score to the search and like magic it won't time out. The reason why this works is fairly involved, but the basic explanation is that order:score tricks the database into searching using a different strategy than it normally would, which happens to be faster for these searches.

Thanks for the explanation, it helps a lot. I'll have to remember that in the future.

evazion said:

• The 'Save search' button has been moved to the new '+' dropdown next to the search box.

I don't see any + dropdown next to the search box. I disabled all my Greasemonkey scripts and still don't see it. I'm on Firefox 52.
There doesn't seem to be any way to add new saved searches.

Also, help:saved searches still talks about the old button.

john1980 said:

I don't see any + dropdown next to the search box. I disabled all my Greasemonkey scripts and still don't see it. I'm on Firefox 52.
There doesn't seem to be any way to add new saved searches.

Are you using custom CSS to hide the "Go" button by the search box? I was, and I had to tweak it so it wouldn't hide the '+' too

The following is the code to hide the "Go" button, so you know what to look for.

/* Hide the Go button next to the search box. */
#c-posts #search-box form > input:nth-child(4) {
	display: none;
}

The code I was using (from the opening post of topic #9662) was this:

/* Hide the post search Go button */
*#search-box form input[type="submit"] { display: none }

Ah, yes, the above would cause issues.

<input type="submit" value="Go" />
<input type="submit" name="commit" value="+" data-jq-dropdown="#search-dropdown" />

As you can see, they both have type="submit", so both would be hidden.

Unbreakable said:

On another note, after cleaning up all (?) posts I found in solo solo_focus, the search only gives me this error.

evazion said:

Basically, the problem is that for mutually exclusive tags (tags that independently have a large number of posts, but that when combined together produce few-to-no results), searches become very slow and likely to time out.

There is a trick, however: add order:score to the search and like magic it won't time out.

An alternate workaround is to add a post ID range to the request. solo multiple_girls times out, but solo multiple_girls id:1..1000000 doesn’t (it even returns some posts...). When you’re done with that range, increase the numbers. If it still times out or is just too slow for your tastes, use a smaller range. This always works, even if order:score doesn’t do the trick.

As I’m too lazy to update the numbers myself, I wrote a user script that displays a second paginator for the IDs whenever it detects an ID range in the search field. I’m usually using 250k ranges, so that’s just ten clicks to go over all currently existing posts.

Btw, here’s what I’m using to hide the “Go” button of the search box. I think it’s a bit more resilient against future changes.

/* Hide the Go button of the search box */
#search-box form input[value="Go"] {display:none!important}

Edit: Background for the code fixed thanks to BrokenEagle98.

kittey said:

(Why doesn’t my code have a grey background?)

You need more spaces between your code blocks and pre and post sentences. It's because you're still in the INLINE ragel machine. To break out to the MAIN ragel machine, you need to have two carriage returns.

Backstory is, when Dtext_RB/Issue 9 was fixed to allow code blocks to be inline, albert used blocks instead of <pre> blocks. <code> blocks currently don't have the grey background CSS styling (but probably should). h5. Edit: Created issue #2939.

Did anyone else’s saved searches have all their individual tags reordered as well? For example, if I saved artist -something, it would show up as -something artist. copyright a_thing would turn into a_thing copyright. Both are kind of annoying because it’s harder to find the queries I’m looking for. Ordering the saved searches table by query is also kind of useless now because it orders strictly by ASCII from left to right, so all queries with excluded tags are at the top and few of the others are where I expect them.

Hmm, it looks like tags within saved searches were indeed resorted in alphabetical order (commit #da06bee0). I would consider this a bug. Internally, they're sorted so that if two people have the same search but the tags are in a different order, the site only performs the search once. But they don't have to actually be saved that way.

I don't think it will be possible to undo this, everyone's searches have already been resorted :/.

evazion said:

I don't think it will be possible to undo this, everyone's searches have already been resorted :/.

I have less than 100 saved searches with more than one tag. I’d be fine with reordering all those manually, as long as the site doesn’t undo that again...

Trying to add tags to post #8856 gives me this error:

Magick::ImageMagickError exception raised

    unable to open image `/var/www/danbooru2/releases/20170322212609/public/data/f0e32c0e2d906c4932858866346f98b5.gif': No such file or directory @ error/blob.c/OpenBlob/2712
    app/models/post.rb:177:in `ping'
    app/models/post.rb:177:in `is_animated_gif?'
    app/models/post.rb:684:in `add_automatic_tags'
    app/models/post.rb:638:in `normalize_tags'
    app/controllers/posts_controller.rb:49:in `update'

Thanks, fossilnix and BrokenEagle98. The custom CSS is why I didn't see the + dropdown. I had forgot I ever set that.

Thanks, kittey. That updated code block works.

If anyone uses Danbooru Miscellaneous Tweaks script to move the search bar into the navbar, I made the following change so that it includes the + dropdown.
1. Turn off the tweaks and copy the HTML source for the + dropdown.

<input type="submit" name="commit" value="+" data-jq-dropdown="#search-dropdown" />
<div id="search-dropdown" class="jq-dropdown jq-dropdown-tip">
...
</div>

2. Edit the script. Go to the line with searchBox.innerHTML =. Paste that into the string before </form>. You may need to remove extra newlines and spaces from what you paste.

Unbreakable said:

Trying to add tags to post #8856 gives me this error:

This is another thing caused by image hosting moving offsite. There's an autotagger that automatically tags animated gifs whenever the post is saved, but that doesn't work now that image files aren't kept on the same server anymore.

I'll make an issue. Currently this should only affect gifs below post #10000.

evazion said:

This is another thing caused by image hosting moving offsite. There's an autotagger that automatically tags animated gifs whenever the post is saved, but that doesn't work now that image files aren't kept on the same server anymore.

I'll make an issue. Currently this should only affect gifs below post #10000.

Funny thing is that I could tag it like normal when I tried from my phone a few hours later.

Hmm, it looks like it only fails on http://hijiribe.donmai.us. If you're on http://sonohara.donmai.us it still works.

Pixiv messing with links. Again.
Original image link may change if i reload page.
http://www.pixiv.net/member_illust.php?mode=medium&illust_id=61202991
Original image links may be:
http://i.pximg.net/img-original/img/2017/01/31/07/20/48/61202991_p0.png
New domain. Yay.
Return 403, obviously.
And
http://i4.pixiv.net/img-original/img/2017/01/31/07/20/48/61202991_p0.png
or
https://i4.pixiv.net/img-original/img/2017/01/31/07/20/48/61202991_p0.png
Well, should be no problems with these 2.

Can anyone else confirm this new domain link for original image?

There's issue #2930 for this.

Site update (2017.03.22 - 2017.03.27)

Changes

• issue #2937: Moving favorites is less broken. An upvote is now correctly given for every favoriter that has voting privileges.
• Deleted posts now link the uploader to the upload feedback thread.
• issue #2931: wiki pages for character_(cosplay) tags now include a notice that they imply character and cosplay.
• issue #2933: alias and implication lists on wiki pages now have "(learn more)" links.
• Approvers: the mod queue nag message was changed to every 20 hours (down from every 24 hours).
• issue #2934: The /moderator/dashboard page should load more quickly.
• Thumbnails on the /moderator/dashboard page now use the same HTML that thumbnails do on the rest of the site.

Fixes

• issue #2937: favorites by non-gold supervoters didn't superupvote the post.
• issue #2933: during tag searches, when a tag didn't have a wiki entry, the Wiki tab didn't list the tag's aliases/implications.
• issue #2930: http://i.pximg.net Pixiv URLs weren't recognized when uploading.
• issue #2939: inline [code] tags were missing CSS styling.
• issue #2943: editing an animated gif post below post #10000 threw an exception.
• issue #2940: the search page threw an exception if there was a post with a null source.

Full changelog: https://github.com/r888888888/danbooru/compare/production-2017.03.22-212722-utc...production-2017.03.27-235216-utc

Some words about moving favorites:

• Moving favorites now gives an upvote to the parent post on behalf of every favoriter who has voting privileges. This includes gold+ and supervoters. For supervoters, these upvotes will be superupvotes (+3).
• Previously favorites by member-level supervoters didn't give upvotes. Only gold-level supervoter favs gave upvotes. Now all supervotes favs give a superupvote.
• Upvotes are based on the user's current privileges. So normally when a regular member favorites a post, it doesn't give an upvote. But if later they upgrade to gold or become a supervoter, and their favorites are moved, those favs will now give upvotes.
• Likewise, if a person loses their voting privileges, moving their favorites won't upvote the parent, even though that favorite may have originally upvoted the child.
• Non-favorite votes are not (yet) moved. Voting records only kept for 90 days, so in many cases there won't be many votes left to move. And I'm not sure if downvotes should be moved, since if someone downvotes a post for being an image sample, that shouldn't necessarily translate to the parent.
• Favorite ordering is still not preserved.