Thanks for reporting. Looks like the issue is “sqlite3.OperationalError: disk I/O error”. Can you contact us at support@mapillary.zendesk.com to share more info about your disk/folder setup which will help us investigate your issue. Thanks!
Does anyone check your email? This is not an ironic question.
This is from today -
[2025-12-31 08:57:42.548] [debug] [mapillary:tools] 08:57:42.557 - INFO - ==> Upload summary
08:57:42.557 - INFO - Nothing uploaded. Bye.[2025-12-31 08:57:42.564] [debug] [mapillary:tools] 08:57:42.558 - ERROR - HTTPError: POST https://rupload.facebook.com/mapillary_public_uploads/mly_tools_0ea833f2eb352d226015c278b5224933.jpg => 400 Bad Request: {“debug_info”: {“retriable”: false, “type”: “StorageWriteFailedError”, “message”: “Failed to write to storage”}}
Traceback (most recent call last):
File “mapillary_tools\commands_main_.py”, line 156, in main
File “mapillary_tools\commands\upload.py”, line 82, in run
File “mapillary_tools\upload.py”, line 121, in upload
File “mapillary_tools\upload.py”, line 112, in upload
File “mapillary_tools\upload.py”, line 629, in _continue_or_fail
File “mapillary_tools\uploader.py”, line 573, in upload_images
File “mapillary_tools\uploader.py”, line 599, in _upload_sequence_and_finish
File “mapillary_tools\uploader.py”, line 594, in _upload_sequence_and_finish
File “mapillary_tools\uploader.py”, line 670, in _upload_images_parallel
File “concurrent\futures_base.py”, line 449, in result
File “concurrent\futures_base.py”, line 401, in __get_result
File “concurrent\futures\thread.py”, line 59, in run
File “mapillary_tools\uploader.py”, line 722, in _upload_images_from_queue
File “mapillary_tools\uploader.py”, line 771, in upload
File “mapillary_tools\uploader.py”, line 879, in upload_stream
File “mapillary_tools\uploader.py”, line 977, in _handle_upload_exception
File “mapillary_tools\uploader.py”, line 862, in upload_stream
File “mapillary_tools\uploader.py”, line 1051, in _upload_stream_retryable
File “mapillary_tools\upload_api_v4.py”, line 163, in upload_shifted_chunks
File “requests\models.py”, line 1026, in raise_for_status
requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: https://rupload.facebook.com/mapillary_public_uploads/mly_tools_0ea833f2eb352d226015c278b5224933.jpg
I’ve tested it. It takes the app now 1 min and 10 seconds to load, and this is a fast PC.
After deleting the upload history folder and the config-xxxx.json file (@GITNE the userinfo is stored in config.json, just for your info), the startup time is around 1 sec.
I’ve made a screenrecording of the startup: Dropbox
Below the upload folder content.
1 Like
Yikes, that is definitely a problem, thank you @TheWizard for the video as well. We will take a look at resolving this. cc: @nikola
1 Like
Should I dare delete
Which are under
according to
Five minutes, three seconds.
After deleting the two files, it is 5 seconds faster.
I uninstalled and also deleted the folder under Roaming. Then I installed and logged in and now it is OK. Thanks for my help.
I only get 2 min 50 sec. How do I catch up to you guys? upload_history folder is 2.6 GB. Deleting it does nothing. Deleting config-xxxx.json makes the launch instant. Of course, I don’t actually want to delete the history. The app’s UI is beyond terrible, but at least the list is there.
This happens when devs do not listen to experienced users. I have pointed out this long time ago by asking @tao for how long should the upload history be stored. I got no answer. Furthermore, I have also pointed out that it is a bad idea to store cache data (like the upload history) in the roaming section of a user profile because nobody wants to wait for hours when logging in and out in a remote user profile configuration environment (this usually means Active Directory on Windows), and that it does not conform to Freedesktop’s XDG Base Directory Specification (which has been created by smart people for good reasons) either. Again, all I got was a shrug. But hey, what do I know? 
I think, you guys should be grateful that you do not log in using remote user profiles because otherwise you would not get done anything with your computers. Or, you would want to stay logged in forever!
1 Like
They do not listen to me either, for very simple, very useful, easy to program things.
Getting a weird bug where the upload size is much bigger than the size of the file and it is just stuck on “Finalizing upload.“ I am now at 3.57 GB uploaded and there is no sign of stopping…
Logs look fine:
[2026-01-18 13:56:24.026] [debug] [mapillary:tools] 13:56:24.027 - DEBUG - UPLOAD_PROGRESS: {“total_sequence_count”: 1, “sequence_idx”: 0, “file_type”: “gopro”, “import_path”: “D:\me\Pictures\GS011323.360”, “sequence_md5sum”: “4de4443188b7193e25f756872037117f”, “entity_size”: 2465343916, “chunk_size”: 2097152, “retries”: 0, “begin_offset”: 1089142768, “upload_start_time”: 1768699343.6504807, “upload_total_time”: 11681.018593549728, “upload_first_offset”: 0, “offset”: 1351286768, “_last_upload_progress_debug_at”: 1768712146.6062756, “upload_last_restart_time”: 1768711045.4046006}
[2026-01-18 13:57:02.470] [debug] [mapillary:tools] 13:57:02.471 - DEBUG - UPLOAD_PROGRESS: {“total_sequence_count”: 1, “sequence_idx”: 0, “file_type”: “gopro”, “import_path”: “D:\me\Pictures\GS011323.360”, “sequence_md5sum”: “4de4443188b7193e25f756872037117f”, “entity_size”: 2465343916, “chunk_size”: 2097152, “retries”: 0, “begin_offset”: 1089142768, “upload_start_time”: 1768699343.6504807, “upload_total_time”: 11681.018593549728, “upload_first_offset”: 0, “offset”: 1359675376, “_last_upload_progress_debug_at”: 1768712184.0278003, “upload_last_restart_time”: 1768711045.4046006}
[2026-01-18 13:57:39.465] [debug] [mapillary:tools] 13:57:39.468 - DEBUG - UPLOAD_PROGRESS: {“total_sequence_count”: 1, “sequence_idx”: 0, “file_type”: “gopro”, “import_path”: “D:\me\Pictures\GS011323.360”, “sequence_md5sum”: “4de4443188b7193e25f756872037117f”, “entity_size”: 2465343916, “chunk_size”: 2097152, “retries”: 0, “begin_offset”: 1089142768, “upload_start_time”: 1768699343.6504807, “upload_total_time”: 11681.018593549728, “upload_first_offset”: 0, “offset”: 1368063984, “_last_upload_progress_debug_at”: 1768712222.4712384, “upload_last_restart_time”: 1768711045.4046006}
[2026-01-18 13:58:14.738] [debug] [mapillary:tools] 13:58:14.738 - DEBUG - UPLOAD_PROGRESS: {“total_sequence_count”: 1, “sequence_idx”: 0, “file_type”: “gopro”, “import_path”: “D:\me\Pictures\GS011323.360”, “sequence_md5sum”: “4de4443188b7193e25f756872037117f”, “entity_size”: 2465343916, “chunk_size”: 2097152, “retries”: 0, “begin_offset”: 1089142768, “upload_start_time”: 1768699343.6504807, “upload_total_time”: 11681.018593549728, “upload_first_offset”: 0, “offset”: 1376452592, “_last_upload_progress_debug_at”: 1768712259.4679167, “upload_last_restart_time”: 1768711045.4046006}
[2026-01-18 13:58:49.403] [debug] [mapillary:tools] 13:58:49.404 - DEBUG - UPLOAD_PROGRESS: {“total_sequence_count”: 1, “sequence_idx”: 0, “file_type”: “gopro”, “import_path”: “D:\me\Pictures\GS011323.360”, “sequence_md5sum”: “4de4443188b7193e25f756872037117f”, “entity_size”: 2465343916, “chunk_size”: 2097152, “retries”: 0, “begin_offset”: 1089142768, “upload_start_time”: 1768699343.6504807, “upload_total_time”: 11681.018593549728, “upload_first_offset”: 0, “offset”: 1384841200, “_last_upload_progress_debug_at”: 1768712294.7385564, “upload_last_restart_time”: 1768711045.4046006}
[2026-01-18 13:59:24.177] [debug] [mapillary:tools] 13:59:24.179 - DEBUG - UPLOAD_PROGRESS: {“total_sequence_count”: 1, “sequence_idx”: 0, “file_type”: “gopro”, “import_path”: “D:\me\Pictures\GS011323.360”, “sequence_md5sum”: “4de4443188b7193e25f756872037117f”, “entity_size”: 2465343916, “chunk_size”: 2097152, “retries”: 0, “begin_offset”: 1089142768, “upload_start_time”: 1768699343.6504807, “upload_total_time”: 11681.018593549728, “upload_first_offset”: 0, “offset”: 1393229808, “_last_upload_progress_debug_at”: 1768712329.4045987, “upload_last_restart_time”: 1768711045.4046006}
[2026-01-18 13:59:58.928] [debug] [mapillary:tools] 13:59:58.929 - DEBUG - UPLOAD_PROGRESS: {“total_sequence_count”: 1, “sequence_idx”: 0, “file_type”: “gopro”, “import_path”: “D:\me\Pictures\GS011323.360”, “sequence_md5sum”: “4de4443188b7193e25f756872037117f”, “entity_size”: 2465343916, “chunk_size”: 2097152, “retries”: 0, “begin_offset”: 1089142768, “upload_start_time”: 1768699343.6504807, “upload_total_time”: 11681.018593549728, “upload_first_offset”: 0, “offset”: 1401618416, “_last_upload_progress_debug_at”: 1768712364.1793642, “upload_last_restart_time”: 1768711045.4046006}
[2026-01-18 14:00:35.119] [debug] [mapillary:tools] 14:00:35.120 - DEBUG - UPLOAD_PROGRESS: {“total_sequence_count”: 1, “sequence_idx”: 0, “file_type”: “gopro”, “import_path”: “D:\me\Pictures\GS011323.360”, “sequence_md5sum”: “4de4443188b7193e25f756872037117f”, “entity_size”: 2465343916, “chunk_size”: 2097152, “retries”: 0, “begin_offset”: 1089142768, “upload_start_time”: 1768699343.6504807, “upload_total_time”: 11681.018593549728, “upload_first_offset”: 0, “offset”: 1410007024, “_last_upload_progress_debug_at”: 1768712398.9292989, “upload_last_restart_time”: 1768711045.4046006}
Interesting, looks like the numbers diverged quite a bit during the upload progress. Were there any other files in this upload? Can you send us your full log to support@mapillary.zendesk.com so we can debug further? Thanks!
Hi. I’m using mapillary-uploader-5.0.3.AppImage on my notebook with an Ubuntu-based Tuxedo OS.
I report two things.
First, I have to run the tool with
./mapillary-uploader-5.0.3.AppImage --no-sandbox
if not, I receive the following error message:
[94102:0202/161049.495126:FATAL:sandbox/linux/suid/client/setuid_sandbox_host.cc:166] The SUID sa
ndbox helper binary was found, but is not configured correctly. Rather than run without sandboxin
g I'm aborting now. You need to make sure that /tmp/.mount_mapillzb38mo/chrome-sandbox is owned b
y root and has mode 4755.
Trace/breakpoint trap
Is this a normal behaviour for Linux-based systems?
Second, when I drag and drop a folder, the upload process immediately starts, without giving me the option to see and review the images.
Is there a way to avoid this?
Best,
Ale
@czecko ,
Thank you for listing both locations where files need to be deleted in order to make Mapillary Desktop Uploader start almost instantaneously.
Would hope that v 5.0.4 comes out soon, with at least two amendments :
a/ upload history will only be loaded when the user clicks the ‘upload history’ button;
b/ an option for the user to limit the uploaded files log to their choice of past 100 or 400 days;
to me, on each upload, waiting ‘ages’ for the upload history going back two or three years to load is a waste of time, and in fact if I ever look at the history it is to check that files which haven’t yet appeared in the app were successfully uploaded and received.
Looking forward,
K
2 Likes