Danbooru 2 Issues Topic

A *_(cosplay) search is basically like a wildcard search on the /tags index, but it is limited by tag limits, 6 tags for gold, 12 for platinum+. So for gold users *_(cosplay) is effectively the same as an or-search for the top 6 cosplay tags, which just so happens to include Shimakaze. This is why it seems to only work for certain characters.

If you search *_(cosplay) by itself you can see the tags it matches under the tag list in the sidebar.

Exclusions + wildcards indeed don't work. I've updated help:cheatsheet to document this. It would probably be doable to add, but given the wildcard limits I'm not sure how useful it would be.

Welp that makes wildcards way less useful than I thought they'd be.

Oh well.

Thanks for updating the cheatsheet.

Hi, JSON api woes, trying to GET /posts.json without session results on a HTML page saying "wrong number of arguments (given 1, expected 0)" instead of JSON with actual data or a response

Noted, can confirm. Reported in issue #2693.

I'm using danbooru.donmai.us and since yesterday thumbnails and full resolution pictures are loading very slow on both Firefox and Safari. Gelbooru and Yander.re are loading normally.

So I need to know if there is an estimated time to sort this out, and if you have a alternate link I should try in the meantime.

G3Gen

g3gen said:

I'm using danbooru.donmai.us and since yesterday thumbnails and full resolution pictures are loading very slow on both Firefox and Safari. Gelbooru and Yander.re are loading normally.

So I need to know if there is an estimated time to sort this out, and if you have a alternate link I should try in the meantime.

G3Gen

There is always sonohara or and hijiribe sub-domain you can try out.

Thanks for the alternates, but something you might want to know:

I'm getting a "Your connection is not secure warning" from FF and "This certificate is not valid--Host name mismatch" warning from Safari for both sub-domains.

What do you make of that?

And I decided to try both. Same very slow loading.

g3gen said:

What do you make of that?

Certificate is for danbooru.donmai.us. When you try to access Hijiribe or Sonohara, the same certificate is used, so you get hostname mismatch, because they, well, mismatch. Wildcard cert is way too expensive to resolve something as trivial as one-time warning on mirror domains.

On that note, I sometimes experience Safebooru certificate being supplied when accessing Danbooru. Did anyone else run into that problem, or is it just me, with my proxy and opera hijinks?

Ok, don't have a problem using Hijiribe or Sonohara since the certificate mismatch isn't a problem.

Seems those subdomains are slow loading as well. Since other image boards are moving along on my 6 Mbps connection, I think that rules out anything on my end, unless it is my ISP. I'll have to wait for it to somehow get resolved.

I keep getting an error message when using tag script to update posts. Adding the tags manually works fine though.

Not sure if this is just a short term case of danbooru playing up or a bigger issue? Or perhaps it's just some kind of anti-spam filter (I've done rather a lot over the last week or two after all)? It's never happened to me before. Changing tag scripts doesn't change anything.

edit: seems to be working again. Weird.

edit: and broken again.

@kuuderes_shadow

There's recently been a change to separate API limits for reads/writes. Your API write limit is 1/10th of your API read limit (in your case 2000 writes/hour). When you use the tag script function, I believe it uses an API write call instead of an HTML write call to accomplish the update, which is why you were getting errors from the tag script function but not through the manual adding of tags.

The above was enacted primarily to limit the potential vandalism by member-level accounts as it restricts them to 300 writes per hour. However, there's not much of a use case for any account needing 20,000 - 10,000 writes per hour either (the old Platinum and Gold write limits). 2000-1000 per hour should be enough for most gardening work, plus there are also BURs.

I seem to be limited to 500 times using the tag script per hour. Does each one take up 4 parts of this API write limit thing then?

No, it should only be one unless there's a bug. You can check your limit at http://danbooru.donmai.us/users/441999.xml. But this affects any kind of update action that goes through the API, which includes tag scripting and I think some other things. Off the top of my head, note editing is another thing I think this affects.

I'm doing nothing other than opening pages/posts and tagging stuff.

I'm not sure how it works though - it just let me do another 297 tags less than an hour after the last lot, and without any earlier ones having passed the hour mark in that time. Perhaps it is 2000 an hour but adds the limit a few at a time and it was just pure coincidence that the last load was exactly 500? Except that I've not done anywhere near 2000 in an hour...

The limit refreshes once an hour, on the hour. So technically if it's 1:55PM, you could do 2000 edits, wait five minutes for it to refresh at 2:00PM, then immediately do 2000 more.

Could you refresh http://danbooru.donmai.us/users/441999.xml as you work to make sure it's not going down more than it should?

That means my limit for this hour was 297. It's not letting me use the tag script and you can check my post edit count yourself if you want (the musical note changes were manual ones; the "greyscale" additions were done with the tag script). 2000 edits ago (including hundreds that weren't with the tag script) was 3 days ago.

edit: 47 minutes past the hour and it's letting me do it again already so it's not a "once an hour, on the hour" thing.

@evazion - the number on the thing you linked goes down by 1 per time using the tag script, but it wasn't letting me do any more with it still on 2668 earlier. Quite how being on 2668 works in the first place when the limit should be 2000 I don't know...

2668 is a strange number. Not sure what's going on then, will have to investigate.

As I noted in issue #2693, the write limit it is reporting back is 10x larger than it actually is. As evazion said though, 2668 is a strange number. It's almost like you have an API limit of 3000 reads/300 writes, just like a Member-level user instead of a Platinum+ user...

If kuuderes_shadow's API read limit was below 3000, that would confirm that...

Just for reference, the following is what it looks like for me...

<remaining-api-hourly-limit type="integer">19998</remaining-api-hourly-limit>
<remaining-api-hourly-limit-read type="integer">19998</remaining-api-hourly-limit-read>
<remaining-api-hourly-limit-write type="integer">20000</remaining-api-hourly-limit-write>

As you can see, it says my write limit is 20000 when in fact it is only 2000.

Stopped me at 2692 this time. edit: and yes the figures do seem to be starting from 3000.

edit:

<remaining-api-hourly-limit type="integer">2990</remaining-api-hourly-limit>
<remaining-api-hourly-limit-read type="integer">2990</remaining-api-hourly-limit-read>
<remaining-api-hourly-limit-write type="integer">2692</remaining-api-hourly-limit-write>