https://bugs.kde.org/show_bug.cgi?id=443827
--- Comment #2 from MarcP ---
Good question, let me check.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=443827
MarcP changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=443827
Bug ID: 443827
Summary: Clicking on a person with unconfirmed suggestions does
not always focus on these suggestions
Product: digikam
Version: 7.4.0
Platform: Flatpak
https://bugs.kde.org/show_bug.cgi?id=436286
MarcP changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=442686
MarcP changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=442686
Bug ID: 442686
Summary: Face suggestion does not disappear if the same face
has already been tagged in another device
Product: digikam
Version: 7.4.0
Platform: Flatpak
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #26 from MarcP ---
Hi Maik.
Just one note. Yesterday I added a bunch of tags to the pictures of an album
using Digikam 7.3 in another computer.
Today when I started the flatpak preview of flatpak 7.4, it did not detect
these changes, so
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #41 from MarcP ---
Hi,
I can confirm that this problem still persists in Ubuntu 20.04 using the latest
flatpak build (Build date: 22/8/21 10:27 (target: Debug)
Rev.: 699538c1b3ff85650d617ab716493135fe44c999)
Even now that the initial
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #23 from MarcP ---
After trying thursday's build (Rev.: 61cee1cc9536b88b073acce47d37dc85bb1bbfdd),
the initial scan was further reduced to 2 minutes and 29 seconds. That's only
17% of the time it took two weeks ago (14m20s), so more than 5
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #20 from MarcP ---
By the way, when the initial scan starts, it stays for a while at 0%, before
the progress bar starts to move towards the 100%.
I must measured it,
from 0% to 1%: 2m26s
>From 1% to 100%: 2m16s
That's about h
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #19 from MarcP ---
Hi again,
I could not find to run digikam in debug mode using the flatpak version, but I
measured the date when I launched it and when it finished the initial scan.
After upgrading to today's version (with no new
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #17 from MarcP ---
Ok! I'll run some tests this week and get back to you.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #13 from MarcP ---
Today I updated the flatpak version (v.:
03f233383d94c20099afe07e75edb727694e5c3c) and tried again:
Same library, same network, no new items: 7 minutes and 37 seconds.
That's about half the time it took yesterday! Good
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #12 from MarcP ---
Ok, so, as a reference, version 7.4.0 rev
90854f4a4e9e06ed2f1196afbee0b92fe5bf9fe8 took 14 minutes and 20 seconds since
it was started until it finished checking for changes (there were none since I
already started
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #11 from MarcP ---
I'll test with my collections these days and provide some feedback as well.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=265241
MarcP changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=437771
MarcP changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #8 from MarcP ---
I believe nothing has changed on this regards. The total startup time still
heavily depends on the latency of the medium where pictures are stored.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=406583
--- Comment #9 from MarcP ---
I confirm that the bug is still present in version 7.4.0 rev
c837733d5b7d48a801a43fcda5b7b6e548b3966a
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=406443
--- Comment #7 from MarcP ---
>From the current 7.4 release, that menu still looks exactly the same.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=414424
--- Comment #7 from MarcP ---
Well, the behavior is the same. When a tag or folder is collapsed, the count
number does not reflect the real number of items within it.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=391428
--- Comment #2 from MarcP ---
Hi Maik. What I have been doing all this time, is having a saved search that
just search for files with a dot. That way, it lists all files in all
libraries.
It's a workaround. Although it would be cool
https://bugs.kde.org/show_bug.cgi?id=407034
--- Comment #14 from MarcP ---
Hello Gilles,
sorry, I just saw your email.
I wouldn't know exactly how to replicate this behavior, because it was a long
time ago that I reported it, but I know that it still happens from time to
time.
My usual
https://bugs.kde.org/show_bug.cgi?id=435843
MarcP changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=435843
Bug ID: 435843
Summary: Metadata changes not saved when removing face region
Product: digikam
Version: 7.3.0
Platform: Flatpak
OS: Linux
Status: REPORTED
https://bugs.kde.org/show_bug.cgi?id=377857
--- Comment #27 from MarcP ---
Nice mockup.
For me, the most important part of the Properties would be an intuitive way to
display the tags. In my case, I use plenty of tags in a tree, so an easy way to
display that information would allow me
https://bugs.kde.org/show_bug.cgi?id=432568
--- Comment #9 from MarcP ---
Works perfectly. Thank you Maik, you are the best!
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=432568
--- Comment #6 from MarcP ---
Yes, I know, but even considering that, there's something weird the way it
works now (that also applies for Bug 431354, as it's likely the same thing).
So, when you tag an image, the new tags you see in that panel have
https://bugs.kde.org/show_bug.cgi?id=432568
--- Comment #4 from MarcP ---
Created attachment 135463
--> https://bugs.kde.org/attachment.cgi?id=135463=edit
Weird behavior when tag trees are involved
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=432568
--- Comment #3 from MarcP ---
Created attachment 135462
--> https://bugs.kde.org/attachment.cgi?id=135462=edit
Normal behavior with first-level tags. No problem here.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=432568
--- Comment #2 from MarcP ---
Ok, I have just tried with an appimage version of digikam (7.1 stable release),
and the behavior is also there. But I realised something. This only occurs when
the picture already has tags in form of a tree.
So
https://bugs.kde.org/show_bug.cgi?id=432568
Bug ID: 432568
Summary: Provisional tags are not displayed until another
change is made
Product: digikam
Version: 7.2.0
Platform: Flatpak
OS: Linux
https://bugs.kde.org/show_bug.cgi?id=432568
MarcP changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=431355
--- Comment #8 from MarcP ---
That's perfect, thank you!
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=431355
--- Comment #4 from MarcP ---
Thanks Maik.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=431355
--- Comment #2 from MarcP ---
You have time to do that before hitting the Apply button.
Ok, I just downloaded Digikam 7.1, and indeed the behavior was different.
Something definitely changed from Digikam 7.1 to 7.2. Once you clicked on
Create
https://bugs.kde.org/show_bug.cgi?id=431354
--- Comment #2 from MarcP ---
Yes, but it's filtered in both cases, either when the tag already exists in the
tree, and when it doesn't.
Shouldn't digikam behave equally in both cases?
In any case, I think it would be more intuitive to show
https://bugs.kde.org/show_bug.cgi?id=399027
--- Comment #4 from MarcP ---
Yes, that's what I meant. Feel free to close it, it's not really a big deal.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=431355
MarcP changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=431355
Bug ID: 431355
Summary: There is no button to add Tag to picture
Product: digikam
Version: 7.2.0
Platform: Flatpak
OS: Linux
Status: REPORTED
Severity: minor
https://bugs.kde.org/show_bug.cgi?id=431354
MarcP changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=431354
Bug ID: 431354
Summary: Inconsistent behavior when adding Tags/Keywords
Product: digikam
Version: 7.2.0
Platform: Flatpak
OS: Linux
Status: REPORTED
Severity:
https://bugs.kde.org/show_bug.cgi?id=399027
--- Comment #2 from MarcP ---
Hi. I exactly remember when I submitted this bug, but I think I meant an option
to expand and collapse the full subalbum tree, including subfolders of
subfolders.
Right now, when you expand an album, you only expand
https://bugs.kde.org/show_bug.cgi?id=377857
--- Comment #23 from MarcP ---
I would also like to see a dashboard like that in the mockup implemented.
The current one is not very "visual", especially in the case of the "folder"
field, which is never shown complete (what about
https://bugs.kde.org/show_bug.cgi?id=417399
--- Comment #11 from MarcP ---
Great :)
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=417399
--- Comment #9 from MarcP ---
Oh, that's nice to hear. You usually want to see the face of the person you are
taggin on the tree (it's more intuitive), but for regular keywords that's not
necessary (the more compact, the better).
Will the icon size
https://bugs.kde.org/show_bug.cgi?id=417399
--- Comment #7 from MarcP ---
It's fine for me.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=427041
MarcP changed:
What|Removed |Added
Resolution|--- |NOT A BUG
Status|REPORTED
https://bugs.kde.org/show_bug.cgi?id=427041
Bug ID: 427041
Summary: Geolocation information not being saved to the
metadata
Product: digikam
Version: 7.1.0
Platform: Appimage
OS: Linux
Status:
https://bugs.kde.org/show_bug.cgi?id=427041
MarcP changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=426218
--- Comment #5 from MarcP ---
Hi again. Today I was using the 7.2 beta, and I re-added the problematic
collection and removed it, and it finally removed all the associated pictures
from my library. I don't know if I was doing something wrong
https://bugs.kde.org/show_bug.cgi?id=426699
--- Comment #4 from MarcP ---
Yes, I confirm that "Ignored" appears at the end of the list, and "Unconfirmed"
and "Unknown" at the beginning.
Mmm, in my case, I would prefer them to be always visible, even if I scrolled
https://bugs.kde.org/show_bug.cgi?id=426699
--- Comment #2 from MarcP ---
Oh, ok, So this was done on purpose, I thought it appeared in the middle of the
list, sorry, my fault.
But I still think it's not very visible, as I had to manually search for it. I
believe interface elements should
https://bugs.kde.org/show_bug.cgi?id=426699
MarcP changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=426699
Bug ID: 426699
Summary: "Ignored" faces category should not be positioned
alphabetically, but on top of the list
Product: digikam
Version: 7.2.0
Platform: Appimage
https://bugs.kde.org/show_bug.cgi?id=422240
--- Comment #23 from MarcP ---
It only happened once to me, but I was just saying that it was a possibility.
Using an external tool (e.g. http://exif.regex.info/exif.cgi ) you can make
sure if the text "binary comment" has actually be
https://bugs.kde.org/show_bug.cgi?id=422240
--- Comment #18 from MarcP ---
In a few cases, the words "binary comment" were saved into the picture as the
comment when I saved the metadata overwriting the actual comment. If
re-reading the metadata doesn't change it, that might be
https://bugs.kde.org/show_bug.cgi?id=426218
--- Comment #4 from MarcP ---
Actually, digikam's database is stored at the same path of the Local collection
I just added (/home/marc/Imatges). But I have not edited the path in the
database manually in this case.
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=426218
--- Comment #2 from MarcP ---
I just replicated it again, with identical results.
I have three collections on network shares, and I added a local collection (a
folder in my home directory). I waited until it finished scanning for new
items
https://bugs.kde.org/show_bug.cgi?id=426218
MarcP changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=426218
Bug ID: 426218
Summary: Pictures from old collection still in database after
removing it
Product: digikam
Version: 7.1.0
Platform: Appimage
OS: Linux
https://bugs.kde.org/show_bug.cgi?id=426215
Bug ID: 426215
Summary: Wishlist: Hierarchical saved searches
Product: digikam
Version: 7.1.0
Platform: Flatpak
OS: Linux
Status: REPORTED
Severity: wishlist
https://bugs.kde.org/show_bug.cgi?id=426215
MarcP changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #38 from MarcP ---
Ok, I did some tests, all of them using the stable 7.0.0 x64 version. I used a
set of ~500 pictures, 4.5GB in size, and using a blank database.
Basically, when storing the pictures locally, the import process is so fast
https://bugs.kde.org/show_bug.cgi?id=395501
--- Comment #23 from MarcP ---
That is great to hear. I can't wait to try the new improvements.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #36 from MarcP ---
I think it also happens with a local collection, but since the latency is much
lower, the time it takes to import each individual picture is also lower and
the effect is less pronounced.
I'll run some tests
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #34 from MarcP ---
I can confirm this still happens in the stable 7.0.0 release under MacOS
Catalina.
I copy what I wrote in a related bug report (Bug 389652):
"I experienced this again in the 7.0.0 stable version on a macbook with
https://bugs.kde.org/show_bug.cgi?id=389652
--- Comment #10 from MarcP ---
Oh, sorry, I was not aware of that other bug report.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=420334
MarcP changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=395501
--- Comment #21 from MarcP ---
Created attachment 131233
--> https://bugs.kde.org/attachment.cgi?id=131233=edit
Example of duplicated "People" tag in different languages
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=389652
MarcP changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.kde.org/show_bug.cgi?id=395501
--- Comment #20 from MarcP ---
I can confirm this is still an issue in the stable 7.0.0 version under MacOS
Catalina.
Since the "People" pseudotag gets written in the pictures' metadata, digikam
will recreate the hierarchy with the t
https://bugs.kde.org/show_bug.cgi?id=395501
MarcP changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=392007
--- Comment #5 from MarcP ---
The situation still applies. I don't think there is an easy solution, but I
would leave it open because we might take it into consideration in the future.
--
You are receiving this mail because:
You are watching all bug
https://bugs.kde.org/show_bug.cgi?id=425310
MarcP changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=425230
MarcP changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=425230
Bug ID: 425230
Summary: Crash when scanning for faces
Product: digikam
Version: 7.0.0
Platform: Appimage
OS: Linux
Status: REPORTED
Severity: normal
https://bugs.kde.org/show_bug.cgi?id=389620
--- Comment #6 from MarcP ---
Wait, I believe this one has been solved as well. At least, I cannot reproduce
the bug anymore.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=416213
--- Comment #14 from MarcP ---
This problem still exists, but has a difficult solution because face rectangles
cannot store a hierarchy.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=391430
--- Comment #3 from MarcP ---
I woukd really like if this feature was implemented. It seems quite simple, but
it would save me quite a lot of time, since I activate that option manually
every time.
--
You are receiving this mail because:
You
https://bugs.kde.org/show_bug.cgi?id=392936
--- Comment #12 from MarcP ---
Still present, but it's mostly a cosmetic issue, and not a very important one.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=389620
--- Comment #5 from MarcP ---
I believe this is still the case.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=391891
--- Comment #9 from MarcP ---
This problem is still present.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=395236
--- Comment #9 from MarcP ---
I still believe it would be a nice feature to have.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=395241
--- Comment #6 from MarcP ---
This behavior is still present.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=392008
--- Comment #10 from MarcP ---
This bug is still present.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=392020
--- Comment #5 from MarcP ---
This issue is still present. But it will be hard to "solve" due to how digikam
understands face tags.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=384485
--- Comment #13 from MarcP ---
❤️
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=399600
--- Comment #9 from MarcP ---
Behavior still present. Digikam is not aware if a file is read-only when
writing metadata and just assumes it has been written correctly.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=406584
--- Comment #9 from MarcP ---
I have not experienced that bug anymore. I would reopen it if I experience
something weird again.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=399034
--- Comment #7 from MarcP ---
This bug is still present.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=407034
--- Comment #9 from MarcP ---
This bug is still present. I experienced it yesterday in a batch of pictures I
scanned yesterday. At some point, the xmp metadata autopopulates (it gets
copied from some value in the exif, I think), including the video tag
https://bugs.kde.org/show_bug.cgi?id=410275
--- Comment #9 from MarcP ---
Well, as we discussed, this is not really a bug, but the way digikam
autocollapses and autoexpands the root of the tag list, which may be confusing
if you don't know what's happening.
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=420710
--- Comment #20 from MarcP ---
Created attachment 130542
--> https://bugs.kde.org/attachment.cgi?id=130542=edit
Table comparing the metadata fields used in main picture managers
To summarize the information I gathered when examining the metad
https://bugs.kde.org/show_bug.cgi?id=420710
--- Comment #19 from MarcP ---
In any case, according to that conversion table:
Exif.Image.DateTime <=> Xmp.xmp.ModifyDate
That means that the Exif.Image.DateTime, that is used in digikam as the date
for when the "pictur
https://bugs.kde.org/show_bug.cgi?id=420710
--- Comment #16 from MarcP ---
Hi. Now that the final 7.0.0 version has been released, can we have a look at
this report?
I think the samples I provided show that the main tag for saving the date in
Exif is the Exif.Photo.DateTimeOriginal. To sum up
https://bugs.kde.org/show_bug.cgi?id=406583
--- Comment #7 from MarcP ---
The bug is still there.
I think it's the most annoying bug I can find in digikam now, since I can't
search for elements that contain special characters in their name.
Also, the search is sensitive to these characters
https://bugs.kde.org/show_bug.cgi?id=417140
MarcP changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Ever confirmed|0
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #6 from MarcP ---
Ok, so I experienced this problem when I lived abroad, and had a ~100ms ping,
but it's no longer the case, so I tried to find ways to assess startup and
scanning speed by simulating high network latencies.
So I used
https://bugs.kde.org/show_bug.cgi?id=412591
--- Comment #10 from MarcP ---
This but is no longer present using the stable 7.0.0 release (64bit, appimage)
in Ubuntu 20.04LTS.
--
You are receiving this mail because:
You are watching all bug changes.
201 - 300 of 492 matches
Mail list logo
