Danbooru 2 Issues Topic

When uploading posts, sometimes the post gets "stuck" on the processing page (looks like this) if the post is submitted too quickly before the upload finishes preprocessing; despite the page saying "This upload is being processed. Please wait a few seconds", very often the post ends up not fully processing at all. This resulted in the upload not going through the first time. This does not happen if the post is allowed to finish preprocessing.

I'm not sure if this is an error, because in the past, if the post is submitted before the preprocessing is finished, the page will remain on the New Upload page before loading the post page.

ugoira player isn't working for posts that link from raikou subdomain

example: Post #1830358

shujito said:

ugoira player isn't working for posts that link from raikou subdomain

example: Post #1830358

Works fine for me.

I have a suggestion: increase the image preview/thumbnail/small size from 150px.

The current default is 150px (https://github.com/r888888888/danbooru/blob/master/config/danbooru_default_config.rb#L78) and according to the repo history, this has been set since at least 2010 and has never changed. The live Danbooru uses this as well. Before 2010, user monitors were still often 1024px or less: but you would have to use a smartphone to be that small nowadays.

When using my RSS reader, I have noticed that over the years Danbooru feeds gradually have become harder to see and decide what images to check. I think it is not just that screens have become much larger and PPIs have increased, but that the artwork has become more complex and ambitious. When I browse back to very old images like 2009 and compare to the front page now, the newer images are larger in every way: more details, more characters, more scope. (All the free art tools and Pixiv and tutorials and competition.) These are all good things. But they mean that 150px thumbnails get a little worse every year as a default for everyone, particularly RSS readers.

inkuJerr said:

When uploading posts, sometimes the post gets "stuck" on the processing page (looks like this) if the post is submitted too quickly before the upload finishes preprocessing; despite the page saying "This upload is being processed. Please wait a few seconds", very often the post ends up not fully processing at all. This resulted in the upload not going through the first time. This does not happen if the post is allowed to finish preprocessing.

I'm not sure if this is an error, because in the past, if the post is submitted before the preprocessing is finished, the page will remain on the New Upload page before loading the post page.

I think I should add something more to this. If the first uploader clicks submit when the second uploader tries to upload from the same source, the former would get the processing page (even if their post already finished preprocessing) if the latter's upload page is still in the preprocessing state.

@evazion confirmed that it is due to the system not detecting that the upload was already completed by the first uploader. Although, is there a way to keep upload (pre)processing "separate" among users so that a user's uploads won't get stuck on the processing page due to interference from another user? ("Separate preprocessing" used to be present before)

Re: bigger thumbnails, this is planned but will take time. The goal is to have multiple thumbnail sizes that you can toggle between. This is probably going to require some server upgrades first.

Site update

Changes

• Removed the "Remember?" checkbox from the login page. Unchecking this box meant you would be logged out when closing your browser window. This functionality has been removed.
• Notes: adjust /notes page layout (usernames and timestamps are now on the right).
• Notes: added a fallback font for Comic Sans to support devices that don't have this font.
• Removed /janitor_trials page.

Fixes

• Fixed issue with not being able to create a new alias that had the same name as a previously deleted alias.
• Fixed /artists/{id}.xml erroring out.
• (Mods) Fixed issue with the Last IP field on profile pages being empty in some cases (issue #4213).

API Changes

• /artists/{id}.xml no longer returns the domains field.
• /posts.json no longer returns the keeper_data field.
• /tag_aliases.json no longer returns the post_count field.
• /users/{id}.json no longer returns the recent_tags field for the current user.
• Made some internal changes to autocomplete that may affect userscripts.

Full changelog: https://github.com/r888888888/danbooru/compare/production-2019.11.13-025824-utc...production-2019.11.19-191229-utc

n/m

Unbreakable said:

Works fine for me.

works well on firefox, doesn't work on safari

There is a problem with me while I'm trying to upload with the bookmarklet from yande; I'm getting a 404 => Net::HTTPNotFound kind of error.
The details are as it follows:

ActionView::Template::Error exception raised
app/logical/pixiv_api_client.rb:189:in `fanbox'
app/logical/sources/strategies/pixiv.rb:363:in `metadata'
app/logical/sources/strategies/pixiv.rb:166:in `artist_name'
app/logical/sources/strategies/moebooru.rb:39:in `artist_name'
app/views/sources/_info.html.erb:12
app/views/uploads/new.html.erb:16
app/controllers/uploads_controller.rb:12:in `new'

Apologies if this has been brought up already, but translation note text used for links appears to be treated as individual characters now rather than retaining word integrity; i.e., the text is likely to wrap to the next line right in the middle of word if said word is used for a link. (See here (strip title) and here (second link in panel 4's 1st note). This did not appear to be happening until relatively recently. Is there a fix in the works, or is it considered a necessary flaw that we just have to work around/tolerate?

Moonspeaker said:

Apologies if this has been brought up already, but translation note text used for links appears to be treated as individual characters now rather than retaining word integrity; i.e., the text is likely to wrap to the next line right in the middle of word if said word is used for a link. (See here (strip title) and here (second link in panel 4's 1st note). This did not appear to be happening until relatively recently. Is there a fix in the works, or is it considered a necessary flaw that we just have to work around/tolerate?

I brought that issue up on Discord, but nobody paid attention. Anyways, a fix for that is to set style="word-break:normal" for each and every link. Now that's a bit ridiculous to do for every link on all of the notes though, so I haven't gone and fixed my own notes yet.

It's a bug, it's a rule that was meant for links outside notes accidentally bleeding into notes.

BrokenEagle98 said:

I brought that issue up on Discord, but nobody paid attention. Anyways, a fix for that is to set style="word-break:normal" for each and every link. Now that's a bit ridiculous to do for every link on all of the notes though, so I haven't gone and fixed my own notes yet.

evazion said:

It's a bug, it's a rule that was meant for links outside notes accidentally bleeding into notes.

Thanks for the explanations. Guess I'll either have to utilize the style mentioned above for every link, or just be patient until Albert or one of the others modifying site code can manage to implement a fix.

The goal is to have multiple thumbnail sizes that you can toggle between. This is probably going to require some server upgrades first.

Good to hear. But is there some particular reason to not change the default right now and delay it until these planned toggle changes and server upgrades? Also, how will that handle non-logged-in thumbnails, such as the RSS feeds?

Reverse image search will be down for a little while as Danbooru's IQDB instance undergoes a migration.

EDIT: should be working again now.

The issue where tags bleed through spoiler code has resurfaced.

Parappa the Rapper with Milk Can, Chop Chop Master Onion, and PJ Berri as DJ, at the You Gotta Believe event

It seems that only untouched tags (tags that haven't had their properties edited and no wiki) won't bleed through.

edit: issue fixed

Site update

Changes

• Changed how posts are chosen for the Curated pool (pool #12514). Now it's the top 100 posts from the last week, in order of most super-upvoted to least. Before it was every post with at least 3 supervotes (upvotes or downvotes), in no particular order.
• Disabled the "You have underused tags on your uploads" dmails. These reports were sent to uploaders showing the top tags added to their uploads over the last week. This had problems with false positives from things like aliases, implications, and source or parent changes.
• Added multiple new fonts for use in notes by translators. See forum #161211 for details.

Fixes

• Fixed tag colors bleeding through spoiler tags.
• Fixed tag colors not showing when hovering over spoiler tags.
• Fixed above issue with links in notes having linebreaks in undesirable locations.
• Notes: adjusted line heights to reduce the amount of space between lines when using non-default font families or font sizes.

Full changelog: https://github.com/r888888888/danbooru/compare/production-2019.11.19-191229-utc...production-2019.11.27-031552-utc

Thornton said:

Good to hear. But is there some particular reason to not change the default right now and delay it until these planned toggle changes and server upgrades? Also, how will that handle non-logged-in thumbnails, such as the RSS feeds?

Just changing the current size isn't an option, too many people are used to it and would be displeased if there were no way to switch back (see the recent Youtube redesign, they made thumbnails bigger and people hated it).

Disabled the "You have underused tags on your uploads" dmails.

Thank you.