Posted under General
ultima said:
Doesn't seem to be working, if post #726510 (which was just posted) is any indication.
Also I'm baffled at how this could be the case because the code seems plain as day to me. Can anyone see what's wrong?
http://trac.donmai.us/browser/danbooru/trunk/lib/download.rb#L30
albert said:
Also I'm baffled at how this could be the case because the code seems plain as day to me. Can anyone see what's wrong?http://trac.donmai.us/browser/danbooru/trunk/lib/download.rb#L30
It works fine if the user uploads from pixiv using the source field but doesn't work if the user saves the image to their hdd and uploads it, replacing the source afterwords. I just tested it with post #730388.
Log said:
Nothing can be done with bad id images they are just ones the artists deleted from pixiv.
Yeah, another few thousand every month...
Well, the scan eventually finished, adding/removing those three tags to all the pixiv sources with max dimension 150/600 as appropriate. A daily scan checks over the last two days or so. MD5 mismatches could be anything from minute edits to completely wrong sources. At least one user just blanked the source after getting an auto-notice about it...
Updated
albert said:
Also I'm baffled at how this could be the case because the code seems plain as day to me. Can anyone see what's wrong?
Well I can't be 100% certain if there was a source given or not since the image has been fully deleted now, but it's probably like Log said and someone just saved the medium thumbnail to their HDD then uploaded it.
There was, it was sourced to the medium, I checked it after you linked it originally.
RaisingK said:
MD5 mismatches could be anything from minute edits to completely wrong sources. At least one user just blanked the source after getting an auto-notice about it...
I would assume these would be things uploaded from a third-party source, be it an official blog or an imagebord, run through saucenao, and the resulting location set as source.
albert said:
Also I'm baffled at how this could be the case because the code seems plain as day to me. Can anyone see what's wrong?
Like what Log said it seem to be working okay. The only problem is it only works for medium sized image links. It doesn't work if someone accidentally uploaded a image link containing a "_s" in it.
Some important changes:
Did something happened earlier because now the tag history actually display the image's source link. Does this mean that the site will auto correct any Pixiv link so that the uploaded image is in it's fullest size?
Example: http://danbooru.donmai.us/post_tag_history/index?post_id=731399
albert said:
If you upload from source, the _m sized image should be corrected and the large image should be downloaded.
I think I remember uploading a _m sized image to see if the site would correct the link. Still good to know that it does.
I haven't done this for thumbnails
Oh yes, please do. That would do wonders for anyone who accidentally uploaded a thumbnail from pixiv and/or any other site. Is it easy for to create scripts like that?
This can't stop anyone from manually downloading the _m size image and uploading that.
Well that's a given and they no way of fixing that short of taking away the ability to manually uploading images from your hard drive but I can assume that would be a bad thing to do.
Log said:
How exactly do you upload a 150 or less pixel image "accidentally" I don't understand that at all, doubly so for pixiv.
Well how does one post a _m sized picture without at least first clicking on said image to see if it's bigger than what they see? Anyway to answer your question it has to do with Google Chrome and it's ability to open images on new tabs.
Updated
I found and I believe I've fixed a major bug with aliases where the cache wasn't being properly expired. I also ran a script to go through every alias and make sure there aren't any inconsistencies.
I'm also running a script to fix a bunch of Pixiv uploads where either the medium-sized version was uploaded or the MD5 mismatches for whatever reason.
albert said:
I'm also running a script to fix a bunch of Pixiv uploads where either the medium-sized version was uploaded or the MD5 mismatches for whatever reason.
So what was the fix? The caching is a bit out of whack right now. The tag count for pixiv thumbnail is -91, pixiv_thumbnail has one page of results, and pixiv_thumbnail -asdfasdf has three (before a bunch more were purged, at least).
And how does the script fix the md5 mismatch posts? Don't those have to be verified manually?
Updated
Log said:
How exactly do you upload a 150 or less pixel image "accidentally" I don't understand that at all, doubly so for pixiv.
I can answer that as I've done it. I was checking through my watched artists on Pixiv to see if they were all here and up-to-date. Quickest way was to find their name as used here was using danbooruup and searching danbooru to see what the most recent post is, and it was quickest to run danbooruup on a thumbnail then cancel the dialog - until I accidentally hit enter.
wanchan said:
Quickest way was to find their name as used here was using danbooruup and searching danbooru to see what the most recent post is, and it was quickest to run danbooruup on a thumbnail then cancel the dialog
It'd probably be easier and faster to query the similarity search, there's a firefox plugin for it somewhere. Just right-click the thumbnail, query on iqdb, and if you don't see it on danbooru post away (unless it was posted there in the few minutes since the last iqdb update).
piespy said:
It'd probably be easier and faster to query the similarity search, there's a firefox plugin for it somewhere.
Yeah, the saucenao extension. My Greasemonkey scripts for pixiv all link to the search in some fashion, but the extension is the simplest.
