A quick update...
I renamed one of the problematic tags after I had replaced the "floating
tag" in it's original parent. What happened after a restart was that the
photo with the problematic tag now got both tags - both the renamed
(located in the intented place) and the orignal (free floating).
Thought it might help with debugging efforts...
On 07/03/18 08:40, Jørn Villesen Christensen wrote:
On 06/03/18 00:54, Jens Georg wrote:
Can you pin-point any particular action that you are doing when this is
Well... At the moment a simple restart of shotwell will result in it
happening. If I order (some or all) the mislocated tags, they will
return to their wrong state shortly after start-up (I presume while
Shotwell is scanning for changes on the files or...?)
Shotwell does not take xmp sidecar files into account yet.
Right. Sorry. I am using Darktable along with Shotwell, so I forgot.
Do you have any idea of what is causing this? Or how to debug this?
If that happens again, can you provide ~/.local/share/shotwell/photo.db
and photo.db.bak somewhere for analysing?
I can send you a copy once I get proper internet again.
What is photo.db.bak? I think I sometimes have manually overwritten that
with a backup when I had made manual changes to the database.
Have not touched the tags table, though :-p
I tried to search a bit in the bug database, but no luck.
Does https://bugzilla.gnome.org/show_bug.cgi?id=776387 match?
Close. It may be related. He talks about the error happening when he is
moving tags around. I can actually move all tags in place to my liking -
except the return to their corrupt state after a Shotwell-restart.
shotwell-list mailing list