User talk:Bawolff
Archives somewhere in history
Scalable Vector Graphics (SVG)
[edit]In other languages (translate this) |
---|
|
Thank you for uploading some images!
Did you know that Wikimedia Commons recommends the SVG (Scalable Vector Graphics) format for certain types of images? Scalable Vector Graphics are designed to look appropriate at any scale, and SVG images are easier to modify and translate, helping Wikimedia to distribute knowledge to all of the world. A lot of modern programs support SVG export. If you encountered problems or have questions, don't hesitate to ask me, a member of the Graphic Lab, or the Graphics village pump. Uploading images in SVG format isn't mandatory, but it would help. (To avoid any misunderstandings, please don't just put raster images into an SVG container as embedded raster.) Thanks, and happy editing!
|
Thanks a lot for the efforts in fixing "my bug" :) -- RE rillke questions? 17:22, 21 June 2011 (UTC)
Gadget Update: UserMessages
[edit]Hi Brian!
Thanks for testing and using AxUserMsg.js . This is essentially important for developers and highly appreciated. The script is now available in your preferences. This will also speed-up page loading.
Please remove the line importScript("User:Rillke/AxUserMsg.js")
from your common.js before activating the ordinary gadget.
If you have questions, don't hesitate to ask me or put them here. Even if you dislike a new feature.
Thank you! -- RE rillke questions? 13:04, 6 December 2011 (UTC)
I'm get pushing around ...
[edit]Another guy, another try :-)
Please have look at Commons:Village_pump#Maintaining_.28and_thus_editing.29_SVGs.27_text_like_wiki_articles. Now 2 weeks are gone and I got no constructive feedback from any responsible admin, not to mention a developper (from bugzilla?). Thus I like to repeat my still unanswered question: Whom must I contact on (commons-)wikimedia, or to which sub-community of wikipedia must I go to explain my wish / demand / proposal of this to get an expert peer-reviewing and a realization hopefully. User:Rillke suggested that I should ask you. Achim1999 (talk) 15:49, 22 June 2012 (UTC)
Replied at VPT
[edit][1] sorry for the delay. - The Bushranger (talk) 09:45, 3 February 2013 (UTC)
Gallery redesign feedback
[edit]See also: http://lists.wikimedia.org/pipermail/commons-l/2013-June/thread.html
- When developing tools I found the feedback given by Jean-Frédéric, LX and Rd232 very helpful.
- I like that it works without JavaScript enabled. All variants will have their use case.
- It would be preferable, if the user can switch the view in categories (e.g. showing all captions)
- Is it possible to include the file name as a HTML5 data attribute? This would make it easier for third party tools to extract it instead of doing fancy things with the a[href] attribute or the img[src] attribute.
- Will the No lines example work as expected in RTL languages?
- How many feedback would you like to get? Should I issue a Watchlist Notice?
-- Rillke(q?) 16:37, 14 June 2013 (UTC)
The redisign should not replace the current design. There should be an attribute to control the design, for example <gallery style="noLines">
. --80.149.113.234 05:22, 17 June 2013 (UTC)
- If you look at the example's source code, you'll see that exactly this is done there. -- Rillke(q?) 08:28, 17 June 2013 (UTC)
- I assume the current "standard" should be kept as a standard (without the need to specify any parameters). Otherwise this will mess up backwards compatibility. --Patrick87 (talk) 11:04, 17 June 2013 (UTC)
- The image description text should not be bold by default. The possibility to format the text freely should remain. Regards, --IW 17:45, 17 June 2013 (UTC)
Did you know Help:QuickDelete?
[edit]This is a gadget which works exactly like the Nominate for deletion thing; it just also supports tagging copyright violations. -- Rillke(q?) 09:27, 27 June 2013 (UTC)
Re: Why both TIFF and JPG?
[edit]On why some of our most prolific batch uploaders upload both versions, the reason is mainly that many archive/GLAM people adore lossless TIFF format; more modern people may instead like lossless PNGs. However, most actual users want JPG versions; this need is surely alleviated by recent thumbnailing improvements, but possibly not eliminated. --Nemo 08:21, 12 September 2013 (UTC)
Help purging one djvu thumbnail
[edit]Hi, Bawolff. I'm trying to refresh one thumbnail and I can't do it. I've been trying all the actions described at Help pages, since some months ago, but they don't work in this specific page. Other times they worked OK in other DjVu pages by adding the "?action=purge". I ask you for help because of the message at Help talk:Purge#Alternative to advanced purge. Any help is appreciated.
The image is https://upload.wikimedia.org/wikipedia/commons/thumb/b/b3/Llegendas_catalanas_%281881%29.djvu/page201-1000px-Llegendas_catalanas_%281881%29.djvu.jpg . This 1000px old version is wrong if it beings with "trició".
The newest version begins with "ulls". You can see it at any other resolution (e.g. 800px: https://upload.wikimedia.org/wikipedia/commons/thumb/b/b3/Llegendas_catalanas_%281881%29.djvu/page201-800px-Llegendas_catalanas_%281881%29.djvu.jpg).
Because of this, it's not the same https://ca.wikisource.org/w/index.php?title=P%C3%A0gina:Llegendas_catalanas_%281881%29.djvu/201&action=edit than https://ca.wikisource.org/wiki/P%C3%A0gina:Llegendas_catalanas_%281881%29.djvu/201 .
It's not urgent. I hope it's not a bugg.
Thanks a lot for your time! -Aleator (talk) 17:11, 20 September 2013 (UTC)
- Done (I think). Bawolff (talk) 01:40, 26 September 2013 (UTC)
- It works! :O Thanks a lot :) -Aleator (talk) 22:09, 26 September 2013 (UTC)
TIFF handling in MediaWiki
[edit]Hi Brian. As the resident multimedia team member in our village pump discussion about the duplication of TIFF files, I thought maybe we could get into the weeds a bit more about some of the software issues at play in handling TIFFs. There seem to be two main simple problems.
- It would be incredibly helpful if the "Size of this preview:" under the image and the Stockphoto "Download" link in the bar at the top can't give an option for full resolution in JPG.
- The current behavior when you click the image from the description pages is not ideal. Normally it gives you the full resolution image, but for TIFFs, it starts a download, usually of a very large file. I think the ideal behavior is either to serve the user a full resolution JPG version of the TIFF, or to give a pop up like the "download" button showing them the options.
What are your thoughts on the likelihood of either of those happening? I'm also interested in learning more about the sharpness issue—is that a deep technical problem? Please let me know if there is something on Bugzilla about it. (I found [2], which seems possible related?) Dominic (talk) 17:34, 27 September 2013 (UTC)
- Actually, whether the click on the image starts a download or shows the image right in the browser, depends on the browser. Firefox really does start a download, while Safari displays the TIFF in the browser. I would say that a click on the image from the description page, except on videos, generally means "download the full file with all the information that is there", and that's also what's done e.g. with PDFs. My opinion is that the way browsers handle certain formats is a matter for browser developers to fix - we didn't e.g. make the click on an SVG file link to a full-size PNG when SVG wasn't yet widely supported. However, a link to a full resolution JPEG would indeed be helpful. darkweasel94 18:16, 28 September 2013 (UTC)
Following up on some of the interface-related issues we explored, I'm wondering what you think of bugzilla:56546, bugzilla:56508, and bugzilla:53017 (see my last comment, especially). I think sorts of changes would clarify things on the image description pages a lot, and seem fairly uncontroversial to me. I'm also curious if you have news about the fate of gerrit:86387. I don't know much about how code review happens; Is it just sitting and waiting for someone to come along? Dominic (talk) 07:04, 4 November 2013 (UTC)
- For code review that's basically how it works (combined with bothering people until someone gets tired of you and reviews your contribution). Sometimes it can be hard to get reviews, especially for volunteers working in less popular areas of the codebase. I've been a bit busy in real life, so haven't had a chance to be as pushy about that change as I could have been. 56546 sounds reasonable to me (hardest part might be getting the proper name of the file format, but could probably just use extension). The other 2 seem to be straightforward small changes that would be good changes (all 3 seem like possible google code-in bugs). Cheers. Bawolff (talk) 17:43, 4 November 2013 (UTC)
- gerrit:86387 is merged now. The change will probably appear on commons on Tuesday November 19 (Attempt to get new-fangled echo notice thing to give Dominic a notice). Bawolff (talk) 16:32, 7 November 2013 (UTC)
- Echo succeeded. Thanks! :-) Dominic (talk) 18:03, 7 November 2013 (UTC)
- gerrit:86387 is merged now. The change will probably appear on commons on Tuesday November 19 (Attempt to get new-fangled echo notice thing to give Dominic a notice). Bawolff (talk) 16:32, 7 November 2013 (UTC)
Storage/Backend issues?
[edit]While monitoring the Rotatebot log I often come around images with storage issues; the first image revision is invalid but not completely broken as the second working image seems to gather wrong rotation info from it, so does Rotatebot and in the end the images gets rotated wrong. Deleting the file and restoring the first working image (usually the first but sometimes the second revision is shown as invalid) shows in most cases an image without rotation problem. Do you have an idea why this data corruption happens? Almost all of these image have the same storage time recorded, maximum one minute difference between the two. Example here. --Denniss (talk) 09:45, 28 September 2013 (UTC)
- I think its a race condition in the filebackend. Not really sure what's going on. I filed bugzilla:54736. Bawolff (talk) 15:37, 28 September 2013 (UTC)
FP promotion
[edit]Hi Bawolff,
Do you have any idea on the problem we are facing with the FPCBot? We discussed with many, including Dschwen and Fæ; but unable to sole it. I made a post at VP; but doesn't attract any response so far. It will be very helpful if you can give any suggestion at User_talk:Daniel78#Bot_doesn.27t_close_new_nominations. JKadavoor Jee 08:25, 19 October 2013 (UTC)
- Thanks, Bawolff; you have a message at User_talk:Daniel78#Bot_doesn.27t_close_new_nominations. JKadavoor Jee 17:43, 19 October 2013 (UTC)
- Glad to see you working on it. Thanks, JKadavoor Jee 02:48, 28 October 2013 (UTC)
- Hi; does the server side issue is over? Daniel restarted the bot as suggested by me and is working now. Since the moth is changed, file sizes are small now. I don't know the issues come later as the files grow. JKadavoor Jee 16:53, 4 November 2013 (UTC)
- my proposed change in that area has not yet been merged, so the situation hasn't changed in that regard. Bawolff (talk) 18:09, 4 November 2013 (UTC)
- Hi; does the server side issue is over? Daniel restarted the bot as suggested by me and is working now. Since the moth is changed, file sizes are small now. I don't know the issues come later as the files grow. JKadavoor Jee 16:53, 4 November 2013 (UTC)
File uploaded multiple time
[edit]Can you get a look at Commons:Administrators'_noticeboard#File_uploaded_multiple ? Move the talk at the right place if there is any. Phe (talk) 16:54, 20 November 2013 (UTC)
Title from file name
[edit]Hi Brian,
1.I see Media Viewer is using file name without extension as title of the work. How can I extract it similarly for my on attribution use in attribution field? I assume it can be achieved by some string functions and {{SUBPAGENAME}}.
2. Can I extract year from the date field of {{Information}}? It works for me for custom templates; but not when I use information template directly at File page. :(
3. The log file of COM:FPC still showing DATA READ TIMEOUT errors when grown beyond a limit. So I periodically move contents for a temporary file and restore when the month is over, for the smooth running of the bot. JKadavoor Jee 16:55, 3 December 2013 (UTC)
- Responded at your talk. Bawolff (talk) 00:44, 4 December 2013 (UTC)
Christmas greetings
[edit]Hey, I wish you a merry Christmas and a restful time. Moreover I want to thank you for your numerous contributions to the Software and Bug tracker, as well as your dedication to assist in technical problems and questions. I perceive your comments always as helpful and interesting so thank you very much! And finally I wish you a successful start into the new year! --McZusatz (talk) 10:16, 24 December 2013 (UTC)
- Thanks. A merry Christmas to you too. Bawolff (talk) 00:09, 25 December 2013 (UTC)
Please have a look at this if you have time. Some developer input needed, the task seems to be somewhat complicated. You may have a better idea to catch these dupes. --Denniss (talk) 22:21, 13 February 2014 (UTC)
Possible database quirks with some images
[edit]All non-deleted images at Commons:Database reports/Broken redirects (data as of 23:42, 27 February 2014 (UTC)) are repeatedly reported every day. All reported files in the list are redirects, either from moves or redirect creation after duplicate delete. Any idea what caused these reportings (apart from Bot error)? --Denniss (talk) 06:50, 28 February 2014 (UTC)
- Hmm, not sure. I ran the same query that I believe the bot is running ([3]), on labs, and it got 0 results. If the bot is running on toolserver, perhaps there's some corruption in the toolserver database (my ts account is expired so I can't really check that). Special:BrokenRedirects (Which is now being updated semi-regularly, still probably not as regularly as the bot) doesn't show those redirects either. Bawolff (talk) 07:19, 28 February 2014 (UTC)
Hello, Bawolff. You have new messages at XXN's talk page.
You may remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.
|
Images without a license
[edit]Hi since we were just talking about it. Here is an example of a novice uploader "loosing" a license during upload session: user talk:Jarekt#https:.2F.2Fcommons.wikimedia.org.2Fwiki.2FFile:Sea_Hill_Lighthouse._Curtis_Island.2C_Australia.2C_May_2011.jpg. Cheers --Jarekt (talk) 04:16, 3 June 2014 (UTC)
- Hi Jarekt. I traced that upload back to the w:Wikipedia:File_Upload_Wizard tool. I left a message at w:Wikipedia_talk:File_Upload_Wizard#uploads_to_commons_that_don.27t_have_any_license_info, so hopefully if there is a bug in that tool, that tools maintainers can figure it out. Bawolff (talk) 19:40, 3 June 2014 (UTC)
- Thanks --Jarekt (talk) 20:00, 3 June 2014 (UTC)
Do you know if there is an effective query (via DB or API) which returns all affected TimedTexts? TimedTextPage.php goes something like
// Check for File name with text extension ( from remaning parts of title ) // i.e TimedText:myfile.ogg.en.srt $videoTitle = Title::newFromText( implode('.', $titleParts ), NS_FILE ); // Check for remote file $basefile = wfFindFile( $videoTitle ); if ( !$basefile ) { $out->addHTML( wfMessage( 'timedmedia-subtitle-no-video' )->escaped() ); wfProfileOut( __METHOD__ ); return; }
but implementing this as reverse-search probably results in some kind of brute force algorithm. --McZusatz (talk) 13:53, 10 July 2014 (UTC)
- @McZusatz: :
MariaDB [commonswiki_p]> select page_title from page left outer join image on substr( page_title, 1, length( page_title ) - length( substring_index( page_title, '.' ,-2 ) ) - 1 ) = img_name where page_namespace =102 and img_name is null; +------------------------------------------------------------------------------------------------------------------+ | page_title | +------------------------------------------------------------------------------------------------------------------+ | 02_-_The_Cold_War_Era_1975_-_1989_(DARPA_history).ogv.darpa | | 051118-WSIS.2005-Richard.Stallman.ogg.en.srt | | 051118-WSIS.2005-Richard.Stallman.ogg.fi.srt | | 051118-WSIS.2005-Richard.Stallman.ogg.uk.srt | | 2008_08_26_01_01.webm.en.srt | | 2008_08_26_01_01.webm.ru.srt | | 2013_Brazilian_twerk.webm.en.srt | | 44_Scrooge,_or_Marley's_ghost_Robert_W_Paul,_1901.webm.ru.srt | | Amandine_Bourgeois_-_L'enfer_et_moi_presentation_(French).ogv.fr.srt | | Amandine_Bourgeois_-_L'enfer_et_moi_presentation_(French).ogv.sv.srt | | Anthem-of-Ukraine_Chorus_post2003.ogg.en.srt | | Anthem_of_Morocco.ar.ogg.srt | | Anthem_of_Morocco.ogg.ar.srt | | Anthem_of_Morocco.ogg.es.srt | | Anthem_of_Morocco.ogg.fr.srt | | Anthems_-_National_Anthem_Of_Jamaica.ogg | | Assembleia01.ogv.en.srt | | B-2_Spirit.ogv.en.srt | | Bibiana_spiega_quello_che_facciamo-YouTube.webmsd.webm.en.srt | | Bibiana_spiega_quello_che_facciamo-YouTube.webmsd.webm.es.srt | | Bill_Reeves,_Pixar,_1995,_on_rendering_algorithms,_raytracing_and_global_illumination.ogg.en.srt | | Bonnie_and_Clyde_death_scene.ogg.en.srt | | CB_School_Song_I.ogg.th.srt | | Closed_cap.af.srt | | Closed_cap.ml.srt | | Commons_h264_MVC_theora.ogv.en.srt | | Commons_h264_MVC_theora.ogv.es.srt | | Commons_h264_MVC_theora.ogv.it.srt | | Creative_Commons_-_Get_Creative.ogv.en.srt | | Creative_Commons_-_Get_Creative.ogv.ru.srt | | Dust_Models_Paint_Alien's_View_of_Solar_System.ogv | | Ellens_dritter_Gesang.ogg.en.srt | | Friedrich_Ludwig_Bauer_über_die_Enigma_-_Interview_von_1996_-_Maximilian_Schönherr.ogg.de-ch.srt | | Habemus_Papam_2013.ogg.it.srt | | Habemus_Papam_2013.ogg.la.srt | | Himno_al_Estado_de_Puebla.ogg.es.srt | | Himno_del_Colegio_Francisco_Arango.ogg | | Hoch_tut_euch_auf.ogg.de.srt | | Hoch_tut_euch_auf.ogg.en.srt | | Hoch_tut_euch_auf.ogg.eng.srt | | Hoch_tut_euch_auf.ogg.es.srt | | Hoch_tut_euch_auf.ogg.ger.srt | | J_P_Asher_voice_-_en.ogg.en.srt | | Jarry_(métro_de_Montréal).ogv.undefined.srt | | Jerry_Coyne_Voice.ogg | | Jimmy_Wales_by_Pricasso_(the_making_of).ogv.en.srt | | Lockheed_U-2.ogv.en.srt | | M_K_Gandhi.ogg.en.srt | | Mauritius_National_Anthem.ogg.en.srt | | Mongolian_National_Anthem_-_instrumental.ogg.en.srt | | Mongolian_National_Anthem_-_instrumental.ogg.mn.srt | | National_Flag_Anthem_of_Republic_of_China_(Chorus).ogg.zh-tw.srt | | Qaumi_Tarana_Instrumental.ogg.en.srt | | Russian_Anthem_chorus.ogg | | Section_2.1_Introduction_To_Small_Business_&_SBIR/STTR_(How_Small_Businesses_Work_With_DARPA)_(DARPA).ogv.en.srt | | Section_3.1_From_Research_To_Use_(SBIR/STTR_Transition_Overview)_(DARPA).ogv.en.srt | | Section_3.2_Addressing_Transition_Pathways_&_Risks_(SBIR/STTR_Transition_Overview)_(DARPA).ogv.en.srt | | Section_3.3_Transition_Planning_(SBIR/STTR_Transition_Overview)_(DARPA).ogv.en.srt | | Section_3.4_Communicating_Your_Innovation_To_Others_(SBIR/STTR_Transition_Overview)_(DARPA).ogv.en.srt | | Sri_Lanka_Matha.ogg.si.srt | | State_of_Wikipedia.ogv.en.srt | | State_of_Wikipedia.ogv.undefined.srt | | Steve_Jobs_on_computer_graphics_-_Interview_excerpt_from_1995.ogg.en.srt | | Taiwan(Republic_of_China)中華民國國歌.ogg.zh-hans.srt | | Taiwan(Republic_of_China)中華民國國歌.ogg.zh-hant.srt | | Test/webm.en.srt | | The_Impact_of_Wikipedia_-_Q_Mike_Cline.webm.en.srt | | The_Impact_of_Wikipedia_-_Srikeit_Tadepalli_and_Noopur_Raval.webm | | The_National_Anthem_of_the_People_Democratic_Republic_of_Korea.ogg.ko-kp.srt | | The_Spirit_of_'43.ogv.en.srt | | Truth_In_Numbers.ogv.en.srt | | Truth_In_Numbers.ogv.en.txt | | Truth_In_Numbers.ogv.es.srt | | Truth_In_Numbers.ogv.pl.srt | | Truth_In_Numbers.ogv.pt.srt | | Truth_In_Numbers.ogv.uk.srt | | Verifiability_and_Neutral_point_of_view_(Common_Craft)-600px-cy.ogv.en.srt | | Verifiability_and_Neutral_point_of_view_(Common_Craft)-600px-cy.ogv.srt | | Voice_of_Cory_Doctorow.ogg.de.srt | | Voice_of_Cory_Doctorow.ogg.en.srt | | WalesAnniversaryAddress.ogvka.srt | | What's_a_Love_Dart | | What's_a_Love_Dart?.webm | | What_are_the_factors_that_generate_poverty | | Wikimedia_Foundation_90_second_HR_Video_with_Disclaimer_720p.theora.ogv | | Yochai_Benkler_-_On_Autonomy,_Control_and_Cultureal_Experience.ogg.en.srt | | Yosemite_Nature_Notes_9:_Frazil_Ice.ogv.en.srt | | 郑璐_-_鄱阳湖之歌.OGG.zh-cn.srt | +------------------------------------------------------------------------------------------------------------------+ 88 rows in set (0.02 sec)
This could probably be turned into a special page. Bawolff (talk) 01:16, 11 July 2014 (UTC)
A barnstar for you!
[edit]The Original Barnstar | |
Thank you for your help! Natkabrown (talk) 10:16, 9 August 2014 (UTC) |
File:Dobrolet logo (Russian).png has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry.
If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. |
Fry1989 eh? 17:29, 20 September 2014 (UTC)
RfC of interest
[edit]I've started the Commons:Requests for comment/Hosting files for 3D models as you suggested. --Piotr Konieczny aka Prokonsul Piotrus Talk 06:50, 28 October 2014 (UTC)
Hi Brian,
I went ahead and drafted Help:Support of new file formats, based on a post you made on the VP recently. Do you think it is useful? Feel free to amend or make suggestions. :)
Cheers, Jean-Fred (talk) 18:39, 28 October 2014 (UTC)
- Looks good to me. Bawolff (talk) 23:43, 28 October 2014 (UTC)
dev help needed
[edit]Hi Bawolff, per your recent comments on VP I've got the impression that you belong to the "dev camp" and could be our community's contact to the devs, which is dearly missing. Could you eventually take a look as this small thread Commons:Administrators'_noticeboard#200x200_Pixel_images_that_are_99_MBytes_large and give your opinion about the possibility to implement a sort of automatic filter that screens all uploads, either at upload or shortly thereafter or another solution? Thanks. --Túrelio (talk) 08:43, 2 November 2014 (UTC)
(Un)known JPEG artefact
[edit]Hi, on the help desk a contributor found a workaround for a JPEG preview artefact. Just click DEL and don't answer if this is off topic for your sphere of interests. –Be..anyone (talk) 12:49, 17 November 2014 (UTC)
Not spam...
[edit]...when you added your tool on Commons:Video almost two months ago, but now I commented it out, because it is apparently AWOL at toollabs:bawolff/usedVideosCommons.htm? –Be..anyone (talk) 03:31, 14 February 2015 (UTC)
- @Be..anyone: ugh, I miss the stability of toolserver... Thanks for letting me know. It should be back now. I've taken the liberty of adding back the link. Bawolff (talk) 22:11, 17 February 2015 (UTC)
Shell project on Phabricator
[edit]Hi,
We recently archived the shell keyword-projects on Phabricator. We now mainly handle former shell requests directly in two component-projects, Wikimedia-Site-requests and Wikimedia-Extension-setup. --Dereckson (talk) 13:07, 14 May 2015 (UTC)
- Thanks. I wasn't aware of that. Bawolff (talk) 15:40, 14 May 2015 (UTC)
Error in metadata viewer
[edit]Hi BaWolff,
With regard to User:Slaunger's query here, you offered some EXIFtool advice. It seems that the fix he is applying loses the colour profile, which is essential for images to appear accurately coloured on browsers. For example, the two versions of File:Facade, Kollhoff Tower, Potsdamer Platz, Berlin, Germany, 2015-07-13-3381.jpg look very different in an internet browser if viewed on a wide-colour-gamut monitor (one is more saturated red than the other). [I have Firefox configured such that it does display both versions the same, but that is not a standard configuration]. I'm not very familiar with EXIFtool. Do you know how to use it to retain the colour profile when fixing the EXIF issues? -- Colin (talk) 19:51, 30 June 2015 (UTC)
- Hi Colin (and ping User:Slaunger for good measure). I didn't realize that would strip colour profiles (And it looks like that command strips a bunch of iptc data too). I guess exiftool should be told to only touch exif properties. You can modify the batch file from the VP to do that by doing:
C:\Tools\exiftool-9.93\exiftool.exe -TagsFromFile %1 -exif:all temp.mie
C:\Tools\exiftool-9.93\exiftool %1 -all=
C:\Tools\exiftool-9.93\exiftool -TagsFromFile temp.mie -exif:all %1
Bawolff (talk) 21:59, 30 June 2015 (UTC)
- Hi Bawolff, thank you for trying hard to help. I have modified my script as indicated above, but I still get the error that the embedded colour profile is not there, see File:Mangrove,_Petit-Canal,_Grande-Terre,_Guadeloupe,_2010-03-28-.jpg :-(. I have verified one extra time that the colour profile is there in the input file to the script by using Jeffrey Firedl's Exif Viewer. It would really be nice if that mediawiki error could be fixed soon. -- Slaunger (talk) 19:23, 1 July 2015 (UTC)
- Hi Bawolff. I ended up installing two Lightroom plugins from Jeffrey Friedl, and after doing that, the directly exported jpg renders fine in the mediawiki metadata viewer. (The example file above is not found in a fourth uploaded version where everything seems to be OK). -- Slaunger (talk) 20:46, 1 July 2015 (UTC)
- @Slaunger: Whoops, I copy and pasted the middle line of that script wrong, it should have been:
- Hi Bawolff. I ended up installing two Lightroom plugins from Jeffrey Friedl, and after doing that, the directly exported jpg renders fine in the mediawiki metadata viewer. (The example file above is not found in a fourth uploaded version where everything seems to be OK). -- Slaunger (talk) 20:46, 1 July 2015 (UTC)
C:\Tools\exiftool-9.93\exiftool.exe -TagsFromFile %1 -exif:all temp.mie
C:\Tools\exiftool-9.93\exiftool %1 -exif:all=
C:\Tools\exiftool-9.93\exiftool -TagsFromFile temp.mie -exif:all %1
Sorry. Bawolff (talk) 22:22, 1 July 2015 (UTC)
- That helped! Thanks . Now, if I am bored today, I can make correction updates to all the uploads I have done with the version of the script, which stripped the colour profile data.... -- Slaunger (talk) 08:40, 4 July 2015 (UTC)
Show/hide
[edit]Hi. Could you pay attention to it. This error is not corrected. --Дагиров Умар (talk) 14:47, 14 September 2015 (UTC)
- Sorry, but I'm probably not going to be fixing that bug (Too much to do, and that bug is somewhat out of my interest area, and non-critical). You could try maybe getting the design people interested in it by emailing the design-l mailing list. Bawolff (talk) 12:32, 17 September 2015 (UTC)
Large job queue increase, category updates etc. very slow
[edit]Bawolff, I noticed your comment on phabricator: "{{Information}} contains {{Years since}} which calls {{CURRENTYEAR}}
. So almost all pages on commons are considered to have dynamic content. So after the edit to {{Information}}, htmlcacheupdate updates page_touched. Then opportunistLinksUpdate slowly starts updating all pages. Thus the LinksUpdate essentially ended up being recursive, despite the bug preventing it from actually being recursive. " I do not understand half of it, but it seems like my recent change changed which added {{CURRENTYEAR}}
might be causing problems. I use {{Years since}} to identify images which were created more than 200 years ago so I can replace {{PD-old}} templates with more specific {{PD-old-100}}, but I can accomplish the same goal without calling {{CURRENTYEAR}}
(which can be hardwired and changed once a decade or so). Would that help? I am reluctant to do another edit to {{Information}} as it can course another backlog. --Jarekt (talk) 14:16, 29 October 2015 (UTC)
- @Jarekt: - technically that is part of the cause, but the underlying cause is bugs in the implementation of job queue, which have now been fixed. Since I made my comment the job queue has been changed so that:
- Direct edits to pages go in a separate prioritized queue. Thus if an edit to a high use template somehow backlogs the queue, it won't affect people making normal edits
- The opportunistic updates (Things caused by {{CURRENTYEAR}}) should no longer be triggered by people editing templates, but by one its detected there is a chance that the {{CURRENTYEAR}} code might cause different categories to be on a page.
- Various bugs that were making the job queue be super slow, were fixed.
So basically, your edits were what caused us to find the bugs, but ultimately its the bugs fault, not your edit. Feel free to edit that template again. I'm pretty sure it won't cause problems like last time. Bawolff (talk) 20:25, 29 October 2015 (UTC)
VP9
[edit]Hi, Regarding your edit here, VP9 videos do not give sound on Commons for me (i.e. File:Snowdonia by drone.webm and File:Devdas 1935.webm). The same video on YouTube has sound. This one has sound. I use Chrome 46 on Win7. Idem on FF. Regards, Yann (talk) 16:21, 26 November 2015 (UTC)
Code issues in User:Bawolff/common.js
[edit]Hi Bawolff, I am a bored bot (this is kind of a computer program) that is watching the recent changes and tapping buttons like I did now.
Curious about the reason? Possibly not but I will tell you anyway:
- You edited User:Bawolff/common.js. Glad to see you coding in javascript! Have you ever considered becoming a MediaWiki hacker?
- Though, that change appears to introduce 8 new jshint issues — the page's status is now having ERRORS. Note that invalid or ambiguous code often has unwanted side effects like breaking other tools for you. If you cannot find out how to fix it, I suggest blanking the page for now.
- To help you understanding where the issues are, I have aggregated a report here and now. If you have questions, don't hesitate to ask users experienced in javascript writing for help. But do not ask the bot's operators (chronically overwrought) unless you suspect an error of mine. If you prefer not getting spammed by me, you can opt-out reports by adding {{ValidationOptOut|type=all}} to your user page or cmb-opt-out anywhere on your your global user page on Meta. Good luck at Wikimedia Commons and happy hacking!
- ISSUE:
line 23 character 32
: Expected an identifier and instead saw '#'. - Evidence:$( function() { setTimeout( $( #ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ), 300 ) );
- ISSUE:
line 23 character 33
: Expected ')' and instead saw 'ca'. - Evidence:$( function() { setTimeout( $( #ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ), 300 ) );
- ISSUE:
line 23 character 43
: Expected ')' and instead saw 'a'. - Evidence:$( function() { setTimeout( $( #ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ), 300 ) );
- ISSUE:
line 23 character 46
: Expected an identifier and instead saw '#'. - Evidence:$( function() { setTimeout( $( #ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ), 300 ) );
- ISSUE:
line 23 character 47
: Missing semicolon. - Evidence:$( function() { setTimeout( $( #ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ), 300 ) );
- ISSUE:
line 23 character 60
: Missing semicolon. - Evidence:$( function() { setTimeout( $( #ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ), 300 ) );
- ISSUE:
line 23 character 62
: Missing semicolon. - Evidence:$( function() { setTimeout( $( #ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ), 300 ) );
- ISSUE:
line 23 character 100
: Missing semicolon. - Evidence:$( function() { setTimeout( $( #ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ), 300 ) );
- ISSUE:
line 23 character 121
: Unclosed string. - Evidence:$( function() { setTimeout( $( #ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ), 300 ) );
- ISSUE:
line 23 character 106
: Unclosed string. - Evidence:$( function() { setTimeout( $( #ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ), 300 ) );
- ISSUE:
line 23 character 106
: Missing semicolon. - Evidence:$( function() { setTimeout( $( #ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ), 300 ) );
- ISSUE:
line 23 character 121
: Missing semicolon. - Evidence:$( function() { setTimeout( $( #ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ), 300 ) );
- ISSUE:
line 23 character 15
: Unmatched '{'. - Evidence:$( function() { setTimeout( $( #ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ), 300 ) );
- ISSUE:
line 23 character 106
: Expected ')' and instead saw ''. - Evidence:$( function() { setTimeout( $( #ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ), 300 ) );
- ISSUE:
line 23 character 121
: Missing semicolon. - Evidence:$( function() { setTimeout( $( #ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ), 300 ) );
Your CommonsMaintenanceBot (talk) at 20:13, 28 November 2015 (UTC).
Code issues in User:Bawolff/common.js
[edit]Hi Bawolff, I am a bored bot (this is kind of a computer program) that is watching the recent changes and tapping buttons like I did now.
Curious about the reason? Possibly not but I will tell you anyway:
- You edited User:Bawolff/common.js. Glad to see you coding in javascript! Have you ever considered becoming a MediaWiki hacker?
- Though, that change appears to introduce 7 new jshint issues — the page's status is now having ERRORS. Note that invalid or ambiguous code often has unwanted side effects like breaking other tools for you. If you cannot find out how to fix it, I suggest blanking the page for now.
- To help you understanding where the issues are, I have aggregated a report here and now. If you have questions, don't hesitate to ask users experienced in javascript writing for help. But do not ask the bot's operators (chronically overwrought) unless you suspect an error of mine. If you prefer not getting spammed by me, you can opt-out reports by adding {{ValidationOptOut|type=all}} to your user page or cmb-opt-out anywhere on your your global user page on Meta. Good luck at Wikimedia Commons and happy hacking!
- ISSUE:
line 23 character 117
: Missing semicolon. - Evidence:$( document ).ready( function() {$( '#ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ) ) );
- ISSUE:
line 23 character 118
: Expected an identifier and instead saw ')'. - Evidence:$( document ).ready( function() {$( '#ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ) ) );
- ISSUE:
line 23 character 119
: Missing semicolon. - Evidence:$( document ).ready( function() {$( '#ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ) ) );
- ISSUE:
line 23 character 120
: Expected an identifier and instead saw ')'. - Evidence:$( document ).ready( function() {$( '#ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ) ) );
- ISSUE:
line 23 character 33
: Unmatched '{'. - Evidence:$( document ).ready( function() {$( '#ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ) ) );
- ISSUE:
line 23 character 121
: Expected ')' and instead saw ''. - Evidence:$( document ).ready( function() {$( '#ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ) ) );
- ISSUE:
line 23 character 122
: Missing semicolon. - Evidence:$( document ).ready( function() {$( '#ca-tineye a, #ca-googleimes a' ).each( function() { this.target = '_blank' } ) ) );
Your CommonsMaintenanceBot (talk) at 20:13, 28 November 2015 (UTC).
Code issues in User:Bawolff/common.js
[edit]Hi Bawolff, I am a bored bot (this is kind of a computer program) that is watching the recent changes and tapping buttons like I did now.
Curious about the reason? Possibly not but I will tell you anyway:
- You edited User:Bawolff/common.js. Glad to see you coding in javascript! Have you ever considered becoming a MediaWiki hacker?
- Though, that change appears to introduce 1 new esprima issue — the page's status is now having ERRORS. Note that invalid or ambiguous code often has unwanted side effects like breaking other tools for you. If you cannot find out how to fix it, I suggest blanking the page for now.
- To help you understanding where the issues are, I have aggregated a report here and now. If you have questions, don't hesitate to ask users experienced in javascript writing for help. But do not ask the bot's operators (chronically overwrought) unless you suspect an error of mine. If you prefer not getting spammed by me, you can opt-out reports by adding {{ValidationOptOut|type=all}} to your user page or cmb-opt-out anywhere on your your global user page on Meta. Good luck at Wikimedia Commons and happy hacking!
- ERROR: Cannot parse
line 23 column 118
: Unexpected token )
Your CommonsMaintenanceBot (talk) at 20:13, 28 November 2015 (UTC).
Hi, Bawolff, I was wondering if this is you. Thank you for your time. Lotje (talk) 11:12, 23 February 2016 (UTC)
- No, thats not me. Bawolff (talk) 14:14, 23 February 2016 (UTC)
- The reason for my asking, is this. But thank you anyway. Lotje (talk) 08:50, 24 February 2016 (UTC)
- Looks like that user hasn't been here for a while (now renamed to n:User:Jmartin678~enwikinews). Bawolff (talk) 20:40, 27 February 2016 (UTC)
- Hopefully he comes back. Lotje (talk) 16:53, 28 February 2016 (UTC)
- Looks like that user hasn't been here for a while (now renamed to n:User:Jmartin678~enwikinews). Bawolff (talk) 20:40, 27 February 2016 (UTC)
- The reason for my asking, is this. But thank you anyway. Lotje (talk) 08:50, 24 February 2016 (UTC)
Fun (ab)use of Template:Tracked
[edit]Manually added duration (diff) . Be..anyone (talk) 17:31, 4 April 2016 (UTC)
Category search scores
[edit]Can you help?[4] Nemo 17:43, 11 April 2016 (UTC)
Case-sensitive comparison wreck dropdown box
[edit]You might know how to fix this problem with the switch-translated file dropdown box.
See Commons talk:Translation possible/Learn more#Hyphenated language codes not working
Glrx (talk) 01:04, 21 October 2016 (UTC)
- Can you revert the change that CParle has put through at Phab:T154132 and https://gerrit.wikimedia.org/r/#/c/385352/ ?
- It's an abomination that changes a line in one place (SVG.php:482) that correctly checked for legal IETF langtags and made it accept illegal IETF langtags; the patch then changes a unit test so the ill-considered langtag change will correctly fail (instead of pass) the unit test (parserTests.txt:15049). It fixes the multiset problem in the wrong place (SVG.php:100 instead of one line in the extractor). The code implements unneeded user agent langtag matching. Simple stuff is strangely moved to subroutines.
- @Nikerabbit:
- Glrx (talk) 18:16, 15 November 2017 (UTC)
Wikimania
[edit]Hello Brian! It's my pleasure to see you in the flesh at Wikimania after seeing your username all these years! Thanks for the good work both as volunteer and as staff. Deryck Chan (talk) 14:52, 23 August 2017 (UTC)
Let's make Commons Conference a reality
[edit]Hello Brian,
I'm writing you as one of the most relevant Mediawiki developers regarding Commons. Since a while now, the idea of a dedicated Commons conference has been floating around. But since the last Wikimania concrete steps have been taken to actually make it happen next year. If you're interested in participation or maybe willing to help organize the first ever Commons Conference, I invite you to check out the project page and add your ideas; or just show your support for the idea, by signing up.
Cheers,
--MB-one (talk) 09:02, 10 September 2017 (UTC)
- @MB-one: If it ends up happening somewhere that is not too expensive for me to travel to, I'd love to attend. Bawolff (talk) 19:36, 11 September 2017 (UTC)
- We are looking into the possibility of scholarships and/or travel grants for certain conference attendees. If you sign up as interested, we will keep you updated on that matter. Cheers --MB-one (talk) 16:52, 12 September 2017 (UTC)
Hi! You may improve this tool (see talkpage)? --Kaganer (talk) 13:41, 14 December 2017 (UTC)
- Hi. I'm aware there are problems with the tool. I'll try to get around to looking at it eventually, but its not a very high priority for me right now. Bawolff (talk) 21:11, 17 December 2017 (UTC)
- Very thanks before ;) --Kaganer (talk) 15:57, 18 December 2017 (UTC)
Greetings, just in case you are still interested in “images that are still showing outdated versions after doing this procedure”: in the last time I uploaded a second version of two of my images, and the changes fail to appear in the thumbnails and the preview (file description page):
I emptied my browser cache and history, I clicked on the “purge” menu item, I manually added “?action=purge” or “?clearcache=0734289” to the URL; I did all this on the image description page as well as on the image URLs (thumbnails and 800×600 preview). Nothing helped. All thumbnails look equal (old version), and the preview shows the old version, too. Manipulating the preview size makes the new image appear but I cannot fix the description page this way.
I am writing this just in case you might be interested, not to request help. I will just stop uploading new versions and create new images instead. Help:Purge mentions an “image cache issue”. It seems to “work” reliably now.
Have a nice day, -- Renardo la vulpo (talk) 18:29, 19 January 2018 (UTC)
- Hi User:Renardo la vulpo - I haven't worked on the multimedia stuff for quite a few years now, so I'm not really interested in that as I once was. BWolff (WMF) (talk) 19:44, 21 January 2018 (UTC)
- I see, thanks all the same. I assume WC has more important things to take care of than re-uploading. -- Renardo la vulpo (talk) 20:52, 21 January 2018 (UTC)
Code issues in User:Bawolff/advancedSearch.js
[edit]Hi Bawolff, I am a bored bot (this is kind of a computer program) that is watching the recent changes and tapping buttons like I did now.
Curious about the reason? Possibly not but I will tell you anyway:
- You edited User:Bawolff/advancedSearch.js. Glad to see you coding in javascript! Have you ever considered becoming a MediaWiki hacker?
- Though, that change appears to introduce 1 new jshint issue — the page's status is now having warnings. Note that invalid or ambiguous code often has unwanted side effects like breaking other tools for you. If you cannot find out how to fix it, I suggest blanking the page for now.
- To help you understanding where the issues are, I have aggregated a report here and now. If you have questions, don't hesitate to ask users experienced in javascript writing for help. But do not ask the bot's operators (chronically overwrought) unless you suspect an error of mine. If you prefer not getting spammed by me, you can opt-out reports by adding {{ValidationOptOut|type=all}} to your user page or cmb-opt-out anywhere on your your global user page on Meta. Good luck at Wikimedia Commons and happy hacking!
- ISSUE:
line 192 character 7
: Missing semicolon. - Evidence:})
Your CommonsMaintenanceBot (talk) at 00:13, 23 January 2018 (UTC).
Typo in JS
[edit]Hi Bawolff... just an FYI, you have a typo in "comma separated" in User:Bawolff/advancedSearch.js. Cheers, Storkk (talk) 13:15, 2 May 2018 (UTC)
- Fixed in my JS (however, that wouldn't fix it in the gadget). Bawolff (talk) 15:04, 2 May 2018 (UTC)
- I know... I fixed it in the gadget first - just thought I'd correct it "upstream" so that if the gadget gets imported from you again, we don't re-inherit the same typo. Anyway, cheers, and have a good one! Storkk (talk) 13:46, 3 May 2018 (UTC)
A barnstar for you!
[edit]The Technical Barnstar | |
For your efforts in saving the Main Page! ~riley (talk) 08:56, 1 January 2020 (UTC) |
Round 1 of Picture of the Year 2022 voting is open!
[edit]Read this message in your language
Dear Wikimedian,
Wikimedia Commons is happy to announce that the 2022 Picture of the Year competition is now open. This year will be the seventeenth edition of the annual Wikimedia Commons photo competition, which recognizes exceptional contributions by users on Wikimedia Commons. Wikimedia users are invited to vote for their favorite images featured on Commons during the last year (2022) to produce a single Picture of the Year.
Hundreds of images that have been rated Featured Pictures by the international Wikimedia Commons community in the past year are all entered in this competition. These images include professional animal and plant shots, breathtaking panoramas and skylines, restorations of historical images, photographs portraying the world's best architecture, impressive human portraits, and so much more.
For your convenience, we have sorted the images into topical categories. Two rounds of voting will be held: In the first round, you may vote for as many images as you like. The top 30 overall and the two most popular images in each category will continue to the final. In the final round, you may vote for just three images to become the Picture of the Year.
Round 1 will end on UTC.
Thanks,
the Wikimedia Commons Picture of the Year committee
You are receiving this message because you voted in the 2021 Picture of the Year contest.
Delivered by MediaWiki message delivery (talk) 09:14, 20 April 2023 (UTC)
5GB with server side upload only
[edit]In the past, I have tried to get files server-side-uploaded. I abandoned the approach. SSU is handled by volunteers and this volunteers only handle the easy cases: the one's that I finally found a way to upload with my own chunked upload tools. I am pessimistic that this has changed, so basically 5GB-SSU seems to be a non-feature that cannot be used in any real world scenario. If it is meant as a test case for later 5GB chunked upload, I assume there will not be many testers of the feature.
At least I hope, transcoding 4GiB video that have a >4GiB transcode will work now? C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 23:49, 8 February 2024 (UTC)
- Essentially yes - i'm hoping a couple people will do 4-5gb to prove it all works, before proposing the chunked upload limit be raised. Chunked upload is already pretty flakey near 4gb, and it might be even more so near 5gb, which is a whole other set of issues. Transcodes larger than 4gb (but smaller tha 5) should be working now (actually as of about 2 months ago). They can still error due to timeouts or other issues of course. To conclude, this is all baby steps. Bawolff (talk) 00:25, 9 February 2024 (UTC)
- @Bawolff 2160p-transcodes do fail for file:genderwahn.webm and file:politparade.webm - and they do fail in the first minute of transcoding. Transcodes for 1440p take 10+ hours. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 07:41, 9 February 2024 (UTC)
- Whoops, I wasn't aware of $wgTranscodeBackgroundSizeLimit, which is currently set to 3GB (T357184). Bawolff (talk) 22:36, 9 February 2024 (UTC)
- @Bawolff 2160p-transcodes do fail for file:genderwahn.webm and file:politparade.webm - and they do fail in the first minute of transcoding. Transcodes for 1440p take 10+ hours. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 07:41, 9 February 2024 (UTC)
- Hi, I have several old films in 4K which size is 4GB to 5 GB. How do you suggest to SSU them? The main issue is to make them available online anyway. Yann (talk) 13:42, 9 February 2024 (UTC)
- @Yann: have you considered trying using google drive as the initial staging server to put them online before SSU? Otherwise i can probably get you SFTP access to a server which you could use Filezilla to upload. Bawolff (talk) 16:49, 9 February 2024 (UTC)
- Google Drive is limited in size. I can't upload a ~4.5GB file there, let alone several ones. I already have an account on Toolforge if it can help. The issue is my connection is not so fast... Yann (talk) 17:20, 9 February 2024 (UTC)
- You should be able to upload to toolforge using sftp. How slow a connection are we talking? Would leaving the upload running overnight be sufficient? I know sftp has a reputation for not being the most efficient protocol. As an alternative we could try transfering the file via bittorrent or magic wormhole if you think that would work better than sftp to toolforge. Bittorrent might work well as its designed to be run in the background and will automatically resume where it left off if interupted. Bawolff (talk) 18:34, 9 February 2024 (UTC)
- OK, I will try sftp. And where do I put the file on Toolforge so that it can be SSU? Yann (talk) 20:18, 9 February 2024 (UTC)
- @Yann: I didn't know this, but apparently you aren't supposed to upload files bigger than 1gb to toolforge https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web#Hosting_large_files . I will email you credentials to a different server. Bawolff (talk) 22:00, 9 February 2024 (UTC)
- OK, I will try sftp. And where do I put the file on Toolforge so that it can be SSU? Yann (talk) 20:18, 9 February 2024 (UTC)
- You should be able to upload to toolforge using sftp. How slow a connection are we talking? Would leaving the upload running overnight be sufficient? I know sftp has a reputation for not being the most efficient protocol. As an alternative we could try transfering the file via bittorrent or magic wormhole if you think that would work better than sftp to toolforge. Bittorrent might work well as its designed to be run in the background and will automatically resume where it left off if interupted. Bawolff (talk) 18:34, 9 February 2024 (UTC)
- Google Drive is limited in size. I can't upload a ~4.5GB file there, let alone several ones. I already have an account on Toolforge if it can help. The issue is my connection is not so fast... Yann (talk) 17:20, 9 February 2024 (UTC)
- @Yann: have you considered trying using google drive as the initial staging server to put them online before SSU? Otherwise i can probably get you SFTP access to a server which you could use Filezilla to upload. Bawolff (talk) 16:49, 9 February 2024 (UTC)
- @Bawolff I tried to upload a webm of 4.9GiB twice and failed with file not found in stash after some time of assembling time. The content of my upload stash is:
- 1appzuqq14kc.q1vky8.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2417"} No Thumbnail - probably assembled
- 1apq20n353m0.n63th6.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2302"} No Thumbnail - probably assembled
- 1apq2nswser4.iyuctt.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2262"} No Thumbnail - probably assembled
- 1apq2vypdhgk.u8gizj.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2360"} No Thumbnail - probably assembled
- 1apq33x21hk4.p6fqbm.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2418"} No Thumbnail - probably assembled
- 1apq5cjwvpq8.9gfo00.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2405"} No Thumbnail - probably assembled
- 1apqaukmudmg.4c9cpu.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2302"} No Thumbnail - probably assembled
- 1apsd8fhi8mk.8mrvs5.6080484.webm {"upload":{"result":"Continue","stage":"uploading","offset":315000000}} No Thumbnail - probably assembled
- 1apumo13rnjk.laxnub.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/f/ff/1apumo13rnjk.laxnub.6080484.webm.0 does not exist.","servedby":"mw2360"} No Thumbnail - probably assembled
- 1apuwdsg8fmk.a0ji56.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/8/81/1apuwdsg8fmk.a0ji56.6080484.webm.0 does not exist.","servedby":"mw2334"} No Thumbnail - probably assembled
- C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 15:57, 16 February 2024 (UTC)
- The file I am trying to upload: https://p-7.eu/f/OBR_Hannover_2024.webm C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 18:23, 16 February 2024 (UTC)
- @Bawolff I tried to upload a webm of 4.9GiB twice and failed with file not found in stash after some time of assembling time. The content of my upload stash is:
Unfortunately chunked upload is pretty unreliable. Here are the internal errors for the things you mentioned:
- 1appzuqq14kc.q1vky8.6080484.webm - The upload is an exact duplicate of the current version of File:Nie wieder ist jetzt – Gedenkdemo - Hannover Opernplatz 2024-01-27.webm.
- 1apq20n353m0.n63th6.6080484.webm, 1apq2nswser4.iyuctt.6080484.webm,"1apq2vypdhgk.u8gizj.6080484.webm, 1apq33x21hk4.p6fqbm.6080484.webm, 1apqaukmudmg.4c9cpu.6080484.webm - The upload is an exact duplicate of the current version of File:Venus Berlin 2022 XXX.webm [Which Venus file varied].
- 1apq5cjwvpq8.9gfo00.6080484.webm - [backend-fail-notexists] Error on concatenate 33 stashed files (mwstore://local-swift-codfw/local-temp/c/cb/1apq5cjwvpq8.9gfo00.6080484.webm.0), SwiftFileBackend-local-swift-codfw failed to concatenate 34 file(s) [0.19641590118408 sec]
- 1apsd8fhi8mk.8mrvs5.6080484.webm - This had no error. Maybe it was aborted part way through uploading
- 1apumo13rnjk.laxnub.6080484.webm -[backend-fail-notexists] Error on concatenate 54 stashed files (mwstore://local-swift-codfw/local-temp/f/ff/1apumo13rnjk.laxnub.6080484.webm.0)
- 1apuwdsg8fmk.a0ji56.6080484.webm - [backend-fail-notexists] Error on concatenate 54 stashed files (mwstore://local-swift-codfw/local-temp/8/81/1apuwdsg8fmk.a0ji56.6080484.webm.0)
Alas, that isn't very illuminating. I'll try and dig further but no promises. Bawolff (talk) 20:41, 16 February 2024 (UTC)
- I was able to upload 2GB of 5GiB: File:OBR Hannvoer 2024.webm. But upload fails with all fragments larger than 2GB:
- 1apw3ry7kag0.y92dwq.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2298"} No Thumbnail - probably assembled
- 1apwae5cydv8.b4fskn.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2402"} No Thumbnail - probably assembled
- 1apx2jczz3qo.f4a3q2.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2285"} No Thumbnail - probably assembled
- 1apyes24f304.q49k41.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2302"} No Thumbnail - probably assembled
- 1apz3txiv3rk.y6rr8a.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/d/dc/1apz3txiv3rk.y6rr8a.6080484.webm.0 does not exist.","servedby":"mw2404"} No Thumbnail - probably assembled
- 1aq075430lfs.wprv1d.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/3/39/1aq075430lfs.wprv1d.6080484.webm.0 does not exist.","servedby":"mw2283"} No Thumbnail - probably assembled
- 1aq14yhzesp0.58wl05.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/8/8b/1aq14yhzesp0.58wl05.6080484.webm.0 does not exist.","servedby":"mw2298"} No Thumbnail - probably assembled
- 1aq1axa0lzrg.j3ayrg.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/6/6a/1aq1axa0lzrg.j3ayrg.6080484.webm.0 does not exist.","servedby":"mw2404"} No Thumbnail - probably assembled
- 1aq1eweeuif0.73ichm.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/3/3f/1aq1eweeuif0.73ichm.6080484.webm.0 does not exist.","servedby":"mw2261"} No Thumbnail - probably assembled
- 1aq1pr6yv6yo.a404ss.6080484.webm {"error":{"code":"stashfailed","info":"Could not acquire lock. Somebody else is doing something to this file.","servedby":"mw2323"} No Thumbnail - probably assembled
- 1aq1qhg04iyw.dtj5zv.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/e/e5/1aq1qhg04iyw.dtj5zv.6080484.webm.0 does not exist.","servedby":"mw2374"} No Thumbnail - probably assembled
- 1aq1tlxf271o.if3626.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/4/49/1aq1tlxf271o.if3626.6080484.webm.0 does not exist.","servedby":"mw2416"} No Thumbnail - probably assembled
- C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 21:59, 18 February 2024 (UTC)
- Its failing at exactly the 2GB mark? That's interesting because that's the max size of a 32 bit signed integer. But I can't think of anything using 32 bit signed integers. How big a chunk size are you using during chunked upload? I tried to add some additional debugging code to chunked upload that should go live on the site on Wednesday. I don't know if it will help, but when stuck gathering more info is always a prudent course. Bawolff (talk) 23:29, 18 February 2024 (UTC)
- No, I tried (successfullty) to upload a fragment of 2.000.000.000. But until now every fragment of 2.100.000.000 or more (or the complete file) fails. And mostly it fails after some minutes of "assembling". I cleared the stash again, to be able to query the stash again and i am still trying. You can see the full file at p-7.eu/f/OBR_Hannover_2024.webm C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 05:04, 19 February 2024 (UTC)
- in the morning:
- 1aq2zg1j97u4.nmatfs.6080484.webm {"error":{"code":"stashfailed","info":"Could not acquire lock. Somebody else is doing something to this file.","servedby":"mw2299"} No Thumbnail - probably assembled
- 1aq37zhtneb4.8p566r.6080484.webm {"error":{"code":"stashfailed","info":"Could not acquire lock. Somebody else is doing something to this file.","servedby":"mw2287"} No Thumbnail - probably assembled
- 1aq3age1amn4.cuzjmy.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/6/64/1aq3age1amn4.cuzjmy.6080484.webm.0 does not exist.","servedby":"mw2397"} No Thumbnail - probably assembled
- 1aq3cx8vze7k.wsd4h3.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/f/f1/1aq3cx8vze7k.wsd4h3.6080484.webm.0 does not exist.","servedby":"mw2287"} No Thumbnail - probably assembled
- 1aq3fy40d4hs.g41dpq.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}} No Thumbnail - probably assembled
- now:
- 1aq2zg1j97u4.nmatfs.6080484.webm {"error":{"code":"stashfailed","info":"Could not acquire lock. Somebody else is doing something to this file.","servedby":"mw2362"} No Thumbnail - probably assembled
- 1aq37zhtneb4.8p566r.6080484.webm {"error":{"code":"stashfailed","info":"Could not acquire lock. Somebody else is doing something to this file.","servedby":"mw2286"} No Thumbnail - probably assembled
- 1aq3age1amn4.cuzjmy.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/6/64/1aq3age1amn4.cuzjmy.6080484.webm.0 does not exist.","servedby":"mw2324"} No Thumbnail - probably assembled
- 1aq3cx8vze7k.wsd4h3.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/f/f1/1aq3cx8vze7k.wsd4h3.6080484.webm.0 does not exist.","servedby":"mw2405"} No Thumbnail - probably assembled
- 1aq3fy40d4hs.g41dpq.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/b/bf/1aq3fy40d4hs.g41dpq.6080484.webm.0 does not exist.","servedby":"mw2403"} No Thumbnail - probably assembled
- 1aq3jd5qi7ck.knnvtp.6080484.webm {"upload":{"result":"Continue","stage":"uploading","offset":2729998975}} No Thumbnail - probably assembled
- C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 10:57, 19 February 2024 (UTC)
- just now it almost succeded: It did not fail while assembling but whil publishing:
- Unstashing '1aq4huils9pg.eu53ho.6080484.webm' as 'OBR_Hannvoer_2024.webm'
- unstashing, retrying - 16 ActionResult PUBLISH
- {"error":{"code":"stashfailed","info":"Could not acquire lock. Somebody else is doing something to this file.","*":"See https://commons.wikimedia.org/w/api.php
- Unstashing '1aq4huils9pg.eu53ho.6080484.webm' as 'OBR_Hannvoer_2024.webm'
- Encountered an error while unstashing, retrying - 17 ActionResult STASHFAILED
- {"error":{"code":"stashfailed","info":"Could not acquire lock. Somebody else is doing something to this file.","*":"See https://commons.wikimedia.org/w/api.php
- C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 18:17, 19 February 2024 (UTC)
- Now:
- unstashing, retrying - 15 ActionResult PUBLISH
- {"error":{"code":"stashfailed","info":"Could not acquire lock. Somebody else is doing something to this file.","*":"See https://commons.wikimedi
- Unstashing '1aq5s1dp141k.ar6mbp.6080484.webm' as 'OBR_Hannvoer_2024.webm'
- Encountered an error while unstashing, retrying - 16 ActionResult STASHFAILED
- C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 04:11, 20 February 2024 (UTC)
- There's also some log entries like:
[Feb 20, 2024 @ 04:00:23.669]FileBackendMultiWrite::doOperationsInternal: failed sync check: ["mwstore://local-multiwrite/local-public/4/49/OBR_Hannvoer_2024.webm","mwstore://local-multiwrite/local-public/archive/4/49/20240219185232!OBR_Hannvoer_2024.webm"], [Feb 18, 2024 @ 15:00:59.187] Error fetching URL "https://ms-fe.svc.codfw.wmnet/v1/AUTH_mw/wikipedia-commons-local-public.49/4/49/OBR_Hannvoer_2024.webm": (curl error: 18) Transferred a partial file, [Feb 18, 2024 @ 15:00:59.188] HTTP 200 (OK) in 'SwiftFileBackend::doGetLocalCopyMulti' (given '{"src":"mwstore://local-swift-codfw/local-public/4/49/OBR_Hannvoer_2024.webm","concurrency":50}'): Got 18350080/1699708636 bytes
Which is a bit different then before. The Failed sync check error means that different WMF data centers have different versions of the file (The stored SHA-1 hash and file size are checked). Its suggestive that in the latest attempt that it might be failing at the stage of moving the currently uploaded file to be an old file, which would be a bit surprising. However, there is definitely some weirdness about the current version of File:OBR_Hannvoer_2024.webm. MediaWiki thinks its file size is exactly 2000000000 bytes (1.86 GiB). Swift seems to think it is 2999993167 bytes (Except if you actually try and fetch it, it thinks the file is only 2099946853 bytes long. After i tried to fetch the end of the file, the content-length header got updated on subsequent requests). So we are off by 931 MB which is very weird. MediaWiki think the current version's (base36) SHA-1 hash is p0amv7n9lkmxw59fbsfdyo164jo9f6b, Swift thinks it is c09mf9ger5qnycw553m404x93bfcuxj. MW thinks the file was last modified Feb 18 19:34:03, swift Mon, 19 Feb 2024 21:59:51 GMT. Anyways, my suspicion is that the current version got half uploaded, MW and Swift disagree about what file is there, so when a new version gets uploaded, MW freaks out at the apparent corruption and aborts. Might also explain why everything has a lock conflict if one of the locks was never released (I'm not sure if they get automatically released at some point or what). Anyways, given the state of that file currently, you might have better luck uploading under a different name. Bawolff (talk) 04:50, 20 February 2024 (UTC)- Stash cleared (again), now trying with different names. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 06:47, 20 February 2024 (UTC)
- File:OBR Hannvoer 2024a.webm File:OBR Hannvoer 2024b.webm File:OBR Hannvoer 2024c.webm C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 08:31, 20 February 2024 (UTC)
- Those new ones have no warnings in the logs (I'm hopeful come wed when we get increased logging of chunked upload on commons, there might be something more useful in logs), seem to have uploaded successfully, and seem consistent between MW and swift. Can I ask what tool you are using to upload files? Bawolff (talk) 08:59, 20 February 2024 (UTC)
- File:OBR Hannvoer 2024d.webm File:OBR Hannvoer 2024e.webm <- will not transcode for 2160p.
- I am using my own upload tool. But the Android-App Offroader is based on it. The App uses Andriod's extfiledir to store files and would be difficult to use at the moment as Google made this directory inaccessible for file managers from the device (but it can be accessed via USB) C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 10:03, 20 February 2024 (UTC)
- The transcode issue is phab:T357184, which is a separate but known problem, and will hopefully be fixed soon. Bawolff (talk) 11:07, 20 February 2024 (UTC)
- 3GB failed: 1aq6ivp0q0kw.rrjm7g.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/b/b2/1aq6ivp0q0kw.rrjm7g.6080484.webm.0 does not exist.","servedby":"mw2328"}
- 3.5GB assembling for about 4 hours now: 1aq6o78kvlbk.d6tn00.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}}
- C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 15:34, 20 February 2024 (UTC)
- 1aq6ivp0q0kw.rrjm7g.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/b/b2/1aq6ivp0q0kw.rrjm7g.6080484.webm.0 does not exist.","servedby":"mw2399"}
- 1aq6o78kvlbk.d6tn00.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}}
- 1aq7isk8lg5k.tk5mmi.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/f/ff/1aq7isk8lg5k.tk5mmi.6080484.webm.0 does not exist.","servedby":"mw2332"}
- 1aq7m80w1unk.qv0vz5.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/6/6c/1aq7m80w1unk.qv0vz5.6080484.webm.0 does not exist.","servedby":"mw2304"}
- 1aq7qbhn7vtw.8o4kao.6080484.webm {"error":{"code":"stashfailed","info":"The file mwstore://local-swift-codfw/local-temp/4/45/1aq7qbhn7vtw.8o4kao.6080484.webm.0 does not exist.","servedby":"mw2405"}
- 1aq7ufcio6fg.ciljcq.6080484.webm {"upload":{"result":"Continue","stage":"uploading","offset":1864150665}}
- C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 20:28, 20 February 2024 (UTC)
- I'm going to try and upload the file myself, to see if i can catch where the error is happening. Bawolff (talk) 23:02, 20 February 2024 (UTC)
- I got a "logged in from a new device" notification at 1:36. That could be my upload script, but it has never before triggered this notification. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 05:40, 21 February 2024 (UTC)
- My attempt at uploading that file failed (with the filename.webm.0 does not exist error). However, i think that might be because i tried uploading it to test.wikipedia.org. In progress chunked upload files are only kept for 6 hours on wikis that are not commons (Commons is supposed to keep them for 48 hours). My attempted upload took more than 6 hours, which might explain the failure. However that should not apply to commons with the higher limit. Bawolff (talk) 06:24, 21 February 2024 (UTC)
- @C.Suthorn We made a change to chunked upload, which we think might fix the file does not exist errors. Do you want to try uploading the full file again to see what happens this time? Bawolff (talk) 22:42, 22 February 2024 (UTC)
- 3.5GB: '1aqe7m9mibc8.ihm5od.6080484.webm' as 'OBR_Hanndvoer_21024g.webm' was in assembling and stopped because of a timeout in my local software after hours of assembling.
- 3.9GB: {"upload":{"result":"Continue","offset":97498542,"filekey":"1aqezls7rlh8.gjawmj.6080484.webm"}} is now uploading
- File:OBR Hanndvoer 21024f.webm is the largest version that succeeded so far.
- the next fragment I tried was 3099925409 bytes and it failed like all larger versions so far.
- At the moment there are so many files in the upload stash that i can neither list the stash nor clear the stash. Therefore i can only see the status of the current upload. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 04:17, 23 February 2024 (UTC)
- I'm actually suspecting right now that the assemble job might be hitting a time limit after 4 minutes, and that if it doesn't finish in 4 minutes, it never will. Still looking into it. Bawolff (talk) 06:38, 23 February 2024 (UTC)
- @C.Suthorn We made a change to chunked upload, which we think might fix the file does not exist errors. Do you want to try uploading the full file again to see what happens this time? Bawolff (talk) 22:42, 22 February 2024 (UTC)
- My attempt at uploading that file failed (with the filename.webm.0 does not exist error). However, i think that might be because i tried uploading it to test.wikipedia.org. In progress chunked upload files are only kept for 6 hours on wikis that are not commons (Commons is supposed to keep them for 48 hours). My attempted upload took more than 6 hours, which might explain the failure. However that should not apply to commons with the higher limit. Bawolff (talk) 06:24, 21 February 2024 (UTC)
- I got a "logged in from a new device" notification at 1:36. That could be my upload script, but it has never before triggered this notification. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 05:40, 21 February 2024 (UTC)
- I'm going to try and upload the file myself, to see if i can catch where the error is happening. Bawolff (talk) 23:02, 20 February 2024 (UTC)
- The transcode issue is phab:T357184, which is a separate but known problem, and will hopefully be fixed soon. Bawolff (talk) 11:07, 20 February 2024 (UTC)
- Those new ones have no warnings in the logs (I'm hopeful come wed when we get increased logging of chunked upload on commons, there might be something more useful in logs), seem to have uploaded successfully, and seem consistent between MW and swift. Can I ask what tool you are using to upload files? Bawolff (talk) 08:59, 20 February 2024 (UTC)
- File:OBR Hannvoer 2024a.webm File:OBR Hannvoer 2024b.webm File:OBR Hannvoer 2024c.webm C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 08:31, 20 February 2024 (UTC)
- Stash cleared (again), now trying with different names. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 06:47, 20 February 2024 (UTC)
- There's also some log entries like:
- Now:
- just now it almost succeded: It did not fail while assembling but whil publishing:
- in the morning:
- No, I tried (successfullty) to upload a fragment of 2.000.000.000. But until now every fragment of 2.100.000.000 or more (or the complete file) fails. And mostly it fails after some minutes of "assembling". I cleared the stash again, to be able to query the stash again and i am still trying. You can see the full file at p-7.eu/f/OBR_Hannover_2024.webm C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 05:04, 19 February 2024 (UTC)
- Its failing at exactly the 2GB mark? That's interesting because that's the max size of a 32 bit signed integer. But I can't think of anything using 32 bit signed integers. How big a chunk size are you using during chunked upload? I tried to add some additional debugging code to chunked upload that should go live on the site on Wednesday. I don't know if it will help, but when stuck gathering more info is always a prudent course. Bawolff (talk) 23:29, 18 February 2024 (UTC)
- @C.Suthorn: I got an error while trying to merge File:OBR Hannover 2024.webm. Deletion and rename were OK, but when undeleting I got Some or all of the undeletion failed: An unknown error occurred in storage backend "local-swift-eqiad". Yann (talk) 14:59, 23 February 2024 (UTC)
- It worked on 2nd try. Yann (talk) 15:11, 23 February 2024 (UTC)
- There was already a 100MB larger version, but it is still good to have it in the version history.
- However it seems I have finally hit this 4 min assembling limit and no larger versions can be added. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 18:51, 23 February 2024 (UTC)
- Now 3.099.925.409 bytes. But still no success with larger, and also failed for a 50MB smaller version. Uploading 1aqiag0jee8o.uuh8lm.6080484.webm with 3.15G at the moment. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 06:17, 24 February 2024 (UTC)
- I think i identified another potential fix on the mediawiki side, but it probably wont be until late next week before it can go live. Bawolff (talk) 06:24, 24 February 2024 (UTC)
- I will wait with more tries to upload the file until the end of the week. There are no uploads running now, but i can list the uploadstash again:
- 1aqezls7rlh8.gjawmj.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2364"} No Thumbnail
- 1aqfmg2ay8lk.jgne3l.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2404"} No Thumbnail
- 1aqfw3lbujx4.amlnqp.6080484.webp {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2364"} thumbnail length 41058 PNG
- 1aqfw5cm870c.anaypg.6080484.png {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2358"} thumbnail length 178764 PNG
- 1aqgdm83ho6o.lh7p22.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2283"} No Thumbnail
- 1aqgurpz5t8s.fvteb6.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2284"} No Thumbnail
- 1aqhq32b9x98.frkzkv.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2397"} No Thumbnail
- 1aqiag0jee8o.uuh8lm.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2326"} No Thumbnail
- 1aqj1p80qhkc.qzv9we.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2326"} No Thumbnail
- 1aqjszr7u69w.ww3b2i.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}} No Thumbnail
- 1aqjy5ve2bvg.ehwcd9.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}} No Thumbnail
- 1aqkq1aw6wqk.suh2ik.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}} No Thumbnail
- 1aqlcf1dkkgk.w7y6uk.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}} No Thumbnail
- 1aqlt57pl2qc.9ipm2g.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}} No Thumbnail
- C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 17:21, 25 February 2024 (UTC)
- Funny thing: to extract a thumbnail from the stash you need to add an extra dash after "px-" for webm files, otherwise it will not find the thunb. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 18:02, 25 February 2024 (UTC)
- User:Umherirrender totally rewrote the way Special:UploadStash displays things. Maybe that is fixed in the new version. (That particular change should go live on Wednesday). Bawolff (talk) 18:44, 25 February 2024 (UTC)
- Just fyi, the latest potential improvement for chunked upload should go live after 21:00 utc on Wednesday. Bawolff (talk) 19:40, 26 February 2024 (UTC)
- 1aqwnvyl3kqs.rnwzly.6080484.webm made it into the publishing stage, but after 5 min 20 secs of publishing it failed with "someone else is doing something to this file". It is a 3.5 GB fragment of the file. Fragments with 3.1 to 3.4 GB have failed before. Again i cannot read the stash, but i was able to read it in the afternoon and webm-thumbs still do not work with a single dash.
- now 1aqwokdel1rg.g4qlr6.6080484.webm is in uploading stage with 3.9GB. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 22:52, 28 February 2024 (UTC)
- aborted the last one and starting again with 1aqwq4rnrmh0.unk5h1.6080484.webm and a modified file name. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 23:09, 28 February 2024 (UTC)
- Well the fact it got past the assemble stage is an improvement. All the fixes were to that stage, so guess i have to look into improving the publish stage too. Bawolff (talk) 23:34, 28 February 2024 (UTC)
- The last try (3.5GB) was hanging in assembling stage again. I was able to clear the stash and 1aqxow763b6g.28fwnc.6080484.webm is uploading now. Fragments with 3.15GB and 3.2GB failed, but I do not know, why. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 06:47, 29 February 2024 (UTC)
- 1aqxow763b6g.28fwnc.6080484.webm is in assemling for more than 30 minutes now. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 09:50, 29 February 2024 (UTC)
- failed with local timeout while assembling. now uploading 3.15GB fragment "1aqygqfvl5pk.v28jo0.6080484.webm". C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 12:47, 29 February 2024 (UTC)
- publishing failed with "someone else is doing something to the file". now uploading 1aqyjt2i69oc.oavgrx.6080484.webm 3.2GB. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 13:32, 29 February 2024 (UTC)
- abandoned and uploading 1aqykgyi34z4.rd8g3u.6080484.webm with modified filename. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 13:35, 29 February 2024 (UTC)
- stuck in assembling. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 14:13, 29 February 2024 (UTC)
- 3.2GB succeeded. 3.15GB before failed, 1aqzi2v3dpow.jkkuak.6080484.webm 3.5GB failed in publishing stage "someone else is...". uploading 1aqziqytmesw.6udwqt.6080484.webm 3.9GB now. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 21:25, 29 February 2024 (UTC)
- It seems like File:OBR Hannovier 1-2024.webm worked, although it seems like there was duplicate publish jobs which may have causes the API to give an error message incorrectly. It seems like some of the changes made helped a little bit, where slightly larger files are working, but didn't help as much as I hoped. Bawolff (talk) 03:21, 1 March 2024 (UTC)
- stash cleared and restarting with 1ar0ih5cxtk8.k8prwu.6080484.webm 3.5GB and modified filename C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 04:50, 1 March 2024 (UTC)
- 1ar0ih5cxtk8.k8prwu.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2290"}
- 1ar1a1kzc7ow.bh810.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}}
- 1ar2243ut3xg.t3pqf9.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}}
- 1ar2uewzf5cw.k6ty4k.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}}
- 1ar3mvy6y1ro.g9nd3z.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}}
- C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 08:13, 2 March 2024 (UTC)
- 1ar0ih5cxtk8.k8prwu.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2299"}
- 1ar1a1kzc7ow.bh810.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2418"}
- 1ar2243ut3xg.t3pqf9.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}}
- 1ar2uewzf5cw.k6ty4k.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}}
- 1ar3mvy6y1ro.g9nd3z.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}}
- C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 16:26, 2 March 2024 (UTC)
- 1ar0ih5cxtk8.k8prwu.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2362"}
- 1ar1a1kzc7ow.bh810.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2374"}
- 1ar2243ut3xg.t3pqf9.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2330"}
- 1ar2uewzf5cw.k6ty4k.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2261"}
- 1ar3mvy6y1ro.g9nd3z.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2326"}
- C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 07:15, 3 March 2024 (UTC)
- 1ar3mvy6y1ro.g9nd3z.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2322"} - only file left in the stash. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 06:49, 4 March 2024 (UTC)
- stash cleared and restarting with 1ar0ih5cxtk8.k8prwu.6080484.webm 3.5GB and modified filename C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 04:50, 1 March 2024 (UTC)
- It seems like File:OBR Hannovier 1-2024.webm worked, although it seems like there was duplicate publish jobs which may have causes the API to give an error message incorrectly. It seems like some of the changes made helped a little bit, where slightly larger files are working, but didn't help as much as I hoped. Bawolff (talk) 03:21, 1 March 2024 (UTC)
- 3.2GB succeeded. 3.15GB before failed, 1aqzi2v3dpow.jkkuak.6080484.webm 3.5GB failed in publishing stage "someone else is...". uploading 1aqziqytmesw.6udwqt.6080484.webm 3.9GB now. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 21:25, 29 February 2024 (UTC)
- stuck in assembling. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 14:13, 29 February 2024 (UTC)
- abandoned and uploading 1aqykgyi34z4.rd8g3u.6080484.webm with modified filename. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 13:35, 29 February 2024 (UTC)
- publishing failed with "someone else is doing something to the file". now uploading 1aqyjt2i69oc.oavgrx.6080484.webm 3.2GB. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 13:32, 29 February 2024 (UTC)
- failed with local timeout while assembling. now uploading 3.15GB fragment "1aqygqfvl5pk.v28jo0.6080484.webm". C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 12:47, 29 February 2024 (UTC)
- 1aqxow763b6g.28fwnc.6080484.webm is in assemling for more than 30 minutes now. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 09:50, 29 February 2024 (UTC)
- The last try (3.5GB) was hanging in assembling stage again. I was able to clear the stash and 1aqxow763b6g.28fwnc.6080484.webm is uploading now. Fragments with 3.15GB and 3.2GB failed, but I do not know, why. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 06:47, 29 February 2024 (UTC)
- Well the fact it got past the assemble stage is an improvement. All the fixes were to that stage, so guess i have to look into improving the publish stage too. Bawolff (talk) 23:34, 28 February 2024 (UTC)
- aborted the last one and starting again with 1aqwq4rnrmh0.unk5h1.6080484.webm and a modified file name. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 23:09, 28 February 2024 (UTC)
- Funny thing: to extract a thumbnail from the stash you need to add an extra dash after "px-" for webm files, otherwise it will not find the thunb. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 18:02, 25 February 2024 (UTC)
- I will wait with more tries to upload the file until the end of the week. There are no uploads running now, but i can list the uploadstash again:
- I think i identified another potential fix on the mediawiki side, but it probably wont be until late next week before it can go live. Bawolff (talk) 06:24, 24 February 2024 (UTC)
- Now 3.099.925.409 bytes. But still no success with larger, and also failed for a 50MB smaller version. Uploading 1aqiag0jee8o.uuh8lm.6080484.webm with 3.15G at the moment. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 06:17, 24 February 2024 (UTC)
- It worked on 2nd try. Yann (talk) 15:11, 23 February 2024 (UTC)
- FYI, I managed to upload File:Waxworks (1924) by Paul Leni.webm (2.7 GB), the second version of File:His Girl Friday (1940) by Howard Hawks.webm (2.61 GB), File:A Page of Madness (1926) by Teinosuke Kinugasa.webm (3.83 GB), and File:Steamboat Bill Jr. (1928) by Charles Riesner.webm (3.4 GB with COM:V2C). Yann (talk) 11:10, 23 February 2024 (UTC)
@C.Suthorn: User:HNowlan_(WMF) deployed another attempt at a fix if you want to try again. Bawolff (talk) 15:59, 2 April 2024 (UTC)
- 1atscf7v1th0.mzhte2.6080484.webm is stuck in assembling for a hour now. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 21:11, 2 April 2024 (UTC)
- @Bawolff{"error":{"code":"publishfailed","info":"Upload from stash already in progress.","*":" <- just now. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 21:27, 2 April 2024 (UTC)
- @C.Suthorn Just FYI, a new change that potentially fixes it (I know, you have heard that before), was deployed today. Bawolff (talk) 16:58, 18 April 2024 (UTC)
- @Bawolff A journey has ended. All four revisions I still had, uploaded at first try, the full file of 5.238.387.915 Bytes / 4.88GiB is now published, I have no more test data left. But then: Transcoding of all but the smallest resolutions seems to fail. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 15:48, 19 April 2024 (UTC)
- Finally! This whole issue took way too long to fix. Guess we'll have to look at the transcode issue next. Bawolff (talk) 16:08, 19 April 2024 (UTC)
- Transcoding also takes really long: https://commons.wikimedia.org/wiki/File:OBR_Hannover_2024.webm#Transcode_status and after a file move or revision merge transcoding has to be started manually. The old transcodes vanish, but no new one's are made. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 05:12, 20 April 2024 (UTC)
- If transcoding takes 15 hours (and then succeeds) it would be really good, if the "status" in the "transcode status" section of the file description page would show something like "23% transcoded and running", instead of "started 14 hours 59 minutes ago". There are videos that show "started 3 month and 2 days ago" - if there was a percentage, or number of bytes already transcoded or running time of the video already transcoded you could at least guess, if a transcoding is still active or stuck for good. Or even on the way to fail by the number of bytes suddenly growing much faster than the running time already processed. For some videos ffmpeg shows this behavior and until now the only solution i have found for it is to split a video and transcode the sections with different bandwith parameters, then merge into one reasonably sized video. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 09:59, 21 April 2024 (UTC)
- Transcodes are limited to taking 24 hours of time at most. "Started" doesn't necessarily mean started, just that it is in the queue of files to be transcoded. Bawolff (talk) 18:25, 21 April 2024 (UTC)
- actually, it first shows something like "added to queue 1 min 34 secs ago", then changes to "started 34 secs ago", if this information is accurate, i don't know. If there is a time limit, then the status should change after this limit to "failed [after xx hours of transcode running] [after 25% transcode progress]".
- The OBR file now has transcodes for all resolutions apart from 2160p and will fail for 2160p at the moment the status changes from "added to queue" to "error" (instead of started XX seconds ago). C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 04:09, 22 April 2024 (UTC)
- Streaming transcodes are as far as i know delivered as a large number of small files to the browser. The 5GiB limit should not come into play for streaming transcodes. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 04:11, 22 April 2024 (UTC)
- Sorry, you are right. Once it is started, there is a 24 hour time limit. However if the job fails or passes 24 hours it will be retried, so it could still succeed after a couple days. Bawolff (talk) 05:06, 22 April 2024 (UTC)
- But this info is not visible to the user. There definitly should be more info on the page. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 06:40, 22 April 2024 (UTC)
- Transcodes are limited to taking 24 hours of time at most. "Started" doesn't necessarily mean started, just that it is in the queue of files to be transcoded. Bawolff (talk) 18:25, 21 April 2024 (UTC)
- If transcoding takes 15 hours (and then succeeds) it would be really good, if the "status" in the "transcode status" section of the file description page would show something like "23% transcoded and running", instead of "started 14 hours 59 minutes ago". There are videos that show "started 3 month and 2 days ago" - if there was a percentage, or number of bytes already transcoded or running time of the video already transcoded you could at least guess, if a transcoding is still active or stuck for good. Or even on the way to fail by the number of bytes suddenly growing much faster than the running time already processed. For some videos ffmpeg shows this behavior and until now the only solution i have found for it is to split a video and transcode the sections with different bandwith parameters, then merge into one reasonably sized video. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 09:59, 21 April 2024 (UTC)
- Transcoding also takes really long: https://commons.wikimedia.org/wiki/File:OBR_Hannover_2024.webm#Transcode_status and after a file move or revision merge transcoding has to be started manually. The old transcodes vanish, but no new one's are made. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 05:12, 20 April 2024 (UTC)
- Finally! This whole issue took way too long to fix. Guess we'll have to look at the transcode issue next. Bawolff (talk) 16:08, 19 April 2024 (UTC)
- @Bawolff A journey has ended. All four revisions I still had, uploaded at first try, the full file of 5.238.387.915 Bytes / 4.88GiB is now published, I have no more test data left. But then: Transcoding of all but the smallest resolutions seems to fail. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 15:48, 19 April 2024 (UTC)
- @C.Suthorn Just FYI, a new change that potentially fixes it (I know, you have heard that before), was deployed today. Bawolff (talk) 16:58, 18 April 2024 (UTC)
- @Bawolff{"error":{"code":"publishfailed","info":"Upload from stash already in progress.","*":" <- just now. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 21:27, 2 April 2024 (UTC)
One more
[edit]- File:His Girl Friday (1940) by Howard Hawks.webm, thanks to you. Yann (talk) 20:28, 21 February 2024 (UTC)
new error
[edit]- 08,11:58:42inf: Unstashing '1armlg09jxac.z0xv97.6080484.webm' as 'OBR_Hannogvefir_2-2024.webm'
- 08,11:58:42wrn: unstashing, retrying - 0 ActionResult ASSEMBLING
- {"upload":{"result":"Poll","stage":"assembling"}}
- 08,11:59:02inf: Unstashing '1armlg09jxac.z0xv97.6080484.webm' as 'OBR_Hannogvefir_2-2024.webm'
- 08,11:59:02wrn: publish '1armlg09jxac.z0xv97.6080484.webm' as 'OBR_Hannogvefir_2-2024.webm'
- {"error":{"code":"publishfailed","info":"Upload from stash already in progress.","*":"See commons.wikimedia.org/w/api.php for API usage...
- 08,11:59:02err: Encountered an error while unstashing, retrying - 1 ActionResult PUBLISHFAILED
- 08,11:59:03inf: Unstashing '1armlg09jxac.z0xv97.6080484.webm' as 'OBR_Hannogvefir_2-2024.webm'
- 08,11:59:03wrn: unstashing, retrying - 301 ActionResult ASSEMBLING
- C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 12:10, 8 March 2024 (UTC)
- Current Stash, no uploads running:
- 1armlg09jxac.z0xv97.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2299"}
- 1arndaho8k3o.ifbwyz.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2404"}
- 1aro5adpwe1s.y9mb7i.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2300"}
- 1aroy5hpq0q0.xeyugt.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2286"}
- 1arpr35427hw.nx3ika.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}}
- C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 05:47, 10 March 2024 (UTC)
- A fragment with 3.5 GB now uploaded successfully but the next larger fragment with 3.9 GB is hanging in assembling stage:
- 1as4mih2vmm8.lvonz8.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}}
- transcoding for 2160p still errs on start. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 10:43, 14 March 2024 (UTC)
- More failed attempts:
- 1as4mih2vmm8.lvonz8.6080484.webm {"error":{"code":"missingresult","info":"No result in status data.","servedby":"mw2298"}
- 1as5f5ak74uk.uvyzab.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}}
- 1as68bq5vems.ats4tb.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}}
- 1as70ur6256s.qh3kc.6080484.webm {"upload":{"result":"Poll","stage":"assembling"}}
- C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 09:32, 15 March 2024 (UTC)
- More failed attempts:
- A fragment with 3.5 GB now uploaded successfully but the next larger fragment with 3.9 GB is hanging in assembling stage:
- Current Stash, no uploads running:
MaybeEncodingError: PicklingError
[edit]FYI: [5]. Yann (talk) 12:26, 8 March 2024 (UTC)
Gadget-ImageStack.js
[edit]Hi Bawolff! Thank You very much for the changes on Gadget-ImageStack.js which are really useful! As a radiologist and just a hobby programmer, I am grateful if someone who understands something about it gets involved. Best regards! Hellerhoff (talk) 15:07, 4 April 2024 (UTC)
webp+metadata - thumbs
[edit]Now that MW does show metadata for webp files, i did a test and uploaded meintest.webp. I discovered two things:
- the thumb files for webp are png and therefore larger (5 times) than the original file (I think i made a feature request on phab in the past for thumbs of webp to be also webp and not png. But it was declined?)
- the thumb files strip the metadata fields "Licensor URL", "Web Statement" and "Usage Terms" (and also Creator, Description, Maker Note, History Software Agent, XMP Toolkit), and IMHO these three entries should be kept for the thumbs.
C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 08:24, 18 May 2024 (UTC)
- For 1, i left a message suggesting it be reconsidered on phab:T338342. For 2, It looks like Exif data is copied over (MediaWiki doesn't support reading Exif data embedded in PNG files, but other tools do) however XMP data is not. While there probably could be improvements made to how metadata is copied to thumbs, I'm probably not going to work on that. Bawolff (talk) 03:56, 19 May 2024 (UTC)
- if the thumbs were webp, then cwebp or the webp-library could just use the option "-metadata=keep-all" and the fields would be there. Fields not wished for could be removed with exiftool. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 18:55, 19 May 2024 (UTC)