Server crashes with long running backup, Android maybe running out of ressources

[arminus]

Uploading 2096 images form an Android 8.0 Galaxy A5, device doesn't turn off on its own, StayAlive is active, WiFi is stable (i.e. no connection drops or anything):

• all goes well until ~ 500 images at which point StayAlive apparently gets killed (no more resources from the OS?) and the device/screen turns off
• turn on again, backup resumes
• this happens once more at around 600
• at around 750 the server crashes (i.e. docker container exits) with the following error:

[Nest] 51  - 03/26/2022, 5:14:02 PM     LOG [NewWebSocketConnection] New websocket connection: -4GaZgiZGyx2cd9cAAAJ
[Nest] 51  - 03/26/2022, 5:14:03 PM     LOG Client -4GaZgiZGyx2cd9cAAAJ disconnected
[Nest] 51  - 03/26/2022, 5:14:17 PM     LOG [NewWebSocketConnection] New websocket connection: QCybZ9cILqixmgB5AAAL
[Nest] 51  - 03/26/2022, 5:14:23 PM   ERROR [createUserAsset] Error Create New Asset QueryFailedError: duplicate key value violates unique constraint "UQ_b599ab0bd9574958acb0b30a90e"
/usr/src/app/dist/api-v1/asset/asset.controller.js:40
                await this.assetService.updateThumbnailInfo(savedAsset.id, uploadFiles.thumbnailData[0].path);
                                                                       ^

TypeError: Cannot read properties of undefined (reading 'id')
    at /usr/src/app/dist/api-v1/asset/asset.controller.js:40:72
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

Android apparently killing StayAlive happened again and again after that, server crash only occured once. (but I also observed during a previous full backup test).

The Immich process on Android ate 320mAh of battery for backing up those 2096 images and videos, battery charge went down from > 80% to 30% - which is quite some loss.

[alextran1502]

Thank you for your issue,

For the StayAlive problem, I assume you didn't plug in your phone, I think it could cause Android to force StayAlive to be turned off to preserve battery life.

I will look at the error and provide a catch for that error's exception. I am still not sure why it happened though.

I think Immich consumes a lot of energy because it has to get the thumbnail data by using the phone's processing power.

[arminus]

This is a stress test and I intentionally didn't plug the phone in to see what would happen. Regarding Android killing StayAlive, I'm not sure, I think it kills much more at that point, i.e. the phone was quite sluggish after that happened. But I really have no clue on Android power/RAM/CPU management, I just felt I needed to point that out. Could be some kind of memory leak on Immich's side...

Regarding the thumbnails being created on the phone rather than the server: I read why you did it that way, but that's a trade-off and especially on lower powered or older phones, that might be a problem. Then again, normally one wouldn't back hundreds of photos every day, so maybe that's a moot point.

[alextran1502]

My primary phone is not Android, so I did have some similar tests on an iPhone. I noticed that the phone also gets hotter due to the processing CPU having to work more.

In the grand scheme of things, like you pointed out, this might be the one-off scenario on the first backup. Subsequence backup won't run into the same heat-up issue.

I've been liking the approach of having the thumbnail generated from the phone more than the server, since it is more consistent regardless of media format :)

[alextran1502]

Should be fixed in #78. Please reopen if you have any additional issues with this.

[alextran1502]

@arminus Found the problem that causes server crashes during a long backup session in #97. The fix will be in the next release.