post #9000000 GET!
Donmai

Danbooru 2 Issues Topic

Posted under General

This topic has been locked.

WestTxTapper said:

For about two months now, my number of uploads on my profile have been off by two. Right now, it's showing 2990 uploads, but the numbers on the upload limit and the user listings are showing 2992. It started when I was uploading post #1524526 through post #1524531.

Did anything weird happen when uploading around the time it started happening?

I'm just guessing, but maybe the upload page gave an error saying an upload failed, but in actuality the post did upload fine?

Even double-submitting an upload shouldn't cause that. The code to determine whether or not to increment the post_upload_count is straightforward: if the post was created successfully, increment the count, if not, don't. I can't think of what could make the count be lower than it should be.

Toks said:

user:<id> isn't supposed to work at all, actually, and I don't know why you'd want it to when using user:<name> is easier than remembering ids.

fav:<id> isn't supposed to work either. The reason it works with or-searches but not with normal searches is because of the implementation. The same index that holds normal tags for a post also holds favorited user ids and pool ids, for performance reasons. It doesn't hold the uploader id. Thus or-searches working for fav:<id> and pool:<id> is just an accident.

So, "not a bug but feature" unfortunately?

FoolyDooly said:

So, "not a bug but feature" unfortunately?

What part are you referring to? You mean user:<name> not working with or-searches?

I'd say that does count as a bug. But it's not a bug I personally intend to fix.

If you're talking about user:<id> not working, then that is neither a bug nor a feature. There's no reason for it to work.

EB said:

The tags that are supposed to automatically be applied to images (highres, absurdres, huge_filesize, etc.) are seemingly not being automatically applied currently.

Can you give an example of a post which you uploaded that it doesn't work on? I tried uploading a random image to my server and it worked correctly.

If the post you observed this on was uploaded by someone other than you then it's possible that the uploader just removed the tags themselves immediately after upload.

post #1568865 didn't have absurdres until I added it, and still doesn't have huge_filesize. omega8719's other recent Valvrave images are like that, so I guess removing the tags may be a possibility. I didn't realize you could do that, as I thought they were stuck like implications. Still, if that's the case, this is another reason it's disappointing to me that not all changes are tracked.

EB said:

I didn't realize you could do that, as I thought they were stuck like implications.

Yeah, I can't think of a reason for it to be like that either.

I changed it for the next version so that they'll always auto-update when you edit a post, making them impossible to erroneously remove or add.

Searching for notes or comments by tag. The autocomplete shows all tags including char, copy, and artist tags as gentag-blue instead of green, purple, and red respectively.

Edit: the regular ol' search works normally. Only the comment and note searches seem affected.

Kikimaru said:

tall_image seems to be creating the tag tag_image.

RaisingK said:

http://danbooru.donmai.us/post_versions has been timed out since at least 12/17 3pm EST.

However, it works fine if I use "?page=b#####", even for edit IDs far greater than the most recent.

budoka_azathoth said:

Searching for notes or comments by tag. The autocomplete shows all tags including char, copy, and artist tags as gentag-blue instead of green, purple, and red respectively.

Edit: the regular ol' search works normally. Only the comment and note searches seem affected.

Fixed.

Log said:

Oh neat checkbox to move favorites to parent, that will cover my one annoyance with deleting pixiv samples. Thanks for fulfilling that request!

๐Ÿ‘

1 40 41 42 43 44 45 46 47 48 315