immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-07-25 14:00:45 +03:00
Code Issues 783 Packages Projects Releases 22 Wiki Activity

[Beta] new beta timelime ,same upload loop issue #6871

New Issue
Closed
opened 2026-02-05 12:36:10 +03:00 by OVERLORD · 5 comments
OVERLORD commented 2026-02-05 12:36:10 +03:00
Owner
Copy Link

Originally created by @ronzino83 on GitHub (Aug 17, 2025).

I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.

  • Yes

The bug

New immich server new smartphone new assets new immich android app installation. New timeline enabled

I have about 720 assets that as soon as they are uploaded the server reject them as while the smartphone keep traing again to reupload in an infinite loop. Luckly i have wifi only upload unabled as this joke cost 8gbyte if wasted trafic in an infinite loop.

I have reported a similat issue weeks ago with the old timeline https://github.com/immich-app/immich/discussions/19972

The scanerio is different,the error is the same but the user experience is the same: death lock upload loop.

New beta features on android app

Sync local assets
Sync remote assets
Hash

Does not solve (sometime ,remaing assets count goes negative , for a while)

This known and old issue should had been fixed with the new upload mechanisms but is still there.
Please at least give users a workaround like implement something to ask to the user what he want do to with those problematic assets (like server discard problematic asset and reupload or overwriting broken asset uuid on server side with the one given by android).

The OS that Immich Server is running on

Truenas sce

Version of Immich Server

1.138.0

Version of Immich Mobile App

1.138.0 3003

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

Not relevant

Your .env content

Not relevant

Reproduction steps

Start sync a folder with 15000 assets (80gb about) and simulate connection disconnection app close and reopen (simulating android power efficency kill). You will gets tons of problematic assets and the deadhlock loop will be triggered.

Relevant log output


00error: PostgresError: duplicate key value violates unique constraint "UQ_assets_owner_checksum"
2025-08-16 21:33:02.031046+00:00at ErrorResponse (/usr/src/app/server/node_modules/postgres/cjs/src/connection.js:794:26)
2025-08-16 21:33:02.031053+00:00at handle (/usr/src/app/server/node_modules/postgres/cjs/src/connection.js:480:6)
2025-08-16 21:33:02.031059+00:00at Socket.data (/usr/src/app/server/node_modules/postgres/cjs/src/connection.js:315:9)
2025-08-16 21:33:02.031065+00:00at Socket.emit (node:events:518:28)
2025-08-16 21:33:02.031071+00:00at addChunk (node:internal/streams/readable:561:12)
2025-08-16 21:33:02.031077+00:00at readableAddChunkPushByteMode (node:internal/streams/readable:512:3)
2025-08-16 21:33:02.031083+00:00at Readable.push (node:internal/streams/readable:392:5)
2025-08-16 21:33:02.031089+00:00at TCP.onStreamRead (node:internal/stream_base_commons:189:23)
2025-08-16 21:33:02.031095+00:00at TCP.callbackTrampoline (node:internal/async_hooks:130:17) {
2025-08-16 21:33:02.031101+00:00severity_local: 'ERROR',
2025-08-16 21:33:02.031107+00:00severity: 'ERROR',
2025-08-16 21:33:02.031113+00:00code: '23505',
2025-08-16 21:33:02.031119+00:00detail: 'Key ("ownerId", checksum)=(b0596690-0189-47e5-b8a4-021862d139c2, \\xec05f8678cf26f8c647d6283eaa51b73a5cb073a) already exists.',
2025-08-16 21:33:02.031125+00:00schema_name: 'public',
2025-08-16 21:33:02.031131+00:00table_name: 'asset',
2025-08-16 21:33:02.031136+00:00constraint_name: 'UQ_assets_owner_checksum',
2025-08-16 21:33:02.031142+00:00file: 'nbtinsert.c',
2025-08-16 21:33:02.031148+00:00line: '664',
2025-08-16 21:33:02.031153+00:00routine: '_bt_check_unique'
2025-08-16 21:33:02.031159+00:00},
2025-08-16 21:33:02.031165+00:00sql: 'insert into "asset" ("ownerId", "libraryId", "checksum", "originalPath", "deviceAssetId", "deviceId", "fileCreatedAt", "fileModifiedAt", "localDateTime", "type", "isFavorite", "duration", "visibility", "originalFileName") values ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14) returning *',
2025-08-16 21:33:02.031172+00:00params: [
2025-08-16 21:33:02.031178+00:00'b0596690-0189-47e5-b8a4-021862d139c2',
2025-08-16 21:33:02.031184+00:00null,
2025-08-16 21:33:02.031189+00:00<Buffer ec 05 f8 67 8c f2 6f 8c 64 7d 62 83 ea a5 1b 73 a5 cb 07 3a>,
2025-08-16 21:33:02.031195+00:00'/data/upload/b0596690-0189-47e5-b8a4-021862d139c2/45/71/45712860-9ae9-4fd4-a59a-80e36a8f610f.JPG',
2025-08-16 21:33:02.031201+00:00'1000108772',
2025-08-16 21:33:02.031207+00:00'6e6cc463ff98eaf7d0f2cad40fbdc3593216eca8fac83c687cc80104b6659585',
2025-08-16 21:33:02.031212+00:002025-07-06T11:39:41.140Z,
2025-08-16 21:33:02.031218+00:002020-05-11T00:13:16.000Z,
2025-08-16 21:33:02.031224+00:002025-07-06T11:39:41.140Z,
2025-08-16 21:33:02.031230+00:00'IMAGE',
2025-08-16 21:33:02.031235+00:00false,
2025-08-16 21:33:02.031241+00:00'0',
2025-08-16 21:33:02.031247+00:00'timeline',
2025-08-16 21:33:02.031252+00:00'IMG_7820.JPG'
2025-08-16 21:33:02.031258+00:00]
2025-08-16 21:33:02.031264+00:00}
2025-08-16 21:43:28.110185+00:00[Nest] 25  - 08/16/2025, 11:43:28 PM     LOG [Api:EventRepository] Websocket Connect:    iQyGfYSINUURlsb3AAAP

Additional information

No response

Originally created by @ronzino83 on GitHub (Aug 17, 2025). ### I have searched the existing issues, both open and closed, to make sure this is not a duplicate report. - [x] Yes ### The bug New immich server new smartphone new assets new immich android app installation. New timeline enabled I have about 720 assets that as soon as they are uploaded the server reject them as while the smartphone keep traing again to reupload in an infinite loop. Luckly i have wifi only upload unabled as this joke cost 8gbyte if wasted trafic in an infinite loop. I have reported a similat issue weeks ago with the old timeline https://github.com/immich-app/immich/discussions/19972 The scanerio is different,the error is the same but the user experience is the same: death lock upload loop. New beta features on android app Sync local assets Sync remote assets Hash Does not solve (sometime ,remaing assets count goes negative , for a while) This known and old issue should had been fixed with the new upload mechanisms but is still there. Please at least give users a workaround like implement something to ask to the user what he want do to with those problematic assets (like server discard problematic asset and reupload or overwriting broken asset uuid on server side with the one given by android). ### The OS that Immich Server is running on Truenas sce ### Version of Immich Server 1.138.0 ### Version of Immich Mobile App 1.138.0 3003 ### Platform with the issue - [x] Server - [ ] Web - [x] Mobile ### Your docker-compose.yml content ```YAML Not relevant ``` ### Your .env content ```Shell Not relevant ``` ### Reproduction steps Start sync a folder with 15000 assets (80gb about) and simulate connection disconnection app close and reopen (simulating android power efficency kill). You will gets tons of problematic assets and the deadhlock loop will be triggered. ### Relevant log output ```shell 00error: PostgresError: duplicate key value violates unique constraint "UQ_assets_owner_checksum" 2025-08-16 21:33:02.031046+00:00at ErrorResponse (/usr/src/app/server/node_modules/postgres/cjs/src/connection.js:794:26) 2025-08-16 21:33:02.031053+00:00at handle (/usr/src/app/server/node_modules/postgres/cjs/src/connection.js:480:6) 2025-08-16 21:33:02.031059+00:00at Socket.data (/usr/src/app/server/node_modules/postgres/cjs/src/connection.js:315:9) 2025-08-16 21:33:02.031065+00:00at Socket.emit (node:events:518:28) 2025-08-16 21:33:02.031071+00:00at addChunk (node:internal/streams/readable:561:12) 2025-08-16 21:33:02.031077+00:00at readableAddChunkPushByteMode (node:internal/streams/readable:512:3) 2025-08-16 21:33:02.031083+00:00at Readable.push (node:internal/streams/readable:392:5) 2025-08-16 21:33:02.031089+00:00at TCP.onStreamRead (node:internal/stream_base_commons:189:23) 2025-08-16 21:33:02.031095+00:00at TCP.callbackTrampoline (node:internal/async_hooks:130:17) { 2025-08-16 21:33:02.031101+00:00severity_local: 'ERROR', 2025-08-16 21:33:02.031107+00:00severity: 'ERROR', 2025-08-16 21:33:02.031113+00:00code: '23505', 2025-08-16 21:33:02.031119+00:00detail: 'Key ("ownerId", checksum)=(b0596690-0189-47e5-b8a4-021862d139c2, \\xec05f8678cf26f8c647d6283eaa51b73a5cb073a) already exists.', 2025-08-16 21:33:02.031125+00:00schema_name: 'public', 2025-08-16 21:33:02.031131+00:00table_name: 'asset', 2025-08-16 21:33:02.031136+00:00constraint_name: 'UQ_assets_owner_checksum', 2025-08-16 21:33:02.031142+00:00file: 'nbtinsert.c', 2025-08-16 21:33:02.031148+00:00line: '664', 2025-08-16 21:33:02.031153+00:00routine: '_bt_check_unique' 2025-08-16 21:33:02.031159+00:00}, 2025-08-16 21:33:02.031165+00:00sql: 'insert into "asset" ("ownerId", "libraryId", "checksum", "originalPath", "deviceAssetId", "deviceId", "fileCreatedAt", "fileModifiedAt", "localDateTime", "type", "isFavorite", "duration", "visibility", "originalFileName") values ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14) returning *', 2025-08-16 21:33:02.031172+00:00params: [ 2025-08-16 21:33:02.031178+00:00'b0596690-0189-47e5-b8a4-021862d139c2', 2025-08-16 21:33:02.031184+00:00null, 2025-08-16 21:33:02.031189+00:00<Buffer ec 05 f8 67 8c f2 6f 8c 64 7d 62 83 ea a5 1b 73 a5 cb 07 3a>, 2025-08-16 21:33:02.031195+00:00'/data/upload/b0596690-0189-47e5-b8a4-021862d139c2/45/71/45712860-9ae9-4fd4-a59a-80e36a8f610f.JPG', 2025-08-16 21:33:02.031201+00:00'1000108772', 2025-08-16 21:33:02.031207+00:00'6e6cc463ff98eaf7d0f2cad40fbdc3593216eca8fac83c687cc80104b6659585', 2025-08-16 21:33:02.031212+00:002025-07-06T11:39:41.140Z, 2025-08-16 21:33:02.031218+00:002020-05-11T00:13:16.000Z, 2025-08-16 21:33:02.031224+00:002025-07-06T11:39:41.140Z, 2025-08-16 21:33:02.031230+00:00'IMAGE', 2025-08-16 21:33:02.031235+00:00false, 2025-08-16 21:33:02.031241+00:00'0', 2025-08-16 21:33:02.031247+00:00'timeline', 2025-08-16 21:33:02.031252+00:00'IMG_7820.JPG' 2025-08-16 21:33:02.031258+00:00] 2025-08-16 21:33:02.031264+00:00} 2025-08-16 21:43:28.110185+00:00[Nest] 25 - 08/16/2025, 11:43:28 PM  LOG [Api:EventRepository] Websocket Connect: iQyGfYSINUURlsb3AAAP ``` ### Additional information _No response_
OVERLORD commented 2026-02-05 12:36:12 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Aug 17, 2025):

Can you elaborate on deadlock loop?

@alextran1502 commented on GitHub (Aug 17, 2025): Can you elaborate on deadlock loop?
OVERLORD commented 2026-02-05 12:36:13 +03:00
Author
Owner
Copy Link

@ronzino83 commented on GitHub (Aug 17, 2025):

The client would like to upload assets that are already on the server but with a differnt id (see the posted log). Client upload gigabyte of data, server reject them. Once client as finisched to upload, after a while, it will restsrt to upload the same rejected assets in an infinite wasting loop. I will check if it stopped after midnight server maintenance today and revert tp you

@ronzino83 commented on GitHub (Aug 17, 2025): The client would like to upload assets that are already on the server but with a differnt id (see the posted log). Client upload gigabyte of data, server reject them. Once client as finisched to upload, after a while, it will restsrt to upload the same rejected assets in an infinite wasting loop. I will check if it stopped after midnight server maintenance today and revert tp you
OVERLORD commented 2026-02-05 12:36:14 +03:00
Author
Owner
Copy Link

@mattague commented on GitHub (Aug 19, 2025):

So you closed this without any update. Was it an error in your config or something? I am trying to figure out why my server (v1.138.1) goes offline (per the version indicator in the bottom left) any time I open the mobile app (v1.138.0 build.3003).

@mattague commented on GitHub (Aug 19, 2025): So you closed this without any update. Was it an error in your config or something? I am trying to figure out why my server (v1.138.1) goes offline (per the version indicator in the bottom left) any time I open the mobile app (v1.138.0 build.3003).
OVERLORD commented 2026-02-05 12:36:15 +03:00
Author
Owner
Copy Link

@ronzino83 commented on GitHub (Aug 19, 2025):

After midnight self maintenance task it self fixed. I wonder if there is a way, maybe using API call or CLI of docker, to call manually the midnight task

@ronzino83 commented on GitHub (Aug 19, 2025): After midnight self maintenance task it self fixed. I wonder if there is a way, maybe using API call or CLI of docker, to call manually the midnight task
OVERLORD commented 2026-02-05 12:36:15 +03:00
Author
Owner
Copy Link

@HMKnapp commented on GitHub (Sep 15, 2025):

Same issue. Saw that some pictures in the Android app were marked as non available on the server, but the web version shows them.
So I switched back to disable Beta (Beta seems to be default, I did not enable it). Then the mobile app re-uploads all photos and videos on the device, xxx GB of data just to reject them on server side because they already exist. Why not hash it locally once then compare hash instead of pushing the files?

Imagine this happening via mobile roaming on vacation somewhere roaming is expensive, counted per MB.

After it finished uploading (still shows xxx media remaining, but it stopped), I closed the app, removed it from background (force close).

Restarting the app, it starts uploading all xxx GB again and the handful of photos it shows as "not available on server" are still shown as not available (they are).

While typing this it started pushing all files for a third time...

Before any new features, please just ensure reliable uploads, sane hashing (before upload), just that the basics work and that users don’t have to guess if their photos are there, restart, guess again... Cannot in good conscience recommend Immich to anyone if that doesn’t work and could very likely cause them to receive a five figure phone bill at the end of the month.

@HMKnapp commented on GitHub (Sep 15, 2025): Same issue. Saw that some pictures in the Android app were marked as non available on the server, but the web version shows them. So I switched back to disable Beta (Beta seems to be default, I did not enable it). Then the mobile app re-uploads all photos and videos on the device, xxx GB of data just to reject them on server side because they already exist. Why not hash it locally once then compare hash instead of pushing the files? Imagine this happening via mobile roaming on vacation somewhere roaming is expensive, counted per MB. After it finished uploading (still shows xxx media remaining, but it stopped), I closed the app, removed it from background (force close). Restarting the app, it starts uploading all xxx GB again and the handful of photos it shows as "not available on server" are still shown as not available (they are). While typing this it started pushing all files for a third time... Before any new features, please just ensure reliable uploads, sane hashing (before upload), just that the basics work and that users don’t have to guess if their photos are there, restart, guess again... Cannot in good conscience recommend Immich to anyone if that doesn’t work and could very likely cause them to receive a five figure phone bill at the end of the month.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:skip
changelog:translation
cli
date-time
dependencies
documentation
external-library
format
good first issue
mobile-beta
mobile-beta
mobile-beta
needs-answer
nice to have
pull-request
Mirrored from GitHub Pull Request
 sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#6871
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?