Donmai

Danbooru 2 Issues Topic

Posted under General

This topic has been locked.

The desktop mode setting doesn't stay enabled for me, yesterday at this time I changed it to "yes", but now that I refresh the page it's on "no" again. I tried searching for related stuff but couldn't find much related to the setting itself not staying on. Apologies if I missed something since I'm on mobile at the moment.

Both servers were almost out of hard disk space. I'm currently deleting some unused files on hijiribe and I don't have any idea when it'll finish. I think probably in the next day or two. Afterwards I'll have to take sonohara offline and delete files on that server as well. So in total we're looking at 5-6 days.

Messes up my tagging habits because the box I type tags on gets moved down when it fetches commentary, requiring me to scroll down even on a 1080p screen. I would rather not let the commentary options get in the way of my tagging.

Updated

fossilnix said:

This is alarming. Is the "deleted posts aren't actually deleted" policy starting to catch up with us?

Deleted images only take up about 100GB of storage. The entire site is about 2.1TB and is growing at a rate of ~35GB per month. So deleted posts shouldn't be a significant factor.

DeusExCalamus said:

Can the 'This picture has already been uploaded (DanbooruIDHere)' link be fixed so that it opens in the same tab instead of a new tab/window? Like the 'similar' image link, I mean.

Not sure what the standard behavior should be here. For myself, I like having it open up a new tab/window. Although to be fair, that could be just as easily done through a right-click.

However, whichever way it's changed, it should be standardized with the IQDB results. Currently, the DanbooruIDHere link opens in a new tab/window, whereas the IQDB one opens in the same tab/window.

BrokenEagle98 said:

Not sure what the standard behavior should be here. For myself, I like having it open up a new tab/window. Although to be fair, that could be just as easily done through a right-click.

However, whichever way it's changed, it should be standardized with the IQDB results. Currently, the DanbooruIDHere link opens in a new tab/window, whereas the IQDB one opens in the same tab/window.

I'd like them both to open in the same tab/window; basically the way the iqdb link works.

I found some of my saved search queries don't work.
For example, I saved the query "shiromanta", and there are certainly some posts uploaded with that tag just a few days ago, but my search:all result does not contain any of them.

What kind of information should I provide you to investigate this issue?

Would it be possible to implement how often any tag has been searched in x days and that aren't in the top 100 (I think you can search for those).

But for example, if the car tag doesn't appear in the top 100, it would still be nice to know how often it were searched.

regarding the recent topic #14734 , noticed that there were some leftover posts (about 20+) that the batch process failed to execute particularly on sakura_saber_(cosplay) and assassin_of_black_(cosplay).

the result is, despite the move to new tags, old char_(cosplay) tags remained together with the old char tags.

the old tags register an already post count of zero but this is not true. when we append "&raw=true" to the url and check the tag correction on the "fix" link the true count shows.

would suspect that's why the batch process proceeded on here but not here . i assume that on the latter was not a simple delayed job, done manually and outside intervention since the time difference of two day after the batch was initially ran.

would recommend that exact count checking be done automatically before batch processes are run.

did not check other mass updates.

ghostrigger said:

regarding the recent topic #14734 , noticed that there were some leftover posts (about 20+) that the batch process failed to execute particularly on sakura_saber_(cosplay) and assassin_of_black_(cosplay).

the result is, despite the move to new tags, old char_(cosplay) tags remained together with the old char tags.

the old tags register an already post count of zero but this is not true. when we append "&raw=true" to the url and check the tag correction on the "fix" link the true count shows.

would suspect that's why the batch process proceeded on here but not here . i assume that on the latter was not a simple delayed job, done manually and outside intervention since the time difference of two day after the batch was initially ran.

would recommend that exact count checking be done automatically before batch processes are run.

did not check other mass updates.

Already made a note of this in forum #126933, but never really created an issue on GitHub. I'll do so now.

Edit:

Created issue #3409.

Updated