[BUG] Album download reports wrong size during prep #1274

Closed
opened 2026-02-05 01:08:29 +03:00 by OVERLORD · 11 comments
Owner

Originally created by @gcarrarom on GitHub (Aug 23, 2023).

The bug

When sharing a large album with many videos and pictures, downloading the album reports considerably smaller footprint on the banner, then proceeds to be stuck for a while in 100% until it allows the full download to happen.
Example:

  1. Create album with over 100GB of files
  2. Click download
  3. Check the banner:
    CleanShot 2023-08-23 at 13 51 22
  4. Wait a long while after 100% hits.
  5. Check the actual download coming in:
    CleanShot 2023-08-23 at 13 33 09

The OS that Immich Server is running on

Kubernetes

Version of Immich Server

v1.74.0

Version of Immich Mobile App

1.74.0

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

postgresql:
  enabled: true
redis:
  enabled: true

typesense:
  enabled: true
  image:
    repository: docker.io/typesense/typesense
    tag: 0.24.1
    pullPolicy: Always
  persistence:
    tsdata:
      enabled: true
      existingClaim: typesense-data

machine-learning:
  enabled: true
  persistence:
    cache:
      enabled: true
      existingClaim: machinelearning-data
proxy:
  ingress:
    main:
      enabled: true
      ingressClassName: nginx
      annotations:
        cert-manager.io/cluster-issuer: letsencrypt
      hosts:
        - host: immich.fancywhale.ca
          paths:
            - path: "/"
      tls:
        - hosts:
            - immich.fancywhale.ca
          secretName: immich-fancywhale-ca-tls
image:
  tag: v1.74.0 # renovate: datasource=docker depName=altran1502/immich-server versioning=regex:^v(?<major>\d+)\.(?<minor>\d+).(?<patch>\d+)$
immich:
  persistence:
    library:
      existingClaim: photos

Your .env content

postgresql:
  enabled: true
redis:
  enabled: true

typesense:
  enabled: true
  image:
    repository: docker.io/typesense/typesense
    tag: 0.24.1
    pullPolicy: Always
  persistence:
    tsdata:
      enabled: true
      existingClaim: typesense-data

machine-learning:
  enabled: true
  persistence:
    cache:
      enabled: true
      existingClaim: machinelearning-data
proxy:
  ingress:
    main:
      enabled: true
      ingressClassName: nginx
      annotations:
        cert-manager.io/cluster-issuer: letsencrypt
      hosts:
        - host: immich.fancywhale.ca
          paths:
            - path: "/"
      tls:
        - hosts:
            - immich.fancywhale.ca
          secretName: immich-fancywhale-ca-tls
image:
  tag: v1.74.0 # renovate: datasource=docker depName=altran1502/immich-server versioning=regex:^v(?<major>\d+)\.(?<minor>\d+).(?<patch>\d+)$
immich:
  persistence:
    library:
      existingClaim: photos

Reproduction steps

1. Create album with over 100GB of files
2. Click download
3. Check the banner:
![CleanShot 2023-08-23 at 13 51 22](https://github.com/immich-app/immich/assets/10549675/83fdc39d-a6a0-411d-adfb-136bcb1c17f0)
4. Wait a long while after 100% hits. 
5. Check the actual download coming in:
![CleanShot 2023-08-23 at 13 33 09](https://github.com/immich-app/immich/assets/10549675/e535727f-8442-421b-a7c2-780cd79dedd5)

Additional information

No response

Originally created by @gcarrarom on GitHub (Aug 23, 2023). ### The bug When sharing a large album with many videos and pictures, downloading the album reports considerably smaller footprint on the banner, then proceeds to be stuck for a while in 100% until it allows the full download to happen. Example: 1. Create album with over 100GB of files 2. Click download 3. Check the banner: ![CleanShot 2023-08-23 at 13 51 22](https://github.com/immich-app/immich/assets/10549675/83fdc39d-a6a0-411d-adfb-136bcb1c17f0) 4. Wait a long while after 100% hits. 5. Check the actual download coming in: ![CleanShot 2023-08-23 at 13 33 09](https://github.com/immich-app/immich/assets/10549675/e535727f-8442-421b-a7c2-780cd79dedd5) ### The OS that Immich Server is running on Kubernetes ### Version of Immich Server v1.74.0 ### Version of Immich Mobile App 1.74.0 ### Platform with the issue - [ ] Server - [X] Web - [ ] Mobile ### Your docker-compose.yml content ```YAML postgresql: enabled: true redis: enabled: true typesense: enabled: true image: repository: docker.io/typesense/typesense tag: 0.24.1 pullPolicy: Always persistence: tsdata: enabled: true existingClaim: typesense-data machine-learning: enabled: true persistence: cache: enabled: true existingClaim: machinelearning-data proxy: ingress: main: enabled: true ingressClassName: nginx annotations: cert-manager.io/cluster-issuer: letsencrypt hosts: - host: immich.fancywhale.ca paths: - path: "/" tls: - hosts: - immich.fancywhale.ca secretName: immich-fancywhale-ca-tls image: tag: v1.74.0 # renovate: datasource=docker depName=altran1502/immich-server versioning=regex:^v(?<major>\d+)\.(?<minor>\d+).(?<patch>\d+)$ immich: persistence: library: existingClaim: photos ``` ### Your .env content ```Shell postgresql: enabled: true redis: enabled: true typesense: enabled: true image: repository: docker.io/typesense/typesense tag: 0.24.1 pullPolicy: Always persistence: tsdata: enabled: true existingClaim: typesense-data machine-learning: enabled: true persistence: cache: enabled: true existingClaim: machinelearning-data proxy: ingress: main: enabled: true ingressClassName: nginx annotations: cert-manager.io/cluster-issuer: letsencrypt hosts: - host: immich.fancywhale.ca paths: - path: "/" tls: - hosts: - immich.fancywhale.ca secretName: immich-fancywhale-ca-tls image: tag: v1.74.0 # renovate: datasource=docker depName=altran1502/immich-server versioning=regex:^v(?<major>\d+)\.(?<minor>\d+).(?<patch>\d+)$ immich: persistence: library: existingClaim: photos ``` ### Reproduction steps ```bash 1. Create album with over 100GB of files 2. Click download 3. Check the banner: ![CleanShot 2023-08-23 at 13 51 22](https://github.com/immich-app/immich/assets/10549675/83fdc39d-a6a0-411d-adfb-136bcb1c17f0) 4. Wait a long while after 100% hits. 5. Check the actual download coming in: ![CleanShot 2023-08-23 at 13 33 09](https://github.com/immich-app/immich/assets/10549675/e535727f-8442-421b-a7c2-780cd79dedd5) ``` ### Additional information _No response_
OVERLORD added the good first issue label 2026-02-05 01:08:29 +03:00
Author
Owner

@danieldietzler commented on GitHub (Sep 12, 2023):

Hey @gcarrarom!
Could you provide some more information to get an idea of what exactly is going wrong?

  • So you mentioned the album had both images and videos. What is the rough ratio between them? Do you also have live photos?
  • How many assets are in the album?
  • What is the total size of all downloaded files when you unzip them? Does it match the zip archive size?

And lastly two more sanity checks:

  • The number of files in the archive matches the number of assets in the album, right?
  • The screenshots refer to the same download, so you actually downloaded ~160GB of files but Immich only showed ~700MiB?

Any help/additional information would be much appreciated.
Immich seems to be so far off that it is quite mind-boggling xD

@danieldietzler commented on GitHub (Sep 12, 2023): Hey @gcarrarom! Could you provide some more information to get an idea of what exactly is going wrong? - So you mentioned the album had both images and videos. What is the rough ratio between them? Do you also have live photos? - How many assets are in the album? - What is the total size of all downloaded files when you unzip them? Does it match the zip archive size? And lastly two more sanity checks: - The number of files in the archive matches the number of assets in the album, right? - The screenshots refer to the same download, so you actually downloaded ~160GB of files but Immich only showed ~700MiB? Any help/additional information would be much appreciated. Immich seems to be so far off that it is quite mind-boggling xD
Author
Owner

@gcarrarom commented on GitHub (Sep 12, 2023):

Hey @danieldietzler

So you mentioned the album had both images and videos. What is the rough ratio between them? Do you also have live photos?

This specific Album has 578 items: 302 are videos, 276 are images. Most images are live photos.

What is the total size of all downloaded files when you unzip them? Does
it match the zip archive size?

Yep, same size essentially

The number of files in the archive matches the number of assets in the album, right?

Yes

The screenshots refer to the same download, so you actually downloaded ~160GB of files but Immich only showed ~700MiB?

That's right!

  1. I click o download on the album.
  2. Shows the 700MB download progress bar
  3. remains stuck in100% for a while
  4. many minutes later, the much heavier download starts and it has the correct assets.

The assets are definitely much larger than 700MB. The size of the compressed artifact is correct, it should be around 160 GB, not 700MB. Something tells me that immich is not accounting for all the files or the actual size of the files when preparing the zip file.

During the zip file preparation, the server pod spikes to larger usage:
immich-server-78dd9dd7c7-wgvg5 688m 1872Mi
CleanShot 2023-09-12 at 10 24 47

I am now timing how long it takes to get a response with the actual download after the progress bar hits 100%. I'll report back with timing.
I will also create another album with less personal photos so I can share a link in which you can reproduce the same.

@gcarrarom commented on GitHub (Sep 12, 2023): Hey @danieldietzler > So you mentioned the album had both images and videos. What is the rough ratio between them? Do you also have live photos? This specific Album has 578 items: 302 are videos, 276 are images. Most images are live photos. > What is the total size of all downloaded files when you unzip them? Does it match the zip archive size? Yep, same size essentially > The number of files in the archive matches the number of assets in the album, right? Yes > The screenshots refer to the same download, so you actually downloaded ~160GB of files but Immich only showed ~700MiB? That's right! 1. I click o download on the album. 2. Shows the 700MB download progress bar 3. remains stuck in100% for a while 4. many minutes later, the much heavier download starts and it has the correct assets. The assets are definitely much larger than 700MB. The size of the compressed artifact is correct, it should be around 160 GB, not 700MB. Something tells me that immich is not accounting for all the files or the actual size of the files when preparing the zip file. During the zip file preparation, the server pod spikes to larger usage: immich-server-78dd9dd7c7-wgvg5 688m 1872Mi ![CleanShot 2023-09-12 at 10 24 47](https://github.com/immich-app/immich/assets/10549675/52e99fb5-a299-4a9f-b3d4-89cedbdfbdd0) I am now timing how long it takes to get a response with the actual download after the progress bar hits 100%. I'll report back with timing. I will also create another album with less personal photos so I can share a link in which you can reproduce the same.
Author
Owner

@danieldietzler commented on GitHub (Sep 12, 2023):

Thanks a lot! I will have a look at it and hopefully figure out what's going on :)

@danieldietzler commented on GitHub (Sep 12, 2023): Thanks a lot! I will have a look at it and hopefully figure out what's going on :)
Author
Owner

@danieldietzler commented on GitHub (Sep 12, 2023):

I will also create another album with less personal photos so I can share a link in which you can reproduce the same.

That would be really awesome if you could do that!

@danieldietzler commented on GitHub (Sep 12, 2023): > I will also create another album with less personal photos so I can share a link in which you can reproduce the same. That would be really awesome if you could do that!
Author
Owner

@gcarrarom commented on GitHub (Sep 12, 2023):

Got it! It's a bit smaller and has a similar behaviour - just much faster than the 160GB version of this 🤣.
This shows 1.2 GB download, but it takes a bit longer after it hits 100%. But here are the files downloaded:

09:48:15 🏠/Downloads at ☸️ fancy_local_k3s (immich)
zsh ⌁ du -sh Immich\ troubleshooting
1.7G	Immich troubleshooting
(base)
09:50:27 🏠/Downloads at ☸️ fancy_local_k3s (immich)
zsh ⌁ du -sh Immich\ troubleshooting.zip
1.8G	Immich troubleshooting.zip

And here's when we click download:
CleanShot 2023-09-12 at 10 51 41

https://fncy.ca/immich-download-troubleshooting

Let me know if you need anything else to help troubleshoot.

More information on the album I've created for this:

09:53:14 🏠/Downloads at ☸️ fancy_local_k3s (immich)
zsh ⌁ curl -L -X GET 'https://immich.fancywhale.ca/api/album/b341d897-5b2d-41b4-a82c-389fb44da079' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer REDACTED' | jq '.assets | length'
21

09:53:40 🏠/Downloads at ☸️ fancy_local_k3s (immich)
zsh ⌁ curl -L -X GET 'https://immich.fancywhale.ca/api/album/b341d897-5b2d-41b4-a82c-389fb44da079' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer REDACTED' | jq '[.assets[] | select(.type == "VIDEO")] | 
10
@gcarrarom commented on GitHub (Sep 12, 2023): Got it! It's a bit smaller and has a similar behaviour - just much faster than the 160GB version of this 🤣. This shows 1.2 GB download, but it takes a bit longer after it hits 100%. But here are the files downloaded: ``` 09:48:15 🏠/Downloads at ☸️ fancy_local_k3s (immich) zsh ⌁ du -sh Immich\ troubleshooting 1.7G Immich troubleshooting (base) 09:50:27 🏠/Downloads at ☸️ fancy_local_k3s (immich) zsh ⌁ du -sh Immich\ troubleshooting.zip 1.8G Immich troubleshooting.zip ``` And here's when we click download: ![CleanShot 2023-09-12 at 10 51 41](https://github.com/immich-app/immich/assets/10549675/a3ddeaaa-37f3-48d5-b139-2d7a4ef22d2f) https://fncy.ca/immich-download-troubleshooting Let me know if you need anything else to help troubleshoot. More information on the album I've created for this: ``` 09:53:14 🏠/Downloads at ☸️ fancy_local_k3s (immich) zsh ⌁ curl -L -X GET 'https://immich.fancywhale.ca/api/album/b341d897-5b2d-41b4-a82c-389fb44da079' \ -H 'Accept: application/json' \ -H 'Authorization: Bearer REDACTED' | jq '.assets | length' 21 09:53:40 🏠/Downloads at ☸️ fancy_local_k3s (immich) zsh ⌁ curl -L -X GET 'https://immich.fancywhale.ca/api/album/b341d897-5b2d-41b4-a82c-389fb44da079' \ -H 'Accept: application/json' \ -H 'Authorization: Bearer REDACTED' | jq '[.assets[] | select(.type == "VIDEO")] | 10 ```
Author
Owner

@jrasm91 commented on GitHub (Sep 12, 2023):

Can you run this on your database?

I am guessing you have some assets with no exif.fileSizeInByte data. We used to not extract this information (or any exif data) for the motion part of live photos. If I upload the same assets and re-download them on my dev instance, I get an estimated archive size of 1865700415, while yours is sending back (and the sql total below probably adds up to) 1243214118.

TLDR - the discrepancy is probably due to some assets you uploaded a long time ago that don't have any size information.

-- select SUM("fileSizeInByte"::int) from "exif" where "assetId" in  (
select 
  "assetId", "originalFileName", "fileSizeInByte" 
from 
  "exif" 
left join
  "assets" on "assets"."id" = "exif"."assetId" 
where
  "assetId" in (
    '0c97c2b5-bd04-42ed-b0bf-12900fe62f60',
    '5e43265c-83b6-41bb-b2fe-58c6009484b4',
    'eff71ae0-10ec-40d0-939f-866054792eae',
    '5f2897bd-3898-4e1c-a7fe-3315bc397a2a',
    'fd88b53b-fe04-435b-b677-e88cbfc9fde6',
    'a62bed4b-afa3-4b2a-877d-47f1d785470c',
    '50becf35-b63c-43fc-981b-bd68959c8dbd',
    '28c11bfc-52ec-47de-b88c-8efa7f1bade7',
    'b5faa1ed-7d1a-4a44-994e-89a4eafc2ae5',
    'c5c14f66-85c6-4617-a1a5-7843b59eec70',
    'a50791a3-ec02-41b1-8c9c-78f12af44ec3',
    'cf8feee3-571f-40e4-909b-a34f93f56bfc',
    'b25fd419-72ee-4918-9d44-cad7d32f3b2f',
    'c6dc8aa9-4cb9-4e34-a770-0e7a1d7359c8',
    '946981cc-6248-4709-bb9f-b35e216aac21',
    'fdc120a4-8e63-47ee-ab18-15c3a9e137cb',
    '6b001496-bed3-4b33-bb6e-17b67c95996d',
    '2ede3de8-9f5a-4c17-854a-56e7ae673a84',
    '5bf24ed3-02c9-4f83-baa9-958ff05770c4',
    '32a1e6ae-05a6-47f4-8af1-75ffdc4fba97',
    '72a80c79-05c5-49c4-a5d5-0e96ada4a423',
    '02854fc7-7bef-4653-9abc-0b86ce4e80f8',
    '0a14a2ea-5dde-4425-a38f-8c7f3520902c',
    '2462bb27-2422-4bcf-be5e-f797cf495858',
    'eb70af2d-ab6a-4612-8f86-4245672ba3e3'
  )
@jrasm91 commented on GitHub (Sep 12, 2023): Can you run this on your database? I am guessing you have some assets with no `exif.fileSizeInByte` data. We used to not extract this information (or any exif data) for the motion part of live photos. If I upload the same assets and re-download them on my dev instance, I get an estimated archive size of `1865700415`, while yours is sending back (and the sql total below probably adds up to) `1243214118`. TLDR - the discrepancy is probably due to some assets you uploaded a long time ago that don't have any size information. ```sql -- select SUM("fileSizeInByte"::int) from "exif" where "assetId" in ( select "assetId", "originalFileName", "fileSizeInByte" from "exif" left join "assets" on "assets"."id" = "exif"."assetId" where "assetId" in ( '0c97c2b5-bd04-42ed-b0bf-12900fe62f60', '5e43265c-83b6-41bb-b2fe-58c6009484b4', 'eff71ae0-10ec-40d0-939f-866054792eae', '5f2897bd-3898-4e1c-a7fe-3315bc397a2a', 'fd88b53b-fe04-435b-b677-e88cbfc9fde6', 'a62bed4b-afa3-4b2a-877d-47f1d785470c', '50becf35-b63c-43fc-981b-bd68959c8dbd', '28c11bfc-52ec-47de-b88c-8efa7f1bade7', 'b5faa1ed-7d1a-4a44-994e-89a4eafc2ae5', 'c5c14f66-85c6-4617-a1a5-7843b59eec70', 'a50791a3-ec02-41b1-8c9c-78f12af44ec3', 'cf8feee3-571f-40e4-909b-a34f93f56bfc', 'b25fd419-72ee-4918-9d44-cad7d32f3b2f', 'c6dc8aa9-4cb9-4e34-a770-0e7a1d7359c8', '946981cc-6248-4709-bb9f-b35e216aac21', 'fdc120a4-8e63-47ee-ab18-15c3a9e137cb', '6b001496-bed3-4b33-bb6e-17b67c95996d', '2ede3de8-9f5a-4c17-854a-56e7ae673a84', '5bf24ed3-02c9-4f83-baa9-958ff05770c4', '32a1e6ae-05a6-47f4-8af1-75ffdc4fba97', '72a80c79-05c5-49c4-a5d5-0e96ada4a423', '02854fc7-7bef-4653-9abc-0b86ce4e80f8', '0a14a2ea-5dde-4425-a38f-8c7f3520902c', '2462bb27-2422-4bcf-be5e-f797cf495858', 'eb70af2d-ab6a-4612-8f86-4245672ba3e3' ) ```
Author
Owner

@gcarrarom commented on GitHub (Sep 12, 2023):

Oh! That does make a lot of sense! How could I force Immich to check that on my files? Here are the responses from the queries:

Sum:

1243214118

Each:

6b001496-bed3-4b33-bb6e-17b67c95996d	IMG_4916	2687900
2ede3de8-9f5a-4c17-854a-56e7ae673a84	IMG_4807	2211868
cf8feee3-571f-40e4-909b-a34f93f56bfc	IMG_4902	372839
b25fd419-72ee-4918-9d44-cad7d32f3b2f	IMG_4900	1241215
c6dc8aa9-4cb9-4e34-a770-0e7a1d7359c8	IMG_4946	43416
fdc120a4-8e63-47ee-ab18-15c3a9e137cb	IMG_4944	1013064
946981cc-6248-4709-bb9f-b35e216aac21	IMG_4945	296998879
5f2897bd-3898-4e1c-a7fe-3315bc397a2a	IMG_5070	1074536
fd88b53b-fe04-435b-b677-e88cbfc9fde6	IMG_5048	10722472
a62bed4b-afa3-4b2a-877d-47f1d785470c	IMG_5047	344976850
50becf35-b63c-43fc-981b-bd68959c8dbd	IMG_5042	143993144
28c11bfc-52ec-47de-b88c-8efa7f1bade7	IMG_5066	687560
b5faa1ed-7d1a-4a44-994e-89a4eafc2ae5	IMG_4992	41798963
0c97c2b5-bd04-42ed-b0bf-12900fe62f60	IMG_5014	273700930
a50791a3-ec02-41b1-8c9c-78f12af44ec3	IMG_4988	2389640
5e43265c-83b6-41bb-b2fe-58c6009484b4	IMG_5190	1540585
eff71ae0-10ec-40d0-939f-866054792eae	IMG_5189	1483740
c5c14f66-85c6-4617-a1a5-7843b59eec70	IMG_4964	116276517

Thanks for helping guys! Great to know the cause of this already!

@gcarrarom commented on GitHub (Sep 12, 2023): Oh! That does make a lot of sense! How could I force Immich to check that on my files? Here are the responses from the queries: Sum: ``` 1243214118 ``` Each: ``` 6b001496-bed3-4b33-bb6e-17b67c95996d IMG_4916 2687900 2ede3de8-9f5a-4c17-854a-56e7ae673a84 IMG_4807 2211868 cf8feee3-571f-40e4-909b-a34f93f56bfc IMG_4902 372839 b25fd419-72ee-4918-9d44-cad7d32f3b2f IMG_4900 1241215 c6dc8aa9-4cb9-4e34-a770-0e7a1d7359c8 IMG_4946 43416 fdc120a4-8e63-47ee-ab18-15c3a9e137cb IMG_4944 1013064 946981cc-6248-4709-bb9f-b35e216aac21 IMG_4945 296998879 5f2897bd-3898-4e1c-a7fe-3315bc397a2a IMG_5070 1074536 fd88b53b-fe04-435b-b677-e88cbfc9fde6 IMG_5048 10722472 a62bed4b-afa3-4b2a-877d-47f1d785470c IMG_5047 344976850 50becf35-b63c-43fc-981b-bd68959c8dbd IMG_5042 143993144 28c11bfc-52ec-47de-b88c-8efa7f1bade7 IMG_5066 687560 b5faa1ed-7d1a-4a44-994e-89a4eafc2ae5 IMG_4992 41798963 0c97c2b5-bd04-42ed-b0bf-12900fe62f60 IMG_5014 273700930 a50791a3-ec02-41b1-8c9c-78f12af44ec3 IMG_4988 2389640 5e43265c-83b6-41bb-b2fe-58c6009484b4 IMG_5190 1540585 eff71ae0-10ec-40d0-939f-866054792eae IMG_5189 1483740 c5c14f66-85c6-4617-a1a5-7843b59eec70 IMG_4964 116276517 ``` Thanks for helping guys! Great to know the cause of this already!
Author
Owner

@jrasm91 commented on GitHub (Sep 12, 2023):

Based on the results, it looks like you have some normal videos with missing exif data in addition to a few live photos with missing exif for the motion portions.

There is no easy way to re-run exif extraction for hidden videos, as those are ignore. We can take a look at this though.

You should be able to run the metadata extraction job for "missing" and it'll try to re-process the 3 videos (and probably more files in your library). They either will be successful and you're good to go, or they don't have and will continue to not have exif because of some error in the process, in which case you will need to look at the immich-microservices logs for more information about why they failed.

If you find problematic files you can see if there are existing issues for them. I know specifically with metadata extraction for videos there are some WIP stuff happening in that area.

@jrasm91 commented on GitHub (Sep 12, 2023): Based on the results, it looks like you have some normal videos with missing exif data in addition to a few live photos with missing exif for the motion portions. There is no easy way to re-run exif extraction for hidden videos, as those are ignore. We can take a look at this though. You should be able to run the metadata extraction job for "missing" and it'll try to re-process the 3 videos (and probably more files in your library). They either will be successful and you're good to go, or they don't have and will continue to not have exif because of some error in the process, in which case you will need to look at the `immich-microservices` logs for more information about why they failed. If you find problematic files you can see if there are existing issues for them. I know specifically with metadata extraction for videos there are some WIP stuff happening in that area.
Author
Owner

@danieldietzler commented on GitHub (Sep 12, 2023):

Feel free to delete the shared album again. We don't need it anymore :)

@danieldietzler commented on GitHub (Sep 12, 2023): Feel free to delete the shared album again. We don't need it anymore :)
Author
Owner

@gcarrarom commented on GitHub (Sep 12, 2023):

Interestingly enough, the extract metadata completed mighty fast and showed a few errors. But nothing has changed.
Here's an example of each of the errors that happened:

[Nest] 7  - 09/12/2023, 4:54:00 PM   ERROR [JobService] Unable to run job handler: QueryFailedError: duplicate key value violates unique constraint "UQ_16294b83fa8c0149719a1f631ef"
[Nest] 7  - 09/12/2023, 4:54:00 PM   ERROR [JobService] QueryFailedError: duplicate key value violates unique constraint "UQ_16294b83fa8c0149719a1f631ef"
    at PostgresQueryRunner.query (/usr/src/app/node_modules/typeorm/driver/postgres/PostgresQueryRunner.js:211:19)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async UpdateQueryBuilder.execute (/usr/src/app/node_modules/typeorm/query-builder/UpdateQueryBuilder.js:83:33)
    at async updateSubject (/usr/src/app/node_modules/typeorm/persistence/SubjectExecutor.js:380:38)
    at async Promise.all (index 0)
    at async SubjectExecutor.executeUpdateOperations (/usr/src/app/node_modules/typeorm/persistence/SubjectExecutor.js:422:9)
    at async SubjectExecutor.execute (/usr/src/app/node_modules/typeorm/persistence/SubjectExecutor.js:99:9)
    at async EntityPersistExecutor.execute (/usr/src/app/node_modules/typeorm/persistence/EntityPersistExecutor.js:140:21)
    at async AssetRepository.save (/usr/src/app/dist/infra/repositories/asset.repository.js:120:24)
    at async MetadataExtractionProcessor.handleLivePhotoLinking (/usr/src/app/dist/microservices/processors/metadata-extraction.processor.js:95:9)
[Nest] 7  - 09/12/2023, 4:54:00 PM   ERROR [JobService] Object:
{
  "id": "780f2fd4-8968-434c-9cc1-a132525070c8"
}


[Nest] 7  - 09/12/2023, 4:53:39 PM   ERROR [JobService] Error: ffprobe exited with code 1
ffprobe version 6.0-Jellyfin Copyright (c) 2007-2023 the FFmpeg developers
  built with gcc 12 (Debian 12.2.0-14)
  configuration: --prefix=/usr/lib/jellyfin-ffmpeg --target-os=linux --extra-version=Jellyfin --disable-doc --disable-ffplay --disable-ptx-compression --disable-static --disable-libxcb --disable-sdl2 --disable-xlib --enable-lto --enable-gpl --enable-version3 --enable-shared --enable-gmp --enable-gnutls --enable-chromaprint --enable-libdrm --enable-libass --enable-libfreetype --enable-libfribidi --enable-libfontconfig --enable-libbluray --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libopenmpt --enable-libdav1d --enable-libwebp --enable-libvpx --enable-libx264 --enable-libx265 --enable-libzvbi --enable-libzimg --enable-libfdk-aac --arch=amd64 --enable-libsvtav1 --enable-libshaderc --enable-libplacebo --enable-vulkan --enable-opencl --enable-vaapi --enable-amf --enable-libvpl --enable-ffnvcodec --enable-cuda --enable-cuda-llvm --enable-cuvid --enable-nvdec --enable-nvenc
  libavutil      58.  2.100 / 58.  2.100
  libavcodec     60.  3.100 / 60.  3.100
  libavformat    60.  3.100 / 60.  3.100
  libavdevice    60.  1.100 / 60.  1.100
  libavfilter     9.  3.100 /  9.  3.100
  libswscale      7.  1.100 /  7.  1.100
  libswresample   4. 10.100 /  4. 10.100
  libpostproc    57.  1.100 / 57.  1.100
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x397ca190180] moov atom not found
upload/upload/cd4afb29-fb65-4511-9827-947542f03fc8/a253433b-7eab-47a4-b479-5322dfe42da1.MOV: Invalid data found when processing input

    at ChildProcess.<anonymous> (/usr/src/app/node_modules/fluent-ffmpeg/lib/ffprobe.js:233:22)
    at ChildProcess.emit (node:events:514:28)
    at ChildProcess._handle.onexit (node:internal/child_process:291:12)
[Nest] 7  - 09/12/2023, 4:53:39 PM   ERROR [JobService] Object:
{
  "id": "562ad94a-ef7a-4c80-a80e-3fd4e399b0d8"
}

The error messages only happened for a few - 5 items - though. Probably not the ones that this issue is coming from. I'll try to run this for All instead and report back.

@danieldietzler , thanks! Removed the album.

@gcarrarom commented on GitHub (Sep 12, 2023): Interestingly enough, the extract metadata completed mighty fast and showed a few errors. But nothing has changed. Here's an example of each of the errors that happened: ``` [Nest] 7 - 09/12/2023, 4:54:00 PM ERROR [JobService] Unable to run job handler: QueryFailedError: duplicate key value violates unique constraint "UQ_16294b83fa8c0149719a1f631ef" [Nest] 7 - 09/12/2023, 4:54:00 PM ERROR [JobService] QueryFailedError: duplicate key value violates unique constraint "UQ_16294b83fa8c0149719a1f631ef" at PostgresQueryRunner.query (/usr/src/app/node_modules/typeorm/driver/postgres/PostgresQueryRunner.js:211:19) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) at async UpdateQueryBuilder.execute (/usr/src/app/node_modules/typeorm/query-builder/UpdateQueryBuilder.js:83:33) at async updateSubject (/usr/src/app/node_modules/typeorm/persistence/SubjectExecutor.js:380:38) at async Promise.all (index 0) at async SubjectExecutor.executeUpdateOperations (/usr/src/app/node_modules/typeorm/persistence/SubjectExecutor.js:422:9) at async SubjectExecutor.execute (/usr/src/app/node_modules/typeorm/persistence/SubjectExecutor.js:99:9) at async EntityPersistExecutor.execute (/usr/src/app/node_modules/typeorm/persistence/EntityPersistExecutor.js:140:21) at async AssetRepository.save (/usr/src/app/dist/infra/repositories/asset.repository.js:120:24) at async MetadataExtractionProcessor.handleLivePhotoLinking (/usr/src/app/dist/microservices/processors/metadata-extraction.processor.js:95:9) [Nest] 7 - 09/12/2023, 4:54:00 PM ERROR [JobService] Object: { "id": "780f2fd4-8968-434c-9cc1-a132525070c8" } [Nest] 7 - 09/12/2023, 4:53:39 PM ERROR [JobService] Error: ffprobe exited with code 1 ffprobe version 6.0-Jellyfin Copyright (c) 2007-2023 the FFmpeg developers built with gcc 12 (Debian 12.2.0-14) configuration: --prefix=/usr/lib/jellyfin-ffmpeg --target-os=linux --extra-version=Jellyfin --disable-doc --disable-ffplay --disable-ptx-compression --disable-static --disable-libxcb --disable-sdl2 --disable-xlib --enable-lto --enable-gpl --enable-version3 --enable-shared --enable-gmp --enable-gnutls --enable-chromaprint --enable-libdrm --enable-libass --enable-libfreetype --enable-libfribidi --enable-libfontconfig --enable-libbluray --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libopenmpt --enable-libdav1d --enable-libwebp --enable-libvpx --enable-libx264 --enable-libx265 --enable-libzvbi --enable-libzimg --enable-libfdk-aac --arch=amd64 --enable-libsvtav1 --enable-libshaderc --enable-libplacebo --enable-vulkan --enable-opencl --enable-vaapi --enable-amf --enable-libvpl --enable-ffnvcodec --enable-cuda --enable-cuda-llvm --enable-cuvid --enable-nvdec --enable-nvenc libavutil 58. 2.100 / 58. 2.100 libavcodec 60. 3.100 / 60. 3.100 libavformat 60. 3.100 / 60. 3.100 libavdevice 60. 1.100 / 60. 1.100 libavfilter 9. 3.100 / 9. 3.100 libswscale 7. 1.100 / 7. 1.100 libswresample 4. 10.100 / 4. 10.100 libpostproc 57. 1.100 / 57. 1.100 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x397ca190180] moov atom not found upload/upload/cd4afb29-fb65-4511-9827-947542f03fc8/a253433b-7eab-47a4-b479-5322dfe42da1.MOV: Invalid data found when processing input at ChildProcess.<anonymous> (/usr/src/app/node_modules/fluent-ffmpeg/lib/ffprobe.js:233:22) at ChildProcess.emit (node:events:514:28) at ChildProcess._handle.onexit (node:internal/child_process:291:12) [Nest] 7 - 09/12/2023, 4:53:39 PM ERROR [JobService] Object: { "id": "562ad94a-ef7a-4c80-a80e-3fd4e399b0d8" } ``` The error messages only happened for a few - 5 items - though. Probably not the ones that this issue is coming from. I'll try to run this for All instead and report back. @danieldietzler , thanks! Removed the album.
Author
Owner

@gcarrarom commented on GitHub (Sep 12, 2023):

Much better! Thank you!
CleanShot 2023-09-12 at 16 08 32

@gcarrarom commented on GitHub (Sep 12, 2023): Much better! Thank you! ![CleanShot 2023-09-12 at 16 08 32](https://github.com/immich-app/immich/assets/10549675/fee1902a-e162-4965-8abe-e4059d549dbe)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#1274