Photo Station Lightroom Export Plugin: PhotoStation Upload

[nsan]

Hallo Martin,

das logfile hab ich dir per pn geschickt.

die fehlermeldung in Lr hatte ich exakt abgetippt. Im Fehlerdialog steht zusätzlich noch: Die Sammlung konnte nicht aktualisiert werden.

grüße, Kevin.

 

[flingo]

Ich weiss schon, was es ist, Du bist halt mein bester "Export"-Tester! Ich arbeite meistens mit Published Collections: es ist mal wieder eine Variable, die nur beim Publishen und nicht beim Exportieren gesetzt wird. Krieg ich hin!

Muss ich dann manuell abbrechen, weil von selbst geht nichts.

Bei Programmabsturz wird dieser Fortschrittsbalken nicht abgeräumt, obwohl der Plugin-Prozess beendet wurde. Hmm, das Plugin sollte ja eigentlich nicht abstürzen ...

Alle Dateien sind aber auf der DS angekommen.....seltsam....

Nein, das ist nicht seltsam, sondern so programmiert: weil ein gerade hochgeladenes Foto oder Video noch nicht sofort über die PhotoStation API sichtbar ist (kann Sekunden bis Minuten dauern), habe ich den Upload in 2 Phasen aufgeteilt:

• erst alle Bilder und Videos hochladen
• dann die Metadaten für Videos (und nur für Videos) per PhotoStation API hochladen

Dadurch wiird die Wartezeit für jedes einzelne Video verringert. Deshalb sieht man - wenn man published in der ersten Phase auch, wie der obere Fortschrittsbalken voran geht, obwohl die Videos noch nicht in den Zustand "Published" über gehen.

In der nächsten Version werden dann nach spätestens 10 hochgeladenen Videos erstmal die Metadaten hochgeladen, damit man - falls mal das Plugin abstürzt - nicht wieder komplett von vorne anfangen muss.

 

[flingo]

das logfile hab ich dir per pn geschickt.

Den Anhang kann ich leider nicht öffnen, der Link führt auf eine Fehlerseite. Mir ist auch gar nicht klar, ob man per PN einen Anhang schicken kann, ich sehe nicht mal den Knopf für Anhänge, wenn ich PNs schreibe.

@Moderator: geht das überhaupt?

@nsan, schick mal das Logfile per Anhang in diesem Thread.


Grüße, Martin

 

[appel2000]

Bester Export Tester nehm ich mal als Kompliment
Wobei ich doch evtl. mal auf publish umsteige.

Wo war nochmal der Unterschied in der Praxis?

Nachdem das Plugin mit dem genannten Fehler aussteigt, bleibt der Balken bei "Uploading Metadata for Videos" stehen....
diesen Vorgang muss ich dann manuel mit dem klick aufs Kreuzchen beenden...von alleine ist nicht!

 

[nsan]

Anhang anzeigen PhotoStatLr.txt

jetzt aber

 

[flingo]

Got it!
Ja, da war noch ein Bug/Schreibfehler in PSUploadTask.lua, Zeile 279

	vinfo.srcDatvinfo = metaDateTime

Der wirkt sich aus, wenn Du ein Video hast, das kein Aufnahmedatum gespeichert hat im Video-Header. Den Fehler hatte ich gestern schon bei mir gefixt:

	vinfo.srcDateTime = metaDateTime

Dann werd ich mal ein Release mit 2 Bugfixes machen, sollte dann morgen aufliegen.

Schönen Abend noch.

 

[flingo]

Wobei ich doch evtl. mal auf publish umsteige.
Wo war nochmal der Unterschied in der Praxis?

Ach, bleib mal bei Export, dann testet das wenigstens EINER!

Published Collections haben den genialen Vorteil, dass man sich keinen Kopf mehr machen muss, welche Fotos man jetzt nochmal hochladen muss, weil man sie nach dem letzten Hochladen nochmal editiert oder getaggt hat. Das merkt sich dann alles Lr für Dich. Desweiteren gehen diese Metadaten-Download/Sync-Geschichten nur mit Published Collections.

Aber wer braucht schon sowas.

Nachdem das Plugin mit dem genannten Fehler aussteigt, bleibt der Balken bei "Uploading Metadata for Videos" stehen....
diesen Vorgang muss ich dann manuel mit dem klick aufs Kreuzchen beenden...von alleine ist nicht!

Ich weiß. Wenn das Plugin abstürzt, bleibt das hängen. Meine Lösung ist: das Plugin soll nicht abstürzen, deshalb Bugfixes...

 

[nsan]

Kann es sein, dass der gps tag beim video von der DS Photo app nicht interpretiert wird? Im Browser sehe ich die Maps aber in der iOS App nicht.

Grüße, Kevin

 

[flingo]

Das ist gut möglich. DSPhoto auf Android zeigt bei den Videos, die ich mit GPS hochgeladen habe, auch weder unter Informationen/GPS noch bei Standort-Tag irgendwas an. :-(
Das scheint mir ein Bug in der DSPhoto App (Android und iPhone). Aber, hey cool, DSPhoto auf Windows Phone zeigt die Map an.

 

[nsan]

Hi Martin,

eine Verständnisfrage bzgl. der Video, die mit PhotoStatLr aus einer Publish Collection auf die Synology geschickt werden bzw. auch grundsätzlich zur Verarbeitung auf der Synology selbst. Wenn Videos published werden fängt die Synologie manchmal an, einige (nicht alle) Videos zusätzlich zu konvertieren. Ich habe jetzt 2 Gedankengänge: einmal die unterschiedlichen Auflösungen, die sinnvollerweise in Lr gerendert werden (ich lade als additional Video resolution nur 720p hoch) und einmal unterschiedliche Dateiformate (ich habe die Auswahl "Original, unbearbeitete Datei" im Plugin ausgewählt, in den meisten fällen handelt es sich um *.mov Dateien).

Was passiert auf der Synology, bzw in welchen fällen muss sie zusätzlich konvertieren? Ich vermute, das liegt sicher auch an meinen Einstellungen, die ich im DSM gemacht habe - aber so grundsätzlich... wie vermeidet man den zusätzlichen Rechenaufwand auf dem NAS?

Werden da noch andere Auflösungen bzw. noch andere Container erstellt. Wenn ich das richtig sehe, liegen später im Photo Ordner wieder die mov Dateien, aber der Container der in der PS angezeigt wird ist mp4?

hast du da Erfahrungswerte?

Grüße, Kevin

 

[nsan]

Was mit grad keine Ruhe lässt - ich muss immer wieder feststellen, es ist der absolute Wahnsinn was du da auf die Beine gestellt hast, Martin.
Auch wenn man hier zum größten Teil nur irgendwelche Fehler zurückmeldet...

 

[flingo]

Was passiert auf der Synology, bzw in welchen fällen muss sie zusätzlich konvertieren?

Oh ja, dazu kann ich was sagen, nachdem ich letztes WE alle meine knapp 200 Videos nochmal mit Metadaten hochgeladen habe und dann feststellen musste, dass die Diskstation immer langsamer wurde und auf einmal ein Backlog von 167 zu konvertierenden Videos da waren, obwohl ich der Meinung war ich das eigentlich im Griff hätte. Lange Rede, kurzer Sinn, sollte in der 5.4.2 behoben sein (hoffentlich), ich hab's blöderweise nicht mal in den Release Notes erwähnt. Eigentlich kann man einen eigenen Wiki-Artikel dazu schreiben...

Also nach letztem Erkenntnisstand ist es so, dass die Diskstation immer dann ein Flashvideo generieren will, wenn man ein Video ohne begleitendes MP4-Video hochlädt. Das ist blöderweise auch dann so, wenn das Originalvideo schon MP4 ist.

In den folgenden Fällen ist das dann nicht passiert:

• wenn Du eine additional video resolution für die Auflösung des Videos definiert hattest
• Bei Videos, die hard-rotated wurden
• Bei Videos, die nicht auf .MP4 enden (.mov, .avi,...)

In den Fällen hat das Plugin mindestens eine MP4-Version generiert und mit hochgeladen und die Diskstation war zufrieden.

Wenn das hochzuladene Video selbst schon MP4 war (und keine der o.g. Bedingungen zutrafen), habe ich bisher kein zusätzliches MP4 mit hochgeladen, weil die PS damit umgehen kann und daraus automatisch einen Link im zugehörigen @eaDir-Verzeichnis erzeugt. Was mir aber erst am Wochenende aufgefallen ist, ist die Tatsache, dass auch in diesem Fall der Flash-Generator loslegt...

Deswegen: ab Version 5.4.2 lade ich im o.g. Fall das Original-MP4 (ohne Konvertierung) zweimal hoch, einmal als Begleitvideo, einmal als Original. Damit ist die Diskstation wieder zufrieden, alle 167 zu konvertierenden Videos lösten sich in Luft auf und in die @eaDir-Verzeichnissen findet sich kein einziges Flashvideo (.flv) mehr. In der Photo Station findet man bei diesen Videos dann zwei Auflösung: Original und HIGH, MEDIUM oder Low (je nachdem), beide Videos sind aber identisch.

Jetzt kann man natürlich meckern, dass das Platzverschwendung ist. Ja, das ist Platzverschwendung, aber weniger nervenaufreibend. Alternativ kann man mit "Additional Video Resolutions" arbeiten, dann wird weniger Platz benötigt aber auf Kosten einer Videokonvertierung auf dem Rechner.... Nichts ist umsonst!

Ich hoffe, dass ich alle Video-Variationen nun korrekt beachtet habe, bin mir aber nie 100% sicher...

Und wenn Euch das Tool gefällt, ehrlich: macht eine schöne Spende für einen guten Zweck, ich beteilige mich!

 

[nsan]

Verstehe. Aber das deckt sich nicht ganz mit meinen Beobachtungen. Ich habe im Veröffentlichungsmanager die Option der zusätzlichen Auflösung angehakt. Und soweit ich das verstehe, gilt die Einstellung für alle published und published Smart collections, die darin angelegt sind. Trotz 5.4.2. fängt die synology vereinzelt an zu konvertieren...

Ich schaue grad in der PS in den Einstellungungen unter Konvertierungseinstellungen. Dort sind alle Alben angehakt. Theoretisch kann man das doch komplett ausschalten, oder? Sowohl Fotos als auch Videos werden ja schon in Lr entspr. aufbereitet.

 

[flingo]

habe im Veröffentlichungsmanager die Option der zusätzlichen Auflösung angehakt. Und soweit ich das verstehe, gilt die Einstellung für alle published und published Smart collections, die darin angelegt sind.

Genau. Wichtig aber: diese additional video resolutions sind abhängig von der Ausgangsauflösung. Du musst dann also für alle drei (High, Medium, Low) Auflösung eine zusätzliche Auflösung wählen um für alle Videos auf der sicheren Seite zu sein.

Trotz 5.4.2. fängt die synology vereinzelt an zu konvertieren...

Kontrolle wäre mal auf der Konsole

find /volume1/photo -name '*.flv'

Damit findest Du alle Flash videos, die von der Diskstation generiert wurde. Wenn Du in einem dieser Unterzeichnisse neben SYNOPHOTO_FILM.flv und SYNOPHOTO_FILM_H264.mp4 noch weitere .mp4-Dateien findest, wäre meine Theorie widerlegt. Lass es mich wissen!

Ich schaue grad in der PS in den Einstellungungen unter Konvertierungseinstellungen. Dort sind alle Alben angehakt. Theoretisch kann man das doch komplett ausschalten, oder? Sowohl Fotos als auch Videos werden ja schon in Lr entspr. aufbereitet.

Das könntest Du mal probieren. Ich habe da auch schon herum experimentiert, war mir aber nicht so sicher, ob es das macht, was es soll. Wichtig: es gibt sowohl beim Indizierungsdienst als auch in der Photo Station entsprechende Einstellungen: beide müssen deaktiviert werden.

Grüße, Martin

 

[mike196]

Servus Martin,

ich reihe mich ein in die Liste der Beifall spendenden Bewunderer Deiner App.
Nun bin ich nur bedingt beschlagen, was Programmierung angeht und auch in LR noch Novize. Bisher habe ich mit iPhoto gearbeitet und habe die Bilder manuell auf die PhotoStation hochgeladen. Allerdings war dies immer mit erheblichem Aufwand verbunden, da ich auf der PS folgende Datei-Struktur habe:

Name_1
-- /Jahr1
---- /Monat1
----/Monat2
----/Monat3
-- /Jahr2
---- /Monat1
----/Monat2
----/Monat3

Name_2
-- /Jahr1
---- /Monat1
----/Monat2
----/Monat3
-- /Jahr2
---- /Monat1
----/Monat2
----/Monat3

also z.B:

Hans
--/2016
----/01_Januar
----/02_Februar
----/03_März

--/2017
----/01_Januar
----/02_Februar
----/03_März
etc.

Warum eine derartige Struktur? Wir betreiben die PS als zusätzlichen Service für die Eltern unserer Kinderkrippe. Die können sich auf der PS die Bilder ihrer Kinder ansehen und herunterladen. Da ich nicht alle Bilder einfach in einen großen Topf werfen will, habe ich mir diese kindbezogene Struktur ausgedacht.

Erlaubt nun Photo StatLr, wenn exakt diese Struktur als Sammlung in Lr angelegt ist, diese Struktur auch 1:1 auf die PS zu exportieren (Export reicht, da die Bilder nicht mehr verändert werden) und wenn dann neue Monate und Jahre hinzukommen, diese ebenfalls 1:1 auf der PS nachzuziehen? Und gibt es einen Weg, eine solche Struktur in Lr per Script anzulegen?

Ich hoffe ich habe mich halbwegs verständlich ausgedrückt und sag schon mal herzlichen Dank für jegliche Unterstützung.

Beste Grüße
Peter

 

[flingo]

Hallo Peter,
danke für den Beifall, wobei: der StatLr steht ja nicht so gerne auf der Bühne, sondern sitzt in der Loge und gibt freche Kommentare.

Vorneweg: das ist doch eine schöne Anforderung und ich denke, das ist mit einem überschaubaren Aufwand mit dem Plugin machbar.

Das Zauberwort hierfür heißt Collection Set Mirroring bzw. Metadata placeholders, das habe ich in den beiden Wiki-Einträgen (siehe Links) beschrieben. Man muss dafür nicht programmieren können, aber Kenntnisse in Regular Expressions helfen, sind aber in Deinem Fall nicht nötig...

Noch ein paar Vorüberlegungen:

• ich nehme mal an, dass Deine Fotos nicht immer genau einem Kind zugeordnet sind, weil Krippenkinder spielen sicherlich auch mal miteinander und dann soll das Foto ja bei beiden Kinder in die Sammlung, oder?
• eine Sammlungshierarchie mit Jahr und Monat ist zwar schön, macht aber einen unnötigen Mehraufwand, wenn sich der Sinn der Hierarchie erst beim Upload auf die Photo Station ergibt, das bekommt man pflegeleichter hin
• Export wird nicht gehen, es muss mit Published Collections gemacht werden, weil Du für jede Collection (== Kind) eine andere Definition des Zielverzeichnisses benötigt wird
• wenn Du den Kindern je ein Keyword zuordnest, kannst Du ggf. auf Sammlungen (Collections) verzichten und brauchst nur eine Photo StatLr Published Collection pro Kind verwalten

Der erste Punkt in der Liste macht die Sache so schwierig (ist im Wiki erklärt), ansonsten könntest Du alles mit einer einzigen Published Collection abfrühstücken.

Vorschlag 1 - je eine Collection und eine Published Smart Collection pro Kind:
Die Published Smart Collection definierst Du wie folgt (Beispiel 'Hans'):

• entspricht jeder der folgenden Regeln
• Sammlung ist 'Hans'
• Target Album: 'Hans/{Date %Y/%m_%B}
• Create Album, if needed: ja
• Flat Copy to Target
• den Rest nach Belieben

Vorschlag 2 - Verwendung von Keywords für Kinder, keine Collections, eine Published Smart Collection pro Kind b:
Die Published Smart Collection definierst Du wie folgt (Beispiel 'Hans'):

• entspricht jeder der folgenden Regeln
• Keyword ist 'Hans'
• Target Album: 'Hans/{Date %Y/%m_%B}
• Create Album, if needed: ja
• Flat Copy to Target
• den Rest nach Belieben

Nicht so schwer, oder? ;-) Lies mal in Ruhe die beiden Wiki-Artikel und vergleich mal mit meiner Antwort, vielleicht fallen Dir noch andere Lösungen ein. Wenn Fragen, fragen!

Viel Spass beim Probieren.

Grüße, Martin

 

[mike196]

Servus Martin,

erst mal herzlichen Dank für die schnelle Antwort. Das Prinzip habe ich nun halbwegs verstanden, an der konkreten Umsetzung hapert es noch gewaltig.

Dein Vorschlag 2 wäre mir am sympathischen. Oder, was der Knüller schlechthin wäre: nur eine Published Smart Collection für alle Kinder und StatLr analysiert die Bilder entsprechen der Schlagworte und kopiert sie in die passenden Ordner.

Meine bisherige Vorgehensweise war nämlich derart, dass ich alle Bilder, auf denen bis zu max. 3 Kinder abgebildet waren, auf die Ordner dieser 3 Kinder verteilt habe. Waren mehr Kinder auf dem Bild, kam dieses in einen Topf, der nach Jahr, dann der jeweiligen Betreuungsgruppe und darunter nach Monat organisiert war.
Wenn ich Deine Ausführungen richtig verstanden habe, würde StatLr ein Bild entsprechend der Verschlagwortung auch in mehrere Ordner auf der PS ablegen und, sofern ein Ordner nicht existiert, diesen auch neu anlegen. Ist das korrekt?
Meine Monatsordner habe ich immer so benannt: 01_Januar, 02_Februar.... ließe sich so etwas auch umsetzen?

LG Peter

 

[flingo]

Hallo Peter,

...nur eine Published Smart Collection für alle Kinder...

Genau das geht leider nicht, weil ein Foto in einer Published Collection genau eine Remote-Id hat. Mit dieser Remote-Id ist ihr Publish-Status verbunden: To publish, Published, To Re-publish
Die Remote-Id ist bei dem Plugin der Pfad auf der Photo Station, wo es abgelegt ist. An der Remote-Id hängt auch die Funktion "Show in Photo Station", die genau zu dem Bild in seinem Zielordner auf der Photo Station springt.

Also eine Published Collection pro Kind, weniger geht nicht. Sinnvollerweise unter einem gemeinsamen Published Collection Set (z.B.'Krippe'), dann kann man mit einem Klick auf "Publish" auf das Collection Set alle neuen/geänderten Fotos von allen Kindern publishen.

... würde StatLr ein Bild entsprechend der Verschlagwortung auch in mehrere Ordner auf der PS ablegen....

Nee, wenn mehrere Schlagwörter drin wären, würde es daraus eine Ordnern names 'Hans, Willi, Jupp' machen.

...sofern ein Ordner nicht existiert, diesen auch neu anlegen

ja, das stimmt.

eine Monatsordner habe ich immer so benannt: 01_Januar, 02_Februar.... l

Genau: der u.g. Metadata placeholder {Date %Y/%m_%B} macht aus einem Foto mit Aufnahmedatum 20.01.2015 den Verzeichnisbaumnamen '2015/01_Januar' (%Y = Jahr 4stellig, %m = Monat 2-stellig, %B = Monatsname), andere Formatierung sind möglich, findet man in der Lr SDK-Doku, die ich aus Coypright-Gründe nicht in der Doku drin habe, aber im wesentlichen ist das identisch mit den Formaten des Linux date Kommando.

Falls Du kein Problem mit Datenschutz/Zugriffsrechten hast ("ich will nicht, dass andere Eltern die Bilder von meinem Kind anschauen können") kannst Du natürlich auch die Smart Alben der Photo Station benutzen: es werden von der Photo Station automatisch dynamische Smart Alben pro Keyword erzeugt. Dann brauchst Du alle Fotos nur einmal exportieren/publishen, die liegen dann auch nur einmal auf der Photo Station, sind aber automatisch auch über die Smart Alben auffindbar.

Dann wäre Lösung 3:
- die Kinder werden ge-keyworded
- genau eine Published (Smart) Collection mit Jahres/Monatssortierung (Target Album = {Date %Y/%m_%B}), in der alle Fotos beinhaltet sind
- Fotos werden also nur einmal hochgeladen und liegen an genau einer Stelle
- die Fotos können den entweder über die Album-Hierarchie gefunden werden oder über das entsprechende Smart-Album

Das ist dann eine sehr pflegeleichte Variante. Du benutzt das Plugin um eine ordentliche Album-Hierarchie zu bauen und nutzt die Intelligenz der Photo Station für keyword-baiserte Suche.

Grüße, Martin

 

[flingo]

V5.5.0: Download von GPS Infos von der Photo Station

Nachdem das Geo-tagging von Fotos über Google-Suche von Adresse/Ortsname in der Photo Station --> Standort Tag bearbeiten nun wieder funktioniert, habe ich mir das Thema nochmal angeschaut.
Ich habe nun endlich verstanden, dass man über Standort-Tag bearbeiten einem Foto/Video tatsächlich 2 unterschiedliche GPS-Koordinaten zuweisen kann:

• Über die Adresse-Suche bekommt man ein Standort-Tag (Adresse, Ort, Land usw.) und einen blauen Pin
• Über Rechtsklick in die Map kann man einen roten Pin setzen

Die Pins stellen die eigentlichen GPS-Koordinaten dar. Der rote Pin ist dabei besser als der blaue, denn er wird von der Photo Station auch in das Foto geschrieben. Deshalb sieht man diese GPS-Daten dann auch bei den Bildinformationen und wenn man das Foto herunterlädt, sind die GPS-Daten mit drin.

Die Version 5.5.0 erkennt beim Download nun auch diese GPS-Koordinaten und kann sie herunterladen (konfigurierbar), dabei hat der rote Pin Vorrang vor dem blauen Pin, der blaue Pin wird nur verwendent, wenn kein roter da ist. Damit kann man jetzt noch mehr Foto-Pflegearbeit an die Lieben weiter delegieren und danach entspannt die Ergebnisse nach Lr übernehmen. Herrlich, oder?

Ein wichtiger Hinweis noch: Standort-Tags (Adresse, Ort, Land usw.) gibt es sowohl in Lr als auch in der Photo Station, ein Austausch ist aber in beide Richtung nicht möglich. Von daher macht es keinen Sinn diese in der Photo Station intensiv zu pflegen, bei Fotos bleiben sie zwar auch nach dem nächsten Upload von Lr erhalten, bei Videos werden sie aber beim nächsten Upload gelöscht.

Viel Spaß damit.

Martin

 

[nsan]

Hallo Martin,

hab grad GPS für eine published collection von der PS zu Lr runtergeladen und dabei wird ein Video rejected.

ERROR: PSPhotoStationAPI.callSynoAPI: SYNO.PhotoStation.Photo returns error 456
20:38:18, INFO : Get metadata: 2011/abc/IMG_0795.mov -  location changed from '0/0' to 'xx.873251/x.607025', keywords to remove 'x','y','z' include synonyms or parent keyword (not allowed), removal ignored, done, 1 rejected changes, Re-publish needed.

was kann das bedeuten?

Grüße, Kevin