Posted under General
This topic has been locked.
humrh2 said:
Anyone still having a problem with pics giving the sample? Still getting it on my end.
I'm getting it in post #1557779
Getting it everytime I reload too. Resize does not work.
[EDIT] Scratch that, I'm also getting it for
Updated
I thought so. I'm getting this for the majority (if not the entirety) of approved pics with a resolution past a certain point. The "shrunken sample" effect is even more gratuitous on the wide images like post #332556
topic #10028, guys.
fukuyama-san_(character) has no related tags, I thought it might be a time issue but it was created 12 hours ago at this point so I'm not so sure about that now.
it appears that a non-existing record is causing the problem: post #1380370 in the 13th page.
there seems to be bugs involving usages with ~user:(insert username here)
I don't know the exact specific, but for instance, this one refuses to show result but this does so it's not clearly user issue.
in normal condition, it's supposed to show them, one tag or two. After all, other tags, such as ~pool: show up fine. (example 1, using two ~pool: tags, example 2, using two ~general tags )
Updated
Under the current parsing code, or-searches (those with a ~ in them) normally don't work with metatags (like user:, for instance).
The only exceptions to this are pool:<pool_id_here> and fav:<user_id_here>, which are special. All other metatags will be parsed as normal tags; that is, "~user:cyberwire" will look for the tag literally named "user:cyberwire", which of course does not exist.
Toks said:
Under the current parsing code, or-searches (those with a ~ in them) normally don't work with metatags (like user:, for instance).
The only exceptions to this are pool:<pool_id_here> and fav:<user_id_here>, which are special. All other metatags will be parsed as normal tags; that is, "~user:cyberwire" will look for the tag literally named "user:cyberwire", which of course does not exist.
I hate to sound like I'm pulling your leg here, but it was working somehow. Well, forget about that, though. Fact that it doesn't work right now is what's important.
Is there any way we can have it work?
FoolyDooly said:
I hate to sound like I'm pulling your leg here, but it was working somehow. Well, forget about that, though. Fact that it doesn't work right now is what's important.
Do you mean way back in Danbooru 1? I suppose it's possible, though it seems strange that it wouldn't work now in Danbooru 2.
FoolyDooly said:
Is there any way we can have it work?
I don't think it can be done easily. The current tag parsing code ORs normal tags together when doing an or-search, without regard for other parts of the query like metatags. Making it work would probably require rewriting it to allow ORing together any part of the query. But I'm not inclined to rewrite core parts of the site's code without good reason. I'd probably break something or make it perform poorly.
The only exceptions would be pool:<name> and fav:<name>. Since pool:<id> and fav:<id> already work for or-searches, making them work for names too shouldn't be that difficult.
Toks said:
I don't think it can be done easily. The current tag parsing code ORs normal tags together when doing an or-search, without regard for other parts of the query like metatags. Making it work would probably require rewriting it to allow ORing together any part of the query. But I'm not inclined to rewrite core parts of the site's code without good reason. I'd probably break something or make it perform poorly.
The only exceptions would be pool:<name> and fav:<name>. Since pool:<id> and fav:<id> already work for or-searches, making them work for names too shouldn't be that difficult.
Yeah, that code doesn't seem to be set up yet. Doing searches via user:<id> just takes me to front page of the posts
Any way I can help with fixing this?
FoolyDooly said:
Yeah, that code doesn't seem to be set up yet. Doing searches via user:<id> just takes me to front page of the posts
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.
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.
