[digiKam-users] digikam git version , strange 'Tags' tag

[Maik Qualmann]

If I delete a tag here or a tag tree, also from the image / sidecar all
entries are deleted. I can not reproduce a mistake. Is the image collection
local or on a network drive?

Maik

Am Donnerstag, 7. Februar 2019, 19:16:02 CET schrieb [hidden email]:

> On 2/7/19 5:22 PM, [hidden email] wrote:
> > On 2/6/19 9:21 PM, Maik Qualmann wrote:
> >> Can you send me a image (by email), that again and again created this
> >> "badfolder"?
> >
> > Now:
> > 1) "cleanup database" works normally, no "badfolder" created
> > 2) when updating database from images metadata (.xmp files),
> > "badfolder"/"F***" is created. In attached screenshot, this bad folder
> > is the red one . Other good folders are green.
> > 3) after searching in .xmp affected images files, i discover they
> > contain "F***" word/bad tag. => I understand that after deleting this
> > badfolder/"F***"/tags, they are not really deleted in .xmp files.
>
> Now, I deleted this badfolder/"F***" containing subtags then I opened in
> editor .xmp attached to concerned image files: these .xmp are not
> updated all, they still contain "F***"/tags i just deleted
>
> > Other thing, bad folder "F***" duplicates some tags of good folder
> > "T**** (8729)".
> > I think, but I'm not sure, in the past, I renamed tag folder "T***" in
> > "F***", then I renamed folder "F***" in "T***"

[leoutation]

On 2/7/19 8:46 PM, Maik Qualmann wrote:
> If I delete a tag here or a tag tree, also from the image / sidecar all
> entries are deleted. I can not reproduce a mistake. Is the image collection
> local or on a network drive?
Image collection is local on hd PC.
To reproduce, you may try to rename, for example,  a folder "a"
containing subtags to new name "abcd",  then rename "abcd" to  original
name "a". That's what i did some months ago, i think.

>
> Maik
>
> Am Donnerstag, 7. Februar 2019, 19:16:02 CET schrieb [hidden email]:
>> On 2/7/19 5:22 PM, [hidden email] wrote:
>>> On 2/6/19 9:21 PM, Maik Qualmann wrote:
>>>> Can you send me a image (by email), that again and again created this
>>>> "badfolder"?
>>>
>>> Now:
>>> 1) "cleanup database" works normally, no "badfolder" created
>>> 2) when updating database from images metadata (.xmp files),
>>> "badfolder"/"F***" is created. In attached screenshot, this bad folder
>>> is the red one . Other good folders are green.
>>> 3) after searching in .xmp affected images files, i discover they
>>> contain "F***" word/bad tag. => I understand that after deleting this
>>> badfolder/"F***"/tags, they are not really deleted in .xmp files.
>>
>> Now, I deleted this badfolder/"F***" containing subtags then I opened in
>> editor .xmp attached to concerned image files: these .xmp are not
>> updated all, they still contain "F***"/tags i just deleted

After searching, i see "badfolder/"F***" is a replication of original
good folder "T****".  The bad folder contains same (good) tags.
To resume, it seems problem comes from the old name/word folder"F***", I
can't delete it from .xmp files, about 8500 files...
I don't know if it's safely possible to edit metadata in mariadb
database  with a tool. Then, with Digikam, i could update from database
to .xmp images metadata.
Not very easy to understand, it's like Kafka...

>>
>>> Other thing, bad folder "F***" duplicates some tags of good folder
>>> "T**** (8729)".
>>> I think, but I'm not sure, in the past, I renamed tag folder "T***" in
>>> "F***", then I renamed folder "F***" in "T***"
>
>
>
>


--
Maderios

[leoutation]

On 2/7/19 10:37 PM, [hidden email] wrote:
> I don't know if it's safely possible to edit metadata in mariadb
> database  with a tool. Then, with Digikam, i could update from database
> to .xmp images metadata.
I find digikam solution to update .xmp: sync from database to metadata.
After that, I launched "scan for new item", it took about 30 minutes
then displayed "no active" process. This message is wrong because
digikam processes were active in the background (hard drive an cpu)
during more than an hour an half after the "official" end.
--
Maderios

[Gilles Caulier-4]

Le ven. 8 févr. 2019 à 14:00, <[hidden email]> a écrit :

On 2/7/19 10:37 PM, [hidden email] wrote:
> I don't know if it's safely possible to edit metadata in mariadb
> database  with a tool. Then, with Digikam, i could update from database
> to .xmp images metadata.
I find digikam solution to update .xmp: sync from database to metadata.
After that, I launched "scan for new item", it took about 30 minutes
then displayed "no active" process. This message is wrong because
digikam processes were active in the background (hard drive an cpu)
during more than an hour an half after the "official" end.

yes, the bug is know...

And in fact it's not a bug. Few year ago, Marcel has implemented this feature, to scan collection in background. It's done in too stages :

1/ scan albums without contents and register new entries in DB. This is done with progress manager.

2/ scan one by one all albums and register contents  in DB. This is done in low level background.

Gilles Caulier

[leoutation]

On 2/8/19 3:10 PM, Gilles Caulier wrote:

>
>
> Le ven. 8 févr. 2019 à 14:00, <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     On 2/7/19 10:37 PM, [hidden email] <mailto:[hidden email]> wrote:
>      > I don't know if it's safely possible to edit metadata in mariadb
>      > database  with a tool. Then, with Digikam, i could update from
>     database
>      > to .xmp images metadata.
>     I find digikam solution to update .xmp: sync from database to metadata.
>     After that, I launched "scan for new item", it took about 30 minutes
>     then displayed "no active" process. This message is wrong because
>     digikam processes were active in the background (hard drive an cpu)
>     during more than an hour an half after the "official" end.
>
>
> yes, the bug is know...
>
> And in fact it's not a bug. Few year ago, Marcel has implemented this
> feature, to scan collection in background. It's done in too stages :
>
> 1/ scan albums without contents and register new entries in DB. This is
> done with progress manager.
> 2/ scan one by one all albums and register contents  in DB. This is done
> in low level background.
>
> Gilles Caulier

The problem is that the low level background nearly freezes computer.
In another hand, the background progresses is very quick after the first
scan...

--
Maderios

[leoutation]

On 2/8/19 3:22 PM, [hidden email] wrote:

> On 2/8/19 3:10 PM, Gilles Caulier wrote:
>>
>>
>> Le ven. 8 févr. 2019 à 14:00, <[hidden email]
>> <mailto:[hidden email]>> a écrit :
>>
>>     On 2/7/19 10:37 PM, [hidden email] <mailto:[hidden email]>
>> wrote:
>>      > I don't know if it's safely possible to edit metadata in mariadb
>>      > database  with a tool. Then, with Digikam, i could update from
>>     database
>>      > to .xmp images metadata.
>>     I find digikam solution to update .xmp: sync from database to
>> metadata.
>>     After that, I launched "scan for new item", it took about 30 minutes
>>     then displayed "no active" process. This message is wrong because
>>     digikam processes were active in the background (hard drive an cpu)
>>     during more than an hour an half after the "official" end.
>>
>>
>> yes, the bug is know...
>>
>> And in fact it's not a bug. Few year ago, Marcel has implemented this
>> feature, to scan collection in background. It's done in too stages :
>>
>> 1/ scan albums without contents and register new entries in DB. This
>> is done with progress manager.
>> 2/ scan one by one all albums and register contents  in DB. This is
>> done in low level background.
>>
>> Gilles Caulier
> The problem is that the low level background nearly freezes computer.
> In another hand, the background progresses is very quick after the first
> scan...
>

Mistake -> Understand in my bad english: "In another hand, the
background *processes* are very quick after the first
scan"

--
Maderios