• Neuer Gutscheincode unseres Partners Schutzfolien24:
    DSLR-Forum2025
    Dauerhaft 10% Rabatt auf alle Displayschutzfolien und Schutzgläser der Eigenmarken
    "Upscreen", "Screenleaf", BROTECT" und "Savvies".
    Der Code ist für alle Geräteklassen gültig.
  • Stimmt ab über die Sieger des DSLR-Forum Fotowettbewerbs September 2025.
    Thema: "Straßenfotografie s/w"

    Nur noch bis zum 30.09.2025 23:59!
    Jeder darf abstimmen!
    Zur Abstimmung und Bewertung hier lang
  • In eigener Sache!

    Liebe Mitglieder, liebe Besucher und Gäste
    ich weiß, es ist ein leidiges Thema, aber ich muss es ansprechen: Werbung, Werbeblocker und Finanzierung des Forums.
    Bitte hier weiterlesen ...

  • Nicht erreichbare Adressen im Benutzerkonto
    Wir bekommen zurzeit eine große Anzahl an E-Mails, die das System zum Beispiel als Benachrichtigungen an Nutzer verschickt,
    als unzustellbar zurück, weil z.B. die Adressen nicht erreichbar sind oder das Postfach gar nicht existiert.
    Stellt doch bitte sicher, dass die Benachrichtigungen, die ihr vom System erwartet, auch zugestellt werden können.
    Nicht erreichbare E-Mail-Adressen sind dazu wenig hilfreich.
    Danke!
WERBUNG

Lightroom mit mehreren Bearbeitern

juhrmann

Themenersteller
Hallo miteinander,

ich habe eine Frage, die sich um den Workflow in Adobe Lightroom dreht:
Wie nutzt man Lightroom sinnvoll mit mehreren (nicht simultan arbeitenden) Benutzern?

Die Anforderungen:
  • Alle Bilder sollen für eine möglichst globale Suche in einem Katalog gehalten werden.
  • Von jedem Rechner soll der Zugriff auf den Katalog möglich sein (nicht zwingend simultan, aber sowohl lesend als auch schreibend).

Googlen und Fragen im Bekanntenkreis führten zu folgenden Lösungen:
  1. Bilder+Katalog auf externer Platte halten und die bei Bedarf an den jeweiligen Rechner anstöpseln.
  2. Raw-Files liegen auf dem Server. Katalog und Previews werden per Unison synchronisiert (meine aktuelle Lösung).
  3. mit dem "subst-Hack" wird auch der Katalog und die Previews auf das Netzlaufwerk gelegt.
  4. wie 2., jedoch werden neue Bilder erst auf der lokalen Platte in einen eigenen Katalog gesteckt und dann in den Hauptkatalog importiert.

Wegen schlechter Sicherung scheidet Punkt 1 aus.
Der Server hat Raid, Snapshotting und Online-Backup - eine USB-Platte hat im Vergleich dazu hin und wieder mal einen Defekt.
Transportabel brauchen Katalog/Raw-Files auch nicht zu sein, da ich die Nachbearbeitung immer daheim mache.

Punkt 2 hat den Nachteil, dass das Synchronisieren gerne mal vergessen wird und - falls Previews mitsynchronisiert werden - eine halbe Ewigkeit dauert.

Bei Punkt 3 - hab ich zumindest gelesen - führt ein Parallelzugriff dazu, dass die
Lightroom-DB stirbt. Außerdem soll's quälend langsam sein, die SQLite-DB übers Netz zu benutzen. Hat da jemand Erfahrungswerte?

Bei Punkt 4 wäre die hauptsächliche Bearbeitung der Bilder erstmal lokal, dann müsste
Importiert und Synchronisiert werden (mit den ganzen Nachteilen, aber halt seltener).

Wie sieht Euer Workflow aus?
Übersehe ich einfach irgendwas?

Vielen Dank schonmal,

Hans
 
Bei Punkt 3 - hab ich zumindest gelesen - führt ein Parallelzugriff dazu, dass die
Lightroom-DB stirbt. Außerdem soll's quälend langsam sein, die SQLite-DB übers Netz zu benutzen. Hat da jemand Erfahrungswerte?
SQLite vertraut auf das Filesystem und nutzt File-Locks, wenn das fehlschlägt oder vom (Netzwerk)-Filesystem gar nicht implementiert ist, kann es zu einem Problem kommen. NFS z.B. implementiert das gerne nicht.

So wie es aussieht, legt LR selbst auch nochmal eine lock-datei an, die als extra File die Datenbank als gelockt markiert und sich nicht auf das FS verlässt.

Es ist also nicht davon auszugehen, dass die DB sofort im Eimer ist, wenn man aus Versehen LR doppelt startet. In den meisten Fällen sollte LR das merken und verhindern.
In Verbindung mit der automatischen, wöchentlichen Sicherung der DB scheint mir das Risiko im privaten Umfeld vertretbar.

Lässt man die Entwicklungseinstellungen noch in die xmp-Files schreiben, verliert man ja auch im DB-Fehlerfall die Bearbeitung nicht.

Über die Geschwindigkeit kann ich nichts sagen.
 
Danke für die Antwort. Vor allem die Info mit dem Lockfile war mir neu.

Nachdem der Fileserver ohnehin alle 2 Stunden einen Snapshot anlegt werde ich das mal bei Gelegenheit ausprobieren und einen ausführlichen Bericht dazu ins Forum stellen.

Allerdings kann ich nicht versprechen, dass das vor dem nächsten Wochenende passieren wird.

Grüße,

Hans
 
Danke für die Antwort. Vor allem die Info mit dem Lockfile war mir neu.
Das Lock-File ist nur Text mit dem Pfad zum öffnenden Prozess und einer Zahl.
Es sieht für mich so aus als wenn LR das zusätzlich zu der eigentlichen Lock-Funktion von SQLite (DB-Format LR) macht.

SQLite selbst legt ein -journal-File an.

Ist ja nicht eilig, aber ein Bericht wäre super, wenn Du da mal drauf guckst.
 
Die Snapshots würde je nach Bearbeitungsmenge vielleicht auch jede Stunde (je nach System und Arbeitsmenge vielleicht auch öfter) durchführen. Zusätzlich würde ich z.B. mittags 12:30 ein "Wartungsfenster" einfügen, wo man ein Backup bei geschlossener DB durchführen kann. Wenn man dann noch ein handschriftliches Protokoll der bearbeiteten Bilder pflegt, lässt sich im Fehlerfall zumindest schnell nachvollziehen, wo ein Verlust aufgetreten ist.
 
Bericht "Lightroom auf Netzlaufwerk"

Weil ich mich jetzt doch noch kurzfristig dem Thema angenommen habe,
kommt hier der Bericht zum Thema "Lightroom im Netzwerk nutzen".

Disclaimer:
Hier folgen meinen eigenen Erfahrungen. Eure können anders sein.
Ich garantiere weder den Erfolg dieses Vorgehens, noch bin ich
verantwortlich für irgendwelche Datenverluste und Verdienstausfälle.


Aber nun los:

Zum Aufsetzen waren folgende Schritte nötig:
  1. Kopieren der Lightroom-DB nebst Vorschaubildern auf den Server.
    (bei mir hier als Laufwerk Z: eingebunden)
  2. Falls nicht ohnehin schon der Fall bzw. gewünscht: Bilder auf
    das Netzlaufwerk kopieren.
  3. Da Lightroom sich weigert, auf Netzlaufwerken einen Katalog zu
    öffnen, wird der Software mit folgendem Befehl ein lokales
    Laufwerk vorgegaukelt:
    subst X: Z:\Fotos\Lightroom
  4. Die Lightroom-DB auf Laufwerk X: öffnen.
    Dieses erscheint im Explorer jetzt als "Nichtverbundenes Netzlaufwerk",
    woran man sich nicht stören sollte.
  5. Falls nötig, die Bilder in der Bibliotheksansicht wieder den
    Bilddateien auf dem Netzlaufwerk zuordnen.
  6. Hat bis hierhin alles geklappt und Lightroom zeigt die Bilder
    nebst Vorschaubildern an, dann muss das Pseudo-Laufwerk noch
    dauerhaft eingebunden werden.
    Dazu: Im Startmenü von Windows das Verzeichnis "Autostart" öffnen
    (rechte Maustaste - "Öffnen") und eine Datei mit der Endung
    .bat und folgendem Inhalt ablegen:

    subst X: Z:\Fotos\Lightroom
  7. optional:
    Auf der lokalen Platte den Katalog und das Preview-Verzeichnis
    umbenennen, um sicherzustellen, dass die Versionen vom Netzlaufwerk
    verwendet werden.


Verwendete Systeme:
Fileserver:
- CPU: AMD Athlon II X2 250
- RAM: 2 GB
- OS: Ubuntu 10.04 LTS Server 64bit
- Disk: 4x 1.5TB in Software-RAID 5
- FS: BTRFS mit 2stündlichem Snapshotting
- Netz: samba 3.4.7 über GBit

Workstation:
- CPU: Intel Pentium 4 2.6GHz
- RAM: 2 GB
- OS: Windows 7
- Lightroom 3.6


Erstes Fazit:
Die Workstation hat so wenig CPU-Leistung, dass sie
den Flaschenhals im System bildet.
Es ist gefühlt genauso langsam wie vorher auch.

CPU-Leistung auf dem Server ist kaum messbar,
smbd geht beim Öffnen eines neuen Bilds auf 10% hoch.

Die Datentransferleistung liegt mit maximal 5MB/s
deutlich unter dem, was der Server leistet.

In den nächsten Wochen ist eine schnellere Workstation
geplant, dann gibt's ein Update.


Grüße,

Hans
 
Zuletzt bearbeitet:
Die Snapshots würde je nach Bearbeitungsmenge vielleicht auch jede Stunde (je nach System und Arbeitsmenge vielleicht auch öfter) durchführen. Zusätzlich würde ich z.B. mittags 12:30 ein "Wartungsfenster" einfügen, wo man ein Backup bei geschlossener DB durchführen kann. Wenn man dann noch ein handschriftliches Protokoll der bearbeiteten Bilder pflegt, lässt sich im Fehlerfall zumindest schnell nachvollziehen, wo ein Verlust aufgetreten ist.

Für eine berufliche Nutzung ist das sicher ein guter Tipp.
Für meine Zwecke reichen 2h völlig aus.

Übrigens sollte man beachten, dass es einige Filserver gibt, bei
denen die Performance massiv einbricht, wenn zuviele Snapshots aktiv sind.

Das ist z.B. dann der Fall, wenn der Snapshot-Mechanismus von
Linux-LVM verwendet wird. Daher empfehle ich Dateisysteme, die
eine entsprechende Funktion haben (in meinem Fall btrfs).

Was Backup betrifft bin ich mit Crashplan recht zufrieden.

Grüße,

Hans
 
Okay, genau so viel hatte ich auch schon ausprobiert :)

Beim Laden von RAWs usw. sind auch schnelle CPUs der Flaschenhals. Ein RAW hat sagen wir mal < 30 MB/s und für ein Rendering daraus braucht auch eine flotte CPU >2 Sek..
Die dabei erzeugten Cache-Dateien liegen lokal.

Previews sind vergleichsweise klein.

Der Traffic in und aus der DB ist sehr moderat, das sind vor allem Einstellungen und AFAIK auch die kleinsten Thumbnails.

Spannend ist ja jetzt die Frage, ob es klappt bzw. nicht, wenn Du versuchst den Katalog von zwei Rechnern zeitgleich zu öffnen.
 
Übrigens sollte man beachten, dass es einige Filserver gibt, bei
denen die Performance massiv einbricht, wenn zuviele Snapshots aktiv sind.

Ja, wobei dies auch im Midrange/Enterprise-Umfeld nicht alle Systeme gleichermaßen beherrschen. Eine HP EVA (SAN-Storage) unterstützt lange nicht soviele Snapshots, wie ein z.B. NetApp MetroCluster. Aber ich denke weder das eine noch das andere wird hier im Forum Verwendung finden. Wenn überhaupt werden NAS-Systeme eingesetzt werden. Im Grunde ist es, wie immer, eine Güteabwegung. Will ich zusätzliche Snapshots oder vertraue ich auf die geringeren Backups.

Was ich vergessen hatte... Snapshots sind ganz nett, allerdings sollte man auch einen Recoverytest vornehmen. Wenn die DB nicht hochfahren, nützen einem auch halbstündliche Snapshots nichts. :)
 
Spannend ist ja jetzt die Frage, ob es klappt bzw. nicht, wenn Du versuchst den Katalog von zwei Rechnern zeitgleich zu öffnen.

Eigentlich müßte ja die Lockdatei im Katalogverzeichnis abgelegt werden und daher dürfte es meines Erachtens nicht funktionieren.
Falls nicht, hat man ziemlich sicher ein ernsthaftes Problem und der Katalog dürfte hin sein.
Sowas kann man ja mal mit einer Kopie ausprobieren.

Jürgen
 
Auch ohne das lock-file sollte SQLite den sogar gleichzeitigen Zugriff verarbeiten, falls das Netzwerk-Filesystem mit macht
 
Ein klitzekleines Update:

Die schlechte Performance lag tatsächlich nur am Client.

Mit dem jetzigen Intel i5 + 8GB RAM macht Lightroom
richtig Spaß. Dass Datenbank und Fotos auf dem Server
liegen, fällt - mir zumindest - nicht auf.

Gleichzeitigen Zugriff habe ich noch nicht probiert, mangels
Zeit und Notwendigkeit.

Grüße,

Hans
(der mittlerweile erst recht nicht kapiert, wieso Adobe
sich gegen den Katalog auf Netzlaufwerken sträubt)
 
(der mittlerweile erst recht nicht kapiert, wieso Adobe
sich gegen den Katalog auf Netzlaufwerken sträubt)

Ich habe schon vor langer Zeit im Adobe-Forum einen Beitrag gelesen, wo ein Adobe-Mitarbeiter genau solche Sachen versucht hatte und damit den Katalog unwiderbringlich zerstört hat.

Es ist was anderes, ob das jemand auf eigenes Risiko nur für sich macht, oder ob eine Softwarefirma das als offizielle Möglichkeit anbietet. Im zweiten Fall muß das dann einwandfrei und immer funktionieren. Und das kann Adobe scheinbar nicht garantieren und läßt es daher lieber.

Jürgen
 
(der mittlerweile erst recht nicht kapiert, wieso Adobe
sich gegen den Katalog auf Netzlaufwerken sträubt)

Da gibts mehrere Gründe .

1. Performance ist ggf schlechter , das ist aber sicher eine Abwägungsfrage
2. SQL Lite ist gemacht als Datenbank auf einem Device , aber nicht gedacht als Client Server System
3. Aufgrund der Einschränkung ist die Anwendung auf korrekte Implementierung von loking Mechanismen im Netzwerkfilesystem angewiesen. Da kann es sowohl bei Unix ( Linux ) und auch Win Probleme geben

Deshalb wird es nicht unterstützt. Übrigens aufgrund 3 schon von SQL Lite nicht, wäre also seltsam wenn Adobe es dann unterstützen würde.

Allerdings finde ich die Einschränkung auch ärgerlich, ich vermute mal daß das DB System gewählt wurde, weil es eben passiv ist und es keinen zusätzlichen Admin Aufwand gibt, dafür musste man dann eben die Einschränkung in Kauf nehmen.
 
WERBUNG
Zurück
Oben Unten