[digikam] [Bug 482132] When renaming an album, all collections' trees are expanded (windows and kde neon)
https://bugs.kde.org/show_bug.cgi?id=482132 --- Comment #10 from guenael --- There it is : using Right-Click and Rename works well. It's using "Properties" that provokes the trees expansion. I use Properties by habit, no reason else. Can you reproduce it now ? I'll tell you if this is also true on Win 10 tomorrow. I don't use Snap. I installed Digikam using pkcon (eg Neon wrapper for apt). I install my apps with pkcon (generic + private ppa's) or flathub. Should I prefer one method? I installed Digikam on both my Win10 and my father's using chocolatey, for the record. My father has a big db: 56 000 objects, several collections, lots of directories. Mine is much smaller, a few thousand photos and much simpler tree. I'm not sure this is part of the issue. I realize now that lead wasn't relevant, sorry for that. I'll try the 8.3 pre-release. I used X11 until yesterday and for now Wayland works ... perfectly well. Nothing to complain so far but I'll give it a try for a few days before making a decision. I'm agnostic on the matter and not technical enough to grasp the stakes between the two. I would not be surprised to move back to X11 : it has been fine for me for quite a few years. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 482132] When renaming an album, all collections' trees are expanded (windows and kde neon)
https://bugs.kde.org/show_bug.cgi?id=482132 --- Comment #14 from guenael --- Awesome! Thank you for your fortitude into solving this! My best regards to you and Gilles, and the whole team for Digikam - this such useful tool. We use it for family memories, like many obviously. The important thing here it that it brings a lot of happiness in this world: that's an important job you're doing. And it keeps that away from surveillance states (that even democracies have become) and greedy global corporations. That's important work and something to be proud of. Sorry if that feels a bit over, I needed to express my gratitude! Best regards. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 482132] New: When renaming an album, all collections' trees are expanded (windows and kde neon)
https://bugs.kde.org/show_bug.cgi?id=482132 Bug ID: 482132 Summary: When renaming an album, all collections' trees are expanded (windows and kde neon) Classification: Applications Product: digikam Version: 8.2.0 Platform: Neon OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Albums-TreeView Assignee: digikam-bugs-n...@kde.org Reporter: g...@zai.re Target Milestone: --- SUMMARY When renaming an album, all collections' trees are expanded. In the collection tree where that album is, the whole tree is expanding. In other trees, only the first level. Observed on Win 10 and KDE Neon. STEPS TO REPRODUCE 1. Right-click in the tree, select Collapse all albums 2. Open a tree, select an album and rename it OBSERVED RESULT All the trees expand as described EXPECTED RESULT The trees stay as they were with the album renamed. SOFTWARE/OS VERSIONS Windows: 10 KDE Plasma: Neon with Plasma 5.27 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 482132] When renaming an album, all collections' trees are expanded (windows and kde neon)
https://bugs.kde.org/show_bug.cgi?id=482132 guenael changed: What|Removed |Added CC||g...@zai.re --- Comment #1 from guenael --- Not a big bug, but a real annoyance when working on a large photo collection. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 482132] When renaming an album, all collections' trees are expanded (windows and kde neon)
https://bugs.kde.org/show_bug.cgi?id=482132 --- Comment #4 from guenael --- Really? That's weird because this is a bug I have been observing for weeks so not a sudden issue for me. Note that I started using DIgikam al lot a few weeks ago (instead of once in a while). Hum. I could send you a screen cast I presume - but that won't help a lot, will it ? Except showing that I have not gone postal. What can I do then to help make it reproducible? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 482132] When renaming an album, all collections' trees are expanded (windows and kde neon)
https://bugs.kde.org/show_bug.cgi?id=482132 --- Comment #6 from guenael --- I happen to have upgraded to Plasma 6 and Wayland - without knowing it beforehand it was such a huge upgrade. I was lucky though, only details don't work. So I tested "my" tree bug and reproduced it once again. I also check through a remote session that it happens as well on my father's computer, a Win10 laptop. His digikam db and collections are different than mine, so it's not only "my" computer. A family bug? :-) My current Neon conf: Operating System: KDE neon 6.0 KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.5.0-21-generic (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-3770T CPU @ 2.50GHz Memory: 15,4 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4000 At this point, I can only hope that other users confirm the issue. I've made many trials to find a circumstance when the bug would NOT appear. I just found that the bug is even more obvious when the album renamed is situated not in the first collection but on the next ones (the whole trees expand). However, it's just an annoyance and not a blocking thing, so no reason to make it a priority of any sort. In all cases, thank both of you for your super quick reaction to try and reproduce it ; it's super nice to feel supported and it shows how serious the Digikam team is. Best regards. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 484708] New: Images.modificationDate value in the db is incorrect
https://bugs.kde.org/show_bug.cgi?id=484708 Bug ID: 484708 Summary: Images.modificationDate value in the db is incorrect Classification: Applications Product: digikam Version: 8.3.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: minor Priority: NOR Component: Database-Files Assignee: digikam-bugs-n...@kde.org Reporter: g...@zai.re Target Milestone: --- SUMMARY . On Windows 10, using 8.3 . In the SQLite db, Images.modificationDate value is stored in this format "2024-03-29T10:48:44.011Z" . If I understand rightly the ISO 8601 standard, the final Z without offset means UTC. . But Digikam stores the modification date as local time and adds "Z" at the end without taking account of the local time. STEPS TO REPRODUCE 1. If your local time is not UTC, add or edit a caption of an image 2. Check of value Images.modificationDate field in the db (I use DB Browser for SQLite) OBSERVED RESULT The value is a string which value is local time of that image, plus "Z" at the end If you need an extra confirmation, change the timezone of your computer in the Windows settings, edit the caption and look at the field value. EXPECTED RESULT That value should be in UTC, taking account of the local timezone. SOFTWARE/OS VERSIONS Windows: 10 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 484708] Images.modificationDate value in the db is incorrect
https://bugs.kde.org/show_bug.cgi?id=484708 --- Comment #3 from guenael --- Thanks for your super-quick reaction! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 484802] New: The 'album date' is updated to the 'creation date' of a picture when that picture is renamed outside of Digikam
https://bugs.kde.org/show_bug.cgi?id=484802 Bug ID: 484802 Summary: The 'album date' is updated to the 'creation date' of a picture when that picture is renamed outside of Digikam Classification: Applications Product: digikam Version: 8.3.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: minor Priority: NOR Component: Database-Files Assignee: digikam-bugs-n...@kde.org Reporter: g...@zai.re Target Milestone: --- STEPS TO REPRODUCE 1. Activate 'monitor the albums for external changes' in the Digikam configuration 2. Set an album date to an arbitrary date 3. Using Windows file explorer, rename a picture of that album OBSERVED RESULT The album date is updated to the date of that picture. EXPECTED RESULT The album date should stay unchanged. SOFTWARE/OS VERSIONS Windows 10 latest version -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 484802] The 'album date' is updated to the 'creation date' of a picture when that picture is renamed outside of Digikam
https://bugs.kde.org/show_bug.cgi?id=484802 --- Comment #2 from guenael --- Well, I have spent quite a long time looking for any option related to the album date and haven't found it. Could you let me know where I can change that setting? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 446201] Freeze while browsing pictures
https://bugs.kde.org/show_bug.cgi?id=446201 guenael changed: What|Removed |Added CC||g...@zai.re --- Comment #15 from guenael --- Hi, Sorry in advance for the long post, I'm just trying to give as much details as possible. My father is having this issue while using 8.2 on Windows 10 (latest version). It's very frequent, several times per hour, sometimes more. It has been happening for a few weeks, since he started using Digikam heavily again (rather than casual uses, once or twice per week. Symptoms: - 3 to 20, sometimes 30 seconds freezes - after some time, Windows says that the program is "not responding". We never closed it the hard way, waiting patiently Digikam to become responsive again - the task manager indicates around 20% of the processor being used. My guess is 100% of 1 of the 8 cores + the system - but take that for what it is: an amateur guess. On normal usage, this figure is attained during maintenance like thumbnails recreating, rarely otherwise (as far as we can tell...) - no disk usage at all (unexpected by me), no network usage (as expected) => digikam is "thinking hard" :-/ Different operations can lead to 3-to-20-second freezes: mostly, moving images to another album (by dragging) or moving an album into another album. Anything related to reorganizing albums and images. My father and I have spent quite some time trying to pinpoint specific circumstances, but nothing emerges (except what I described). So I have extensively duckduckducked the issue, read forums, and tried many things: - deep maintenance - moving all Digikam directories to a directory directly on C:\, put digikam.exe, exiftool.exe out of scan by security services (Defender etc) and other stuff like OneDrive etc, checked access rights. - we moved all archives to an external hard drive, keeping all digikam collections are on the SSD. This was to reduce the SQLite database size (to around 50 Mo, 60 Mo before). No change, after full maintenance of course. - I manually deleted all the databases from the Digikam db directory except the main one, so that they would be re-created from scratch through maintenance. It hugely decreased the size of the thumbnails database from 7.6 to 3.1 Go, but very little on other databases. We thought we nailed it, but nope: no change. => NB: this was done before the archives were moved to an external drive, so the decrease is not linked to that. I find this decrease a bit too huge for a db that I had "deeply" cleant before (using the proper options in the maintenance panel). But the performance was not better after than before, as surprising to me as it is. - I migrated the SQLite to another directory, using the "migrate" function: the main database size was reduced to around 40 Mo (for around 56 000 pictures, but I'd to check those figures again if you need them, that's from memory) - The disk is a quite recent 2To SSD with good performances with plenty of room available. The computer is rather old, with a i7 4770, eg 4th generation processor and 16 GB of RAM. All Windows "checks" are green. Windows 10, Store programs, drivers are all up to date. - the computer has 2 video-cards: one on-chip, the other is a NVIDIA (I can check the reference, but this is a 6 or 7 year old gamer laptop to give you an idea). I deactivated the NVIDIA card completely and rebooted: no change. Digikam processes often uses that card according to the task manager. - I considered moving to MySQL but the help pages and forums were not in favor of that option, considering the number of images. I have used MySQL extensively so I can quickly set up a MySQL server on my father computer and migrate the db - if you think it useful. - ... I certainly have forgotten some stuff I tried but please point me what I could have tried, I'll give you a feedback within 24h (we live in France), often more quickly. So I install DebugView and checked the relevant option in digikam settings. It works, we can record logs as expected. The freezes always finish with a "one job done" and nothing more. => My guess is the path to the solution, but could you tell me exactly what data are needed? - Obviously, we'll write down the action leading the the freeze and the precise time HH:MM:SS. The seconds figure will be an approximation for sure, but we'll do our best. - The corresponding logs using DebugView - how many freezes to record? 5? 10? more ? It's easy to make them appear, even if they seem anything but regular. My father has tens of thousands of pictures to sort, comment, organize. And we like Digikam. So we are committed and available to spend the time necessary to give the data needed to spot that bug. On Windows. I use KDE Neon but my digikam collection is
[digikam] [Bug 446201] Freeze while browsing pictures
https://bugs.kde.org/show_bug.cgi?id=446201 guenael changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #17 from guenael --- Hi, My father installed the 8.3 pre-release last week as directed and it solved the issue immediately. We wanted to be sure (eg trying in real conditions) before reporting it, the official release came, and we tested on that one also: everything is fine on both versions, no freeze anymore. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 484084] New: Impossible to rename a picture when changing only the case of one letter of its name
https://bugs.kde.org/show_bug.cgi?id=484084 Bug ID: 484084 Summary: Impossible to rename a picture when changing only the case of one letter of its name Classification: Applications Product: digikam Version: 8.3.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: minor Priority: NOR Component: AdvancedRename-file Assignee: digikam-bugs-n...@kde.org Reporter: g...@zai.re Target Milestone: --- SUMMARY Impossible to rename a picture when changing only the case of one letter of its name STEPS TO REPRODUCE 1. Type F2 after selecting a picture named, say, "picture01.jpg" 2. Try and rename it "Picture01.jpg" (change only the case of 1 letter) OBSERVED RESULT An error panel appears "An error occurred while renaming 1 image" ; it offers to rename it again or overwrite the image. Both solutions fail if you persist to change the case of that precise letter. But if you want to rename it "Aicture.jpg", it works. EXPECTED RESULT Image renamed to "Picture01.jpg" SOFTWARE/OS VERSIONS Windows 10 ADDITIONAL INFORMATION It looks like the same issue as bug #311151 but that one happened in 2012, so I feel it more relevant to create a new ticket. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 474560] New: image saved with .tiff extension instead of .tif
https://bugs.kde.org/show_bug.cgi?id=474560 Bug ID: 474560 Summary: image saved with .tiff extension instead of .tif Classification: Applications Product: digikam Version: 8.1.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: minor Priority: NOR Component: ImageEditor-Save Assignee: digikam-bugs-n...@kde.org Reporter: g...@zai.re Target Milestone: --- SUMMARY When an image with a name such as abcde.tif extension is edited in the image editor, the edited image is saved as abcde_v1.tiff STEPS TO REPRODUCE 1. load image into the image editor 2. edit the image 3. save changes 4. compare names of the two files OBSERVED RESULT name-of-image_v1.tiff EXPECTED RESULT name-of-image_v1.tif SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION Same issue on KDE Neon based on Ubuntu 22.10 ; it has existed for quite a long time, I just never took the time to report it since it's a mere annoyance. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 474684] New: CTRL-A doesn't select all images despite status bar displaying all selected
https://bugs.kde.org/show_bug.cgi?id=474684 Bug ID: 474684 Summary: CTRL-A doesn't select all images despite status bar displaying all selected Classification: Applications Product: digikam Version: 8.1.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Preview-Image Assignee: digikam-bugs-n...@kde.org Reporter: g...@zai.re Target Milestone: --- SUMMARY CTRL-A doesn't select all images despite status bar displaying all selected STEPS TO REPRODUCE 1. Click on the first image to set focus 2. CTRL A 3. move images to another album : only the first image is moved s OBSERVED RESULT a. only the first image is highlighted as selected b. the status bar indicates all images selected EXPECTED RESULT a. all images of the album are selected b. the status bar indicates all images selected NB : point b mentioned to underline the discrepancy between the status bar and how many images are indeed selected. SOFTWARE/OS VERSIONS Windows: 10 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 474684] CTRL-A doesn't select all images despite status bar displaying all selected
https://bugs.kde.org/show_bug.cgi?id=474684 --- Comment #1 from guenael --- Created attachment 161714 --> https://bugs.kde.org/attachment.cgi?id=161714&action=edit screenshot -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 474684] CTRL-A doesn't select all images despite status bar displaying all selected
https://bugs.kde.org/show_bug.cgi?id=474684 guenael changed: What|Removed |Added Resolution|NOT A BUG |--- Ever confirmed|0 |1 Status|RESOLVED|REOPENED --- Comment #4 from guenael --- (In reply to Maik Qualmann from comment #3) > You can only select and move multiple items from the Item (Thumbnail) view, > not from the preview. > > Maik OK, but then there is a bug in the status bar since it indicates - for examples - 10/10 items selected when I press CTRL A. -- You are receiving this mail because: You are watching all bug changes.
