<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks Johnny!<br>
This is realy great and exactly what we need as much as possible
here, sharing knowledge for free!<br>
<br>
<br>
Op 03-09-11 13:45, Johnny schreef:
<blockquote cite="mid:87obz14zot.fsf@DeuxExMachina.config"
type="cite">
<pre wrap="">When I started using digikam, I was ignorant of "safe" filenaming
conventions and consequently have lots of silly characters (non-ascii
such as spaces and brackets), mainly in albums but also in a few
imagenames. I want to find and replace these names with minimal hassle
and wonder what is the best practice?
FAILED ATTEMPT:
My first attempt was to simply open digikam (I think this makes the
database change-aware, right?) and from the shell (i.e. emacs dired
mode) do a find and replace on the filenames. This was instantaneous,
and it seemed digikam picked up the changed. However, digikam became
incredibly slow and after a few minutes, I just stopped and restarted
digikam. Upon restart, it didn't recognise the database and additionally
became unresponsive, so I killed digikam from the shell. I found two
digikam processess and killed both - in retrospect I suspect maybe one
process was from the initial digikam session and it was updating the
database, and hence kept it locked from the second digikam process.
Now, this was several minutes after I did the initial file renaming, so
the question is why, if my guess is correct, digikam was so incredibly
slow?
WORKAROUND:
I recovered from my backed up database, but now directory names were
misaligned in the database and on the filesystem, so I had to manipulate
the database directly. Using sqlite3 from the command line, I did a find
and replace operation in the database - this was practically instant,
hence the query why digikam does this slowly (again, if this is really
what happened)? Now, restarting digikam, everything is back to normal
/and/ the albums are renamed. While this is doable, it is somewhat of a
workaround, are there better ways to do this?
If anyone is inclined to try my method the steps are as attached.
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">ONLY ATTEMPT IF
YOU UNDERSTAND WHAT THE COMMANDS DO!</pre>
</blockquote>
If you could elaborate a bit about what happens in each step, it
would be a great learning experience.<br>
and how to stop the sqlite session? could not think of something
else than control c.<br>
Don´t worry, I use a copy.<br>
<br>
<blockquote cite="mid:87obz14zot.fsf@DeuxExMachina.config"
type="cite">
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Digikam-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Digikam-users@kde.org">Digikam-users@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/digikam-users">https://mail.kde.org/mailman/listinfo/digikam-users</a>
</pre>
</blockquote>
I have something similar at hand at the moment, wrestling with the
setup from virtual box, it refuses to read from existing database.<br>
I pointed in digikamrc to the place where db exist, in my normal
setup db works with my pictures in the path
/media/FOTO/FOTO/ARCHIEF/<br>
but it kept stubbornly saying: path FOTO/ARCHIEF/ not found, so it
looks like it uses a reletive path and doesn know about the base
media/FOTO (which is the mounted drive called ¨FOTO¨.)<br>
any ideas?<br>
<br>
Best regards,<br>
Rinus<br>
<br>
</body>
</html>