Welcome to Wikimedia Commons, TheSandDoctor!

-- Wikimedia Commons Welcome (talk) 16:30, 23 January 2017 (UTC)

AutopatrollerEdit

Hi, I gave you the Autopatroller right. Regards, Yann (talk) 16:41, 12 January 2019 (UTC)

Hi Yann, I was not expecting that, thank you! May I ask why you did this? --TheSandDoctor (talk) 18:27, 12 January 2019 (UTC)
(talk page stalker) Hey, because you were triggering filters during renames. ‐‐1997kB (talk) 13:20, 13 January 2019 (UTC)

TheSandBotEdit

Hi. Is there any way you can have your bot mark its edits as "bot" edits? It has a bot flag, but is still showing up in recent changes, suggesting that it isn't using the flag. Thanks, --DannyS712 (talk) 04:21, 31 May 2019 (UTC)

@DannyS712: Queued the run in question for deletion on tools and started a patched one. My apologies, it appears that it was a copy and paste error that slipped through and was introduced from patching a memory leak. now fixed. Thank you again for bringing this up, I'm just glad I was around to fix it so quickly after notice. Thanks! --TheSandDoctor (talk) 04:26, 31 May 2019 (UTC)
No problem. Also, if you have a minute to talk about bots, would you mind checking out w:en:wp:Bots/Requests for approval/DannyS712 bot 44? It should only take a few minutes, its pretty straightforward. Thanks, --DannyS712 (talk) 04:27, 31 May 2019 (UTC)

Wrong editsEdit

There is something wrong with your bot. This picture was not taken in 2015. And lots of other similar edits. ~Cybularny Speak? 05:15, 31 May 2019 (UTC)

I wrote out a response, but not sure where it went. Anyways, you are quite right. Thank you very much for the report. There was an image 'stuck' that it was referencing against. How it got stuck was a typo resulting from repairing a memory leak, resulting in the temporary save of the new image not overwriting the old. The bot is now currently performing the edits and cleaning up after itself. Thanks so much for bringing this up, @Cybularny:. --TheSandDoctor (talk) 06:03, 31 May 2019 (UTC)

Same here. But as long it is eventually cleaned, its ok. --Arnd (talk) 07:19, 31 May 2019 (UTC)

@Aschroet: Special:Diff/352583015 done. --TheSandDoctor (talk) 12:51, 31 May 2019 (UTC)
  • Sorry to pile on, but this case of EXIF date miscorrection might be a different matter. As it seems, this JPEG file does not have any EXIF info we might gather a date from, either confirming or disproving the uploader’s statement on the filepage upon upload (@Geekdidi:). -- Tuválkin 19:28, 31 May 2019 (UTC)
@Tuvalkin: My apologies for the delayed response, I saw the email notification of your message much sooner but was unable to respond/edit until now. That is the same issue as above. Outside of the bot's aforementioned glitch, it only makes changes when "EXIF DateTimeOriginal" is present in the file metadata and disagrees with the value in Template:According to EXIF data. If the EXIF data simply did not exist, then TSB would favour the description page already present and move on without making an edit. By this same behaviour, it will also not automatically clean up after itself in this particular instance because it wouldnt see EXIF data and therefore favour whatever the description page said. In the near future, I will run a (non-editing) test to see how many were changed to read that date that do not have "EXIF DateTimeOriginal" present to hopefully catch these edge cases that it edited via the aforementioned bug and be able to resolve them. --TheSandDoctor (talk) 02:54, 1 June 2019 (UTC)
  • Thanks for reverting and good luck with the clean up bot run. Concerning this one photo, it was my fault, as I had kept the {{Exif date}} template for a JPEG without any EXIF. -- Tuválkin 12:59, 1 June 2019 (UTC)
  • @Tuvalkin: Don't worry. Under normal circumstances the bot would not have even made an edit in that case. The only reason it did was because of the bug mentioned above. I have taken steps to make sure that the code error does not happen in the future.
  • So far, the (non-editing) script looking at images which lack "EXIF DateTimeOriginal" and have Template:According to EXIF data containing 2015-10-30 has turned up nothing. Both scripts seem to have run into some corrupt metadata which stops them. I have most likely now patched this. However, since they both crash at what appears to be around the same point, that means that the image you originally mentioned might have been the only case where it edited without any metadata.   (Of course, I will keep looking to be sure.) --TheSandDoctor (talk) 16:30, 1 June 2019 (UTC)
  • @Tuvalkin: Around 550 others were discovered by the analysis and I have manually reverted the instances. I will run the (non-editing) analysis once more in a day or two to be sure that I haven't missed any. --TheSandDoctor (talk) 05:52, 3 June 2019 (UTC)

File:20170402 - Bangkinang city.jpgEdit

Why did you revert this? Bangkinang is in Riau province in 2017. Seems like a logical category to me. -- Ricky81682 (talk) 06:20, 3 June 2019 (UTC)

@Ricky81682: You are right. Reverting your edit was accidental, what I meant to do was to revert TheSandBot (see above section) as it had made an error on the page. I have reverted my revert of your edit (diff) and performed the proper revert of my bot (diff). My apologies. --TheSandDoctor (talk) 12:53, 3 June 2019 (UTC)
No worries. Thanks! -- Ricky81682 (talk) 01:30, 4 June 2019 (UTC)

File:135 Militkasko .svgEdit

Respeite a língua usada pelo carregador. Você propôs alteração misturando duas linguas: Esperanto (original) e inglês. Eugenio Hansen, OFS (talk) 09:57, 21 July 2019 (UTC)

minhas sinceras desculpas, Eugenio Hansen, OFS. Terei mais cuidado na próxima vez. --TheSandDoctor (talk) 16:53, 21 July 2019 (UTC)

Welcome, Dear Patroller!Edit

Hi TheSandDoctor,

You now have the Patroller right and may call yourself a patroller! Please take a moment to read the updated Commons:Patrol to learn how Patrolling works and how we use it to fight vandalism.

As you know already, the patrolling functionality is enabled for all edits, not just for new-page creations. This enables us to keep track of, for example, edits made by anonymous users here on Commons.

We could use your help at the Counter Vandalism Unit. For example by patrolling an Anonymous-edits checklist and checking a day-part.

If you have any questions please leave a message on the CVU talkpage or ask for help on IRC in #wikimedia-commons.


English | español | മലയാളം | +/−

-- ~riley (talk) 06:55, 4 November 2019 (UTC)

Important message for file moversEdit

A community discussion has been closed where the consensus was to grant all file movers the suppressredirect user right. This will allow file movers to not leave behind a redirect when moving files and instead automatically have the original file name deleted. Policy never requires you to suppress the redirect, suppression of redirects is entirely optional.

Possible acceptable uses of this ability:

  • To move recently uploaded files with an obvious error in the file name where that error would not be a reasonable redirect. For example: moving "Sheep in a tree.jpg" to "Squirrel in a tree.jpg" when the image does in fact depict a squirrel.
  • To perform file name swaps.
  • When the original file name contains vandalism. (File renaming criterion #5)

Please note, this ability should be used only in certain circumstances and only if you are absolutely sure that it is not going to break the display of the file on any project. Redirects should never be suppressed if the file is in use on any project. When in doubt, leave a redirect. If you forget to suppress the redirect in case of file name vandalism or you are not fully certain if the original file name is actually vandalism, leave a redirect and tag the redirect for speedy deletion per G2.

The malicious or reckless breaking of file links via the suppressredirect user right is considered an abuse of the file mover right and is grounds for immediate revocation of that right. This message serves as both a notice that you have this right and as an official warning. Questions regarding this right should be directed to administrators. --Majora (talk) 21:36, 7 November 2019 (UTC)

Google Code-In 2019 is coming - please mentor some documentation tasks!Edit

Hello,

Google Code-In, Google-organized contest in which the Wikimedia Foundation participates, starts in a few weeks. This contest is about taking high school students into the world of opensource. I'm sending you this message because you recently edited a documentation page at Wikimedia Commons.

I would like to ask you to take part in Google Code-In as a mentor. That would mean to prepare at least one task (it can be documentation related, or something else - the other categories are Code, Design, Quality Assurance and Outreach) for the participants, and help the student to complete it. Please sign up at the contest page and send us your Google account address to google-code-in-admins@lists.wikimedia.org, so we can invite you in!

From my own experience, Google Code-In can be fun, you can make several new friends, attract new people to your wiki and make them part of your community.

If you have any questions, please let us know at google-code-in-admins@lists.wikimedia.org.

Thank you!

--User:Martin Urbanec (talk) 22:05, 23 November 2019 (UTC)


Congratulations, dear license reviewerEdit

 
If you use the helper scripts, you will find the links next to the search box (vector) or as single tabs (monobook). They are named license+ and license-.

Hi TheSandDoctor, thanks for your request for license reviewer status. The request has been closed as successful, and you've been added to the list of reviewers. You can now start reviewing files – please see Commons:License review and Commons:Flickr files if you haven't done so already. We also have a guide how to detect copyright violations. Potential backlogs include Flickr review and files from other sources. You can use one of the following scripts by adding one of the lines to your common.js:

mw.loader.load('//commons.wikimedia.org/w/index.php?title=User:ZooFari/licensereviewer.js&action=raw&ctype=text/javascript'); // stable script for reviewing images from any kind of source OR
mw.loader.load('//commons.wikimedia.org/w/index.php?title=User:Majora/LicenseReview.js&action=raw&ctype=text/javascript'); // contains also user notification when review fails, auto blacklist-check and auto-thank you message for Flickr-reviews.

Important: thou shalt not review thy own uploads, nor those of anyone closely related to you!

Please feel free to join us on IRC: #wikimedia-commons webchat on irc.freenode.net. You can also add {{User license reviewer}} to your user page if you wish. Thank you for your contributions on Commons! Minoraxtalk (formerly 大诺史) 03:09, 15 January 2020 (UTC)

Corrupt images?Edit

Hi SandDoctor, your bot identified 3 images i uploaded as corrupt. Could you tell me why, because they look oke? Regards, Mr.Nostalgic (talk) 12:37, 8 February 2020 (UTC)

example = File:Handschoenen (paar) en beschrijving op papier. objectnr KA 15684.13.tif
  • @Mr.Nostalgic: My local system agrees with you, but for some reason when the same code runs on the server it flags it as corrupt. I am investigating. Don't worry, I made sure that it won't nominate your three images. You can see the ticket here I created tracking this if curious. This was a trial run that has now concluded. Thank you very much for coming to me with this. --TheSandDoctor (talk) 18:08, 8 February 2020 (UTC)
Thanks! I was not worried. I know you have good intentions and i actualy experienced the message as quit friendly. Mr.Nostalgic (talk) 19:10, 8 February 2020 (UTC)
@Mr.Nostalgic: I ran it again after updating the server and it now correctly identifies the images you uploaded as not being corrupt. I have also manually updated their database entries to reflect this and reverted the bot's related edits. My apologies for this. I am glad that you found the message quite friendly, that was the intent  . --TheSandDoctor (talk) 19:44, 8 February 2020 (UTC)
Thank you and keep up the good work. Regards, Mr.Nostalgic (talk) 20:42, 8 February 2020 (UTC)
And also:
I can understand the last one as the first version was corrupted and I uploaded new file. But can't understand the others. -- Geagea (talk) 06:12, 13 February 2020 (UTC)
@Geagea: Thanks for reaching out! I have ran a couple of tests (results here) and it appears that the first two JPG images are truncated, meaning that the bytes in the file end prematurely/incorrectly. For the first image, it appears to be between 41 bytes and 45 bytes early. In the case of the second, 5 bytes early. These errors I don't think are necessarily noticeable (at least in this particular instance), but essentially means that part of the file is missing. I hope that this helps! Perhaps try uploading again and I can take a look? --TheSandDoctor (talk) 06:45, 13 February 2020 (UTC)
I have uploaded new versions.
Anyway, The 2 first files and also File:PikiWiki Israel 61786 historic site.jpg comes from the The National Photo Collection of Israel. There are thousands of files from this site.
But I think this template is not appropriate. Even if the file is missing 45 bytes it have educational value. This so called "corrupted file" have non visual corruption. I don't think that there is a need to notify for speedy deletion. Adding template to the file says someting like: "this file is corrupted: missing 45 bytes" is ok. -- Geagea (talk) 08:43, 13 February 2020 (UTC)
@Geagea: Unfortunately, telling what is visible corruption to a user/person is not something that is most likely possible for a system to accurately do. Determining what byte threshold should be missing before calling an image corrupt would also be rather arbitrary as it would be a case-by-case thing. Two images could both have 45 bytes missing and, depending where they are, logically there could be vastly different implications for visibility.
Perhaps another approach would be to modify the template message making it more informative and add the ability for users to manually say that the image isn't visibly corrupt? I am not too sure. Ultimately, the failsafe currently in place here is the fact that the bot does not delete images, rather, it nominates them for deletion. As such, human administrators then review them. If it doesn't make sense, they can remove the tag and opt not to take any further action. What I am thinking of doing is adding a parameter of something like "|checked=" where it could then be updated rather than removal.
Anyways, I agree that the template needs work and at current the nomination part of the task is not active because of this. I will be manually reviewing flagged/tagged images for the time being and looking at reports brought to me as well. --TheSandDoctor (talk) 20:04, 13 February 2020 (UTC)

Hello, also one of images I uploaded was indentified as corrupt by the bot. It was corrupt, in fact, but only the original upload while as soon as I noticed, I re-uploaded the image and it seems ok now. The new version was, however, tagged as corrupt. Could you review it? Thanks. Andrzej Otrębski (talk) 18:03, 13 February 2020 (UTC)

Hello Andrzej O. Thank you for reaching out. I have manually checked the image on both my local machine and the server. Both are showing the image as not being corrupt (logs). What I suspect happened was that it was stuck in the queue of images to process (collected from recent changes) and it had the first version cached as a result. I have updated the database and will remove the template once I have the diff of this edit to point to in the summary. Nothing further is needed on your part. I shall have to update the template that is left on file pages to make it more descriptive/helpful. --TheSandDoctor (talk) 19:51, 13 February 2020 (UTC)
Appreciated :) Andrzej Otrębski (talk) 21:10, 13 February 2020 (UTC)

Sandbot EXIF datesEdit

Hi. I just spotted that your bot has a task to set dates based on EXIF data. Yesterday, I came across File:Queen Anne Mansion.jpg with an EXIF date of 2216 (someone must have had an odd date set on their camera). I've changed the date to "Otherdate before 2014" (date of upload to Commons). Your bot hasn't encountered it yet but I wondered if there is anything I need to do to make sure a bot doesn't revert to the future date. Thanks. From Hill To Shore (talk) 21:35, 14 February 2020 (UTC)

@From Hill To Shore: Not to worry! The task was a one-time run basically because the Android app at one point gave everything uploaded the wrong EXIF date. The task has long since completed. That does remind me though that I need to update the userpage....Thanks! --TheSandDoctor (talk) 22:02, 14 February 2020 (UTC)
@From Hill To Shore: Updated userpage. Thanks for the heads up/reminder.   --TheSandDoctor (talk) 22:13, 14 February 2020 (UTC)

File:"Looking downstream into upper cofferdam excavation. Dike and constricted river channel at left." - NARA - 293750.jpgEdit

This and this doesn't feel very helpful. Yes, a bit at the bottom seems to be broken, but having a bot put a speedy deletion threat on the file and editing a redirect page is counterproductive. Looking at Category:TSB identified corrupt I see that most files don't qualify for speedy deletion and judging from the deleted edits, no files have been deleted in the past. Probably better to stop this job and revert all the edits. Multichill (talk) 15:24, 15 February 2020 (UTC)

@Multichill: it is operating as intended per the bot request and request for approval (and templates approved). This has been approved since December but only started in earnest since last weekend. It has scanned over 200,000 files and only found 19 corrupt ones, or about 0.0095‬% of files in its current sample size. That is extremely low and as expected as most images on commons are not corrupt. As for why it has not nominated any as of yet is because I am not currently running that part of the program; I plan to check by hand at the moment. It is the responsibility of an admin to review that the file is indeed corrupt and requires deletion.
As for it tagging a redirect: that is indeed odd, but otherwise everything it has tagged does indeed appear to meet the definition of F7 -- the files are indeed corrupt. I have created a task for that and have implemented the check to ensure it does not edit/scan redirects. Thank you for mentioning that. --TheSandDoctor (talk) 18:46, 15 February 2020 (UTC)
  • OK. @Multichill, Fae: How about we run this in tag only mode (which it is currently) & I temporarily modify the templates to indicate that the files will not be nominated for deletion. Then we take this to a community RfC regarding nominating for deletion, speedy or otherwise. How does that sound? --TheSandDoctor (talk) 19:15, 15 February 2020 (UTC)
It's good that you tag slightly corrupt files to flag that, just the whole speedy deletion part is complete nonsense and not in line with the deletion policy. It's all about the visual part. You can see that only a bit at the bottom is missing. What's the point in deleting this files? If you really think this is covered by the deletion policy, than you're editing on the wrong project. This is Commons, not the English Wikipedia. Common sense still works here and is not overruled by wikilawyering. You can start your RFC's on the English Wikipedia, that stuff doesn't really work out here. Multichill (talk) 19:55, 15 February 2020 (UTC)
  • @Multichill, Fae: Some time ago now I toned down the wording of the templates and the bot will not (nor has it ever) nominated an image for deletion. The followup script has been repurposed for the sole purpose of checking to see if images are fixed (thus updating database/removing the tag). In the event that they are still corrupt, it does nothing. Thank you both for your input. --TheSandDoctor (talk) 06:27, 26 March 2020 (UTC)
Thanks for providing this useful service. Multichill (talk) 17:08, 26 March 2020 (UTC)

Image identified as corrupt. Looks fine(?)Edit

This image here and here was indicated by the bot as corrupt. Need an admin to check. Ominae (talk) 05:51, 26 March 2020 (UTC)

@Ominae: The images are missing some non-visible bytes of information. This can be "fixed" by re-encoding them, but for some reason I seem to be running into a glitch lately where I am unable to do it myself (as in I fix it locally, verify it is fixed, upload it, download it to check & magically corrupt in the same way...). I am investigating that issue on my end, but bottom line is that the images are indeed missing some bytes. Just not sure why I am unable to fix them on my machine... --TheSandDoctor (talk) 06:36, 26 March 2020 (UTC)
I see. Ominae (talk) 06:38, 26 March 2020 (UTC)
@TheSandDoctor: Should I just try to reupload the other "corrupt" image again? Noted that you reuploaded the first one. Ominae (talk) 13:07, 27 March 2020 (UTC)
@Ominae: You can certainly try re-uploading them as that may work, assuming that you have the original files still. JPG files are more likely than others to corrupt during upload. The glitch I was talking about appears to have happened with the new version I uploaded, so try both perhaps? --TheSandDoctor (talk) 17:09, 27 March 2020 (UTC)
@TheSandDoctor: Tried to upload said file again. Not sure if the bot will recognize it as corrupt. Ominae (talk) 05:34, 28 March 2020 (UTC)

Template editor givenEdit

Hello. I just wanted to let you know that I have granted template editor right to your account; the reason for this is that I believe you are sufficiently trustworthy and experienced to work with templates. Please consider enabling two-factor authentication for your account. Furthermore, please look at Category:Commons protected edit requests (template protected) occasionally and try to help your fellow Commoners with responding to their edit requests. Thank you.

~riley (talk) 03:32, 2 April 2020 (UTC)

File:03-07-dagebuell-by-RalfR-129.tifEdit

Hi TheSandDoctor, why was this image by Ralf Roletschek tagged as being corrupt? Regards, AFBorchert (talk) 10:24, 21 April 2020 (UTC)

@AFBorchert: TSB sees it as corrupt, but I had it confirmed by AntiCompositeNumber that it is not. I have updated my scripts so that they avoid tif images from here on out and treat them as non-images (basically a "do nothing" operation). My apologies. --TheSandDoctor (talk) 17:15, 21 April 2020 (UTC)
Hi TheSandDoctor, thank you, this is appreciated! BTW, as this message popped up on the talk page of a user who doesn't speak English, I've provided a German translation for it. But there is a problem. The time until the file is reexamined again is specified as “30 days”. I am not aware of a template which translates this to “30 Tagen” (or “30 Tage” in dependence of the grammatical context). It would be simpler if this could be changed to a numerical value without text i.e. without the “days” suffix) or if you would specify it absolutely in {{ISOdate}} format. Regards, AFBorchert (talk) 18:45, 21 April 2020 (UTC)

again: "Image identified as corrupt"Edit

Dear bot operator,

What is the exact problem here. Why are users threatened with sd, I find it a bit harsh.

Next problem: As ordered, I tried to perform a re-upload. Reason for re-upload: Your message "This image has been automatically identified as corrupt by TheSandBot. Please re-upload and this will be scanned by TheSandBot again." Result: no luck (message: "The upload is an exact duplicate of the current version of File:GER — BY — München — Hansastraße 19 (ADAC-Zentrale) 2020.JPG." Further action: Another fresh upload with another file name.

You're system is bonding a lot of extra precious time. --Mateus2019 (talk) 14:25, 1 May 2020 (UTC)

Hello Mateus2019, you actually are the first to discover/experience this specific error in its over 2.2 million files scanned. That has been corrected and will not re-occur. I have also updated the image in the bot's internal database. Typically when there is no visible corruption, it means that the file has lost its "end" tags and needs to be re-encoded.
Regarding the rest of your message, I fail to see how "If it is still corrupt at that time, then the file may be nominated for deletion. This is most likely to happen when a substantial portion of the image is corrupt." is threatening. What that means in practice is that if over 50% of the image is visibly corrupt, it may be nominated for deletion on a case-by-case basis as at that point its value may be in question. Images without visible corruption will not receive this treatment.
"You're system is bonding a lot of extra precious time." You are corrent in this one instance that it was a software fault, and I do apologize for that. Speaking generally, however, re-uploading a file that was corrupted during upload is hardly a waste of time. The worst corrupt images that the bot has encountered that were unrecoverable and the uploader took no action were indeed nominated for speedy deletion and deleted, but that is because either over 50% of the image was corrupt and/or the primary subject of the picture was entirely corrupted out. --TheSandDoctor (talk) 16:42, 1 May 2020 (UTC)
accepted. So just inclomplete image data is the issue during the upload process. The old one can be deleted now. Anyhow, thanks for your information and best wishes from Germany, --Mateus2019 (talk) 16:55, 1 May 2020 (UTC)

TheSandBot false positiveEdit

Your bot marked File:Track near Tobelbach 2020-03-11 16.jpg as corrupt. As the file and metadata looking okay and the downloaded file has the same hashes as the original file it themes to be a false positive. --GPSLeo (talk) 15:32, 3 May 2020 (UTC)

@GPSLeo: It has "f7xnvacfkivafer58h6whi8ezdqydca" stored as the image hash value, which is clearly incorrect per the page information. This requires further investigation. --TheSandDoctor (talk) 16:36, 3 May 2020 (UTC)
What image hash do you mean? --GPSLeo (talk) 19:43, 3 May 2020 (UTC)