Relaunch: file not found.... -> no start!

[Uwe Haider]

First I have to apologize my separated mails of the last week. I got the
mailing-list-digest, so it was hard to keep all infos in one thread. Now
I try to make it better.... (Thanks to Remco)

Here are all separated mails collected together:

After moving to a new computer/NAS I have trouble to start digikam. I
try to fix it for several weeks now, but no success so far. This is the
output of digikam while starting:

  [...]

  133  digikam.general: Using  8  CPU core to run threads
  134 digikam.general: new search text settings:  "" : hasResult =
false , validRows =  0
  135 QFSFileEngine::open: No file name specified
  136 digikam.geoiface: ----
  137 digikam.general: Added root album called:  "WD-USB"
  138 digikam.general: Added root album called:  "Geschäftsbericht_2011"
  139 digikam.general: Added root album called:  "Einweihung HHN"
  140 digikam.general: Added root album called:  "Albas Bilder"
  141 digikam.general: Added root album called:  "Carla 18"
  142 digikam.general: Added root album called:  "Bilder_lokal"
  143 digikam.general: Added root album called:  "Bilder"
  144 digikam.general: Added root album called:  "Fotos"
  145 digikam.general: Added root album called:  "NAS"
  146 digikam.general: Did not find album root album in hash
  147 QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch
failed: Datei oder Verzeichnis nicht gefunden
  148 QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch
failed: Datei oder Verzeichnis nicht gefunden

-> last line is repeated until here

3094 QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch
failed: Datei oder Verzeichnis nicht gefunden
3095 QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch
failed: Auf dem Gerät ist kein Speicherplatz mehr verfügbar

"Datei oder Verzeichnis nicht gefunden" means "file not found"

"Auf dem Gerät ist kein Speicherplatz mehr verfügbar" means "no space
left on device".

This is, what I have done while moving to the new machine:

- moved the mariadb-server to my NAS

- moved all files in the NAS-mariadb as separate dumps

- changed the album paths in the albumroot-table to the new mount points

- I have lost an harddisk (broken, unreadable) and tried to mount the
backup instead ( I don't need this files absolut)

- changed the configuration in digikam to the NAS-mariadb

The main problem seems to be the QInotifyFileSystemWatcherEngine writing
a disk full - how can I stop this? I think digikam will be able to check
and repare the mariadb if it gets started.

My NAS is connected via nfs. DigikamDB is mysql installed on the NAS.

This is supposed to work, just look here:

https://scribblesandsnaps.com/2011/03/13/manage-photos-from-multiple-digikam-installations/

Starting digikam in bash I can see, how digikam works with mariadb ->
The connection via nfs is no problem. The problem is, that so much files
aren't found by digikam. Is it a good idea to remove this albumpaths in
mariadb via shell? So digikam will nort seek the missing files....

I've tested it with vim and it works for my user. Writing is possible
to
the NAS.

The speed of the network connection don't lead to error messages - or I
haven't found them...

To avoid all the missing file errors can I drop the album paths in
mariadb. This will leave a bunch of pictures in the tables without an
album and an album root path. Will dk correct this tables? Or will I get
much more errors doing so?

"QINotifyFileSystemWatcherEngnine::addPaths: inotify_add_watch failed:
file not found

If I drop the missing Album Root Path in the albumrootpath-table will
dk  purge all pictures without the albumrootpath while starting? Or must
I purge all pictures, tags etc per hand for the misssing album root path?

Or is there an other way to clean up the database when dk does not start??

Any details missing? Please don't hesitate to ask for.


I have had a shooting for the catholic church three weeks ago and have
to make 30 pictures out of ~250 ready for printing. So I need dk
soon.... every advice is very welcome....

-- 
Uwe Haider
uwe.haider at gmx.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20170601/446949be/attachment.sig>