| Summary: | images.album = NULL without reason (disappearing images in DK) | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Kusi <kusi> |
| Component: | Database-Mysql | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | caulier.gilles, kusi, metzpinguin, nd03tzn |
| Priority: | NOR | ||
| Version First Reported In: | 8.3.0 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | 9.0.0 | |
| Sentry Crash Report: | |||
| Attachments: |
digikam log with last good sql revision
digikam log with first bad sql revision |
||
|
Description
Kusi
2024-05-07 21:26:27 UTC
The fact that you have image entries where the album is NULL is a completely normal process in the digiKam database. That's why you don't "lose" any images. For example, when you delete an image, such an entry is created. Maybe the image will be restored from the trash and we can use the database information again. Do you have a concrete example where an image is not displayed in the album and it is present in the file system? Maik Another note: the "sanity check" you want is the initial scan in digiKam, which keeps the entries in the file system in sync with those in the database. Maik Maik, Indeed, an image deleted on the file system is not deleted from the Images table. I missed that part. However, I still see cases, as I said, where the album disappears from Albums table (hence not visible at all in DK), but the folder is still there on the file system. When I run "Scan for new images", the disappeared album doesn't reappear in DK, despite being present as folder on the file system. However, the images are present in the Images table, with Images.album=NULL If I had the images deleted by accident (which I didn't, 99% positive but not more:), the images would have disappeared from the filesystem, right? Since they ARE on the file system, DK should pick them up again, right? So, something is not sane here. And it's not just a single case, it seems reproducible but I didn't yet figure out how. and sorry for the late response :/ If an album exists in the file system but not in digiKam, then either a local collection is not "Online". In digiKam-8.4.0 we mark a collection in the album tree with a red icon if it is not "online". Or the album is read-protected for the digikam user. I'm sure there's no bug in digiKam here. Please create a log from the terminal with active debugging in the digiKam settings under System. Please the log from the start. Maik I nailed down the first occurrence of a specific case where the album disappeared (Images.album = NULL and removed from tbl Album): The same day I upgraded DK from version 8.2 to version 8.3 I will now create a log as you suggested. Thanks for looking into it Maik, much appreciated! Created attachment 169750 [details]
digikam log with last good sql revision
Created attachment 169751 [details]
digikam log with first bad sql revision
Files attached. Most likely the DK upgrade from 8.2 to 8.3 was not the issue, but the appended path to a collection executing "select identifier from AlbumRoots" with last good and first bad sql revision last good: networkshareid:?mountpath=/share/Fotilis&fileuuid=606360a7-139f-46bf-b402-d1309244e351 first bad: networkshareid:?mountpath=/share/Fotilis&mountpath=/Volumes/share/Fotilis&fileuuid=606360a7-139f-46bf-b402-d1309244e351 (background: I wanted to make the sql db accessible from a DK instance running on a Mac, but failed) Why didn't it work on macOS, the networkshareid: seems correct? You have a difference of about 10,000 items between the two scans. If digiKam removes items from albums (and sets them to NULL), then they are not readable by digiKam at the file level. Check the rights for the relevant albums and items. digiKam itself does not change the rights of albums or items. Maik As a test, please also deactivate the option to monitor for external changes to the albums in the digiKam settings under Collections. Maik I've also been having this problem on 8.3.0 and 8.4.0. All images had their album ID removed. I checked in the database and digikam.Images album column was null for ALL images. Strangely all video files did have an album ID. I can see the IDs are starting reappear now (at the rate of about 20 every second) but I really need to know why they were removed. It's possible something I've done but all I did was search for images between two dates and then delete the search. Images get a NULL album if they are no longer found by the initial scanner at the start. There can be various reasons for this. If it is a local collection, make sure that the drive is always available; it should be the boot drive or one that is permanently installed in the computer. Always add external drives as a removable media collection, as there is a possibility that they are not always "online". The same applies to network drives. I am sure that we do not have a bug here, for some reason the images were not visible in the collection for digiKam. Maik Ok so this happened to me again today when I scanned for new items. It cleared out the album field on all images, not on videos. When I scanned a second time it started to add them back in again. Immich was running a metadata scan on the xmp sidecar files at the sametime, so maybe that had a lock on the path? I really can't think of any other reason for this. The collection is on a local or network drive? Are Windows network shares set on this collection? Or is the collection part of a Onedrive or other network sync service? Maik (In reply to Maik Qualmann from comment #14) > The collection is on a local or network drive? Are Windows network shares > set on this collection? Or is the collection part of a Onedrive or other > network sync service? > > Maik This is a local drive. I'm running Digikam inside a docker container and the drive is a mounted volume. This is all inside a Ubuntu environment. Samba shares are enabled for viewing only. With this configuration, it sounds like there are a lot of possibilities that the network drive is not always found by digiKam. For me, the question is how we can prevent this? Because it is clear that digiKam will not "see" the directories when it first reads the drive. Is the Samba share a NAS? Is a standby or energy saving function activated? Maik (In reply to Maik Qualmann from comment #16) > With this configuration, it sounds like there are a lot of possibilities > that the network drive is not always found by digiKam. > > For me, the question is how we can prevent this? Because it is clear that > digiKam will not "see" the directories when it first reads the drive. > > Is the Samba share a NAS? Is a standby or energy saving function activated? > > Maik Just to confirm, this isn't a network drive. It's a local drive attached to the docker container as a mounted volume. The Samba shares are only used for me to view the images on a Windows machine. The drive is local to the Digikam instance and I've never had any other issues with the drive being "offline". I strongly suspect the Immich had a lock on the files while scanning which caused the issue, but that is only a guess. This happened again today. All photos had their album removed in the db when I ran the scan for new items. I had to run it a second time for it to repopulate (which takes around an hour). I wasn't running anything in Immich this time, but I did have the Photos folder open in Windows. Again, maybe some sort of lock? I suspect not but I'm really struggling to think what else is causing this. I thought I'd leave an update on this issue. I've been living with it by restarting Digikam any time I want to import new images. The refresh is unreliable and often marks all my images (not videos) as deleted. I reread the entire thread. You mentioned using digiKam in the Docker image. Don't use it; we've already seen other bug reports with lost MySQL connections. I suspect that after importing images, the network connection is "lost," and that's why digiKam can no longer find files and is removing them. Using digiKam in the Docker image doesn't seem to be working reliably. Maik (In reply to Maik Qualmann from comment #20) > I reread the entire thread. You mentioned using digiKam in the Docker image. > Don't use it; we've already seen other bug reports with lost MySQL > connections. I suspect that after importing images, the network connection > is "lost," and that's why digiKam can no longer find files and is removing > them. Using digiKam in the Docker image doesn't seem to be working reliably. > > Maik Thanks for looking in to this. I'll try Digikam outside of Docker. Upgrading to 8.8.0 fixed the issue for me. I didn't move away from Docker due to the location of my database and images. |