Photo Station Lightroom Export Plugin: PhotoStation Upload

[eisenherz]

Hallo!

PhotoStatLR läuft wieder wie gewünscht
PhotoStatLr deinstalliert und wieder neu installiert

Weiß der Kuckuck was da klemmte

 

[Kermit2k]

Hallo,

ich habe ein Problem mit dem Videoexport auf Mac OS Catalina (via Veröffentlichen). Es scheitert immer an der Konvertierung der Videos mit ffmpeg. Eine erste Analyse ergab, dass das Plugin eine alte ffmpeg-Version verwendet (via Synology Photo Station Uploader).

• 20:05:35, INFO : !!! Warning: Unsupported ffmpeg version 1.2.1 may not work as expected, please use ffmpeg V 4.x or higher!!!
• 20:05:35, TRACE: "/Applications/Synology Photo Station Uploader.app/Contents/MacOS/ffmpeg/ffmpeg" -i ...

Ein Update auf die aktuellste ffmpeg-Version (via ffmpeg-Website) brachte leider auch keinen Erfolg. Die zweite Analyse ergab, dass folgendes das Problem ist:

• 20:05:42, TRACE: qtfstart report:
  ===========================================================================
  sh: /Applications/Synology Photo Station Uploader.app/Contents/MacOS/ffmpeg/qt-faststart: Bad CPU type in executable
  ===========================================================================

Habt ihr eine Idee, wie ich den Fehler wegbekomme bzw. wieder Videos veröffentlicht bekomme? Es bricht immer an der gleichen Stelle mit dem "qt-faststart: Bad CPU type in executable" ab. Ich habe ein Macbook Pro Retina Late 2013 (2,3GHz QuadCore i7 mit 16 GB RAM).

Codiere ich die Videos manuell via Kommandozeile und ffmpeg (ohne qt-faststart) geht alles.

Im Endeffekt möchte ich 'nur' meine Originalvideos veröffentlicht haben, am besten noch mit Hard-Rotation. Umcodieren ist eigentlich in den meisten Fällen überhaupt nicht notwendig.

Eine Idee, wie ich das auf Mac OS hinbekomme? Das LogFile dafür kann ich auch gern zur Verfügung stellen.

Danke im Voraus!

Viele Grüße
Mirko

SideNote: CUDA von NVidia für Mac OS Catalina nicht mehr unterstützt, weshalb die Codierung via nv_enc auch fehlschlägt.

 

[TeXniXo]

Das Problem liegt in der 64-bit-Architektur. Catalina setzt nur noch auf 64-bit-Applikationen, die so ausgeführt werden können. Alle, die bisher auf 32-bit-Basis arbeiten, werden mit ähnlichen Fehlermeldungen quittiert bzw. abgebrochen.

D.h. Photo Uploader aktualisiert? Ich habe nachgesehen u konnte nicht feststellen, ob die aktuelle Version, die noch mit Juli 2019 datiert ist, bereits 64-bit-tauglich ist.

Da die DSM in Version 7 voraussichtlich in 2021-Q1erscheinen wird und dort angeblich die zwei Foto-Pakete (Photo Station und Moments) zusammengeführt werden und daraus "Synology Photos" entwickelt wird, ist eine zeitnahe Aktualisierung von Photo Uploader ziemlich unwahrscheinlich.

 

[Kermit2k]

Ah, vielen Dank für die schnelle Hilfe TeXniXo! Die Applikation Synology Photo Station Uploader (v1.4.5-093) ist zwar x64 (laut Go64.app), allerdings vermute ich stark, dass die darin enthaltenen Pakete qt-faststart und ffmpeg noch nicht x64 sind.

Gibt es die Möglichkeit "qt-faststart" in einer x64-Version zu beziehen und den Pfad im Plugin zu ändern? Oder "qt-faststart" zu überspringen? Ffmpeg selbst kann ich ja via alternativen Pfad bereits jetzt schon einbinden.

So hätte man zumindest ein Workaround.

 

[TeXniXo]

Codiere ich die Videos manuell via Kommandozeile und ffmpeg (ohne qt-faststart) geht alles.

Wenn du so erfolgreich bist, würde ich an deiner Stelle Automator verwenden und die Skripts dann z.B. via Tastaturkürzel oder Icon starten und gut ist?
Alles andere ist Frickelei und bedarf mehr Zeit, die mE nicht wert wäre.

Oder was spricht dagegen deiner Meinung nach?

 

[Kermit2k]

Dieser Workaround mit Automator und Scripts funktioniert bestimmt für mich (wobei ich mich mit Automator noch nicht beschäftigt habe), allerdings ist das für die anderen Mac-Nutzer des PhotoStatLR-Plugins eher nicht die Lösung. Und wie bereits gesagt, auch das Plugin greift nur auf ffmpeg zurück (was ja geht), nur das mit dem "qt-faststart" verursacht die Probleme. Evtl. kann man das mal im Code auskommentieren und testen, für was genau diese Funktion da ist erschließt sich mir nämlich leider noch nicht.

Trotzdem noch mal einen Riesendank an die Entwicklung des Plugins! Bis auf den Videoexport funktioniert es seit mehreren Versionen bei mir hervorragend!

 

[flingo]

Hallo Kermit2k,
der Sinn von qt-faststart ist hier beschrieben. Das Plugin versucht halt maximale Kompatibilität in alle Richtungen zu erhalten. Vermutlich brauchst Du diese Funktionalität überhaupt nicht und kannst das einfach mal auskommentieren, und zwar in PSConvert die Zeilen 767 - 782

--[[
    cmdline =     cmdlineQuote() ..
                    '"' .. h.qtfstart .. '" "' ..  tmpVideoFilename .. '" "' .. dstVideoFilename .. '" 2> "' .. outfile ..'"' ..
                cmdlineQuote()

    writeLogfile(4, cmdline .. "\n")
    if LrTasks.execute(cmdline) > 0 then
        writeLogfile(3, "  error on: " .. cmdline .. "\n")
        writeLogfile(3, "qtfstart report:\n" .. 
                        "===========================================================================\n".. 
                        LrFileUtils.readFile(outfile) ..
                        "===========================================================================\n")
        LrFileUtils.delete(passLogfile)
        LrFileUtils.delete(outfile)
        LrFileUtils.delete(tmpVideoFilename)
        return false
    end
]]

Dass CUDA unter Catalina nicht mehr unterstützt wird, ist wirklich schade, das bringt richtig Speed. Du musst dann halt ein anderes Video Conversion Preset nehmen.
Grüße, Martin

 

[Kermit2k]

Hallo Martin,

vielen Dank für deine ausführliche Hilfe, das bringt mich schon ein gutes Stück weiter. Leider funktioniert es noch immer nicht korrekt, kann ich dir eine PN mit meinem Debuglog schicken?

Danke und viele Grüße
Mirko

 

[flingo]

Ja, schick mal.
Grüße, Martin

 

[feilner]

Hallo,
inzwischen git es ja eine Beta version von DSM 7 und damit auch von eine Beta version von Synology Photos verfügbar. Hat jemand schon ausprobiert ob das Plugin angepasst werden muss?

Viele Grüße

Oliver

 

[flingo]

Hallo Oliver,
ja, hab ich. Es ist reichlich anzupassen, die API ist komplett neu. Ich bin seit Ende Oktober immer mal wieder an der Portierung und bin mittlerweile soweit, dass ein reiner Export schon geht. Für das Publishen fehlen mir noch viele Funktionen und an vielen Stellen ein Redesign. Ich denke, dass eine neue Version als Beta irgendwann Anfang nächsten Jahres fertig ist.

Im Vergleich zur Photo Station fehlen in Photos nach meinem Kenntnissstand aber mindestens folgende Funktionen:
- Kartenansicht
- Rating
- Kommentarfunktion
All das sind für mich ziemlich wichtige Funktionen, die Kartenansicht sogar das Killer-Feature der Photo Station. weshalb ich noch nicht auf DSM7/Photos umsteigen werde.

Grüße, Martin

 

[Nik]

Hallo zusammen,

@Martin: vielen herzlichen Dank für deinen persönlichen Einsatz und für das, was du mit dem Photo StatLr auf die Beine gestellt hast. So etwas hat mir gefehlt - wenn ich es dann zum laufen kriege.

Was ich bisher überprüft habe
- Eintrag NAS als URL oder IP - kein Unterschied
- Aufruf NAS über gleiche URL im Browser - geht, URL mit Zertifikat passt; mit IP wie zu erwarten Zertifikatsfehler, aber geht
- Upload mit Synology Photo Uploader erfolgreich
- Lr nach draußen telefonieren lassen (ich benutze LuLu als Firewall)
- Readme, Wiki und Forum hier gewälzt

Damit konnte ich Schritt für Schritt neue Fehlermeldungen generieren. Zuletzt gehen mir die Ideen aus und ich bin bei dem Fehler (Log siehe unten) hängen geblieben (auf einem Rechner - auf dem anderen komme ich noch nicht mal so weit). Bisher konnte ich noch kein Bild auf's NAS publishen.

Habt ihr nächste Schritte zum testen für mich?

14:42:46, INFO : PSInitPlugin:
PSUploader: '/Applications/Synology Photo Station Uploader.app/Contents/MacOS'
exiftool: '/usr/local/bin/exiftool'
ffmpeg: '/Applications/Synology Photo Station Uploader.app/Contents/MacOS/ffmpeg/ffmpeg'
14:42:46, INFO : PSInitPlugin: Successfully added 2 custom video export presets.
14:43:52, INFO : Environment: plugin: 6.9.4.20200526 Lr: 9.4 OS: 10.15.7.19H15 Lang: de
14:43:52, INFO : processRenderedPhotos starting
14:43:52, INFO : "exportParams":{"RAWandJPG":"false", "addVideoHigh":"None", "addVideoLow":"None", "addVideoMed":"None", "addVideoQuality":"2", "addVideoUltra":"None", "copyTree":"true", "createDstRoot":"true", "dstFilename":"", "dstRoot":"PhotoStatLr-Test", "exifTranslate":"true", "exifXlatFaceRegions":"true", "exifXlatLabel":"true", "exifXlatRating":"true", "hardRotate":"false", "isPS6":"true", "largeThumbs":"true", "locationTagField1":"{LrFM:isoCountryCode}", "locationTagField2":"{LrFM:country}", "locationTagField3":"{LrFM:stateProvince}", "locationTagField4":"{LrFM:city}", "locationTagField5":"{LrFM:location}", "locationTagSeperator":"-", "locationTagTemplate":"", "logLevel":"2", "orgVideoForceConv":"false", "orgVideoQuality":"3", "password":"***", "personalPSOwner":"", "proto":"https", "proto2":"https", "psPath":"/photo/", "psUrl":"https://--URL--/photo/", "psVersion":"68", "publishMode":"Publish", "renameDstFile":"false", "serverTimeout":"10", "serverTimeout2":"10", "serverUrl":"https://--URL--", "servername":"--URL--", "servername2":"", "sortPhotos":"false", "srcRoot":"/Volumes/Lightroom-DB/Bilder", "storeDstRoot":"true", "thumbGenerate":"true", "thumbQuality":"80", "thumbSharpness":"MED", "uploadTimestamp":"capture", "usePersonalPS":"false", "useSecondAddress":"false", "username":"nikadmin", "xlatLocationTags":"true"
}
14:43:52, ERROR: Initialization of Standard Photo Station at
https://--URL--
failed!
Reason: ErrorCode: -1004
14:43:52, INFO : Photo StatLr: Publish failed!: Initialization of Standard Photo Station at
https://--URL--
failed!
Reason: ErrorCode: -1004

14:43:57, INFO : Get comments: nothing to do.
14:43:57, INFO : Get ratings/metadata: nothing to do.

 

[flingo]

Hallo Nik,
das ist vermutlich ein Fehler der LrHttp-API von Lightroom. Setz mal den Loglevel auf DEBUG oder X-DEBUG und schau Dir das Logfile nochmal an. Wie sieht es mit einer http-Verbindung auf die lokael IP-Adresse der Diskstation aus?

 

[Nik]

Vielen Dank für die schnelle Rückmeldung, Martin!

LrHttp scheint schon mal richtig. Gleiches Ergebnis mit https/URL/photo oder http/IP/photo. Das hatte ich auch vorher schon beides versucht, nur nicht mit dem Log-Level. Ich bin auch nochmal die Konfiguration im DSM durchgegangen. Ich finde keinen weiteren Anhaltspunkt als Fehlerquelle.

21:13:46, TRACE: LrHttp failed
errorCode: cannotConnectToHost
name: Verbindung zum Server konnte nicht hergestellt werden.
nativeCode: -1004
21:13:46, TRACE: CheckForUpdate failed: Error "cannotConnectToHost" on http request:
Verbindung zum Server konnte nicht hergestellt werden.

 

[Nik]

Ich hab's gefunden. Viel hilft viel: ich hatte vor Ewigkeiten noch Radio Silence als Firewall zugefügt. Ausgeschaltet -> ich konnte direkt publishen. Freu mich drauf, jetzt tiefer einzusteigen ...

 

[hadi]

Hallo zusammen,

Ich habe Lightroom 5.7x und evaluiere gerade LrC, verwende dabei LrC V10.1 und PhotoStatLr V6.9.4 auf DSM 6.3 (neueste Version inkl. Update 3).
Zunächst einmal vielen Dank für die Arbeiten und Bereitstellung von PhotoStatLr!

Habe dazu folgende Fragen/Probleme (nach erfolgtem Export mit PhotoStatLr auf die PhotoStation ins Verzeichnis photos):

1. Im Export-Dialog kann ich die Einstellungen als Benutzervorgaben einmal anlegen/speichern, aber danach nicht mehr ändern. Die Checkbox ist immer disabled, siehe:
   
   Ist das so gewollt?
   
   
2. Das Datum der exportierten Bilder ist immer das aktuelle, obwohl "Photo/Capture Date/Time" ausgewählt ist. Anscheinend lädt er die Dateien hoch (und legt sie richtig mit CaptureDate an), beim Reinschreiben der Metadaten wird aber das Datum auf das aktuelle geändert (sieht gemäß Logfile so aus). Ist das so (bzw. ist es nicht möglich, auch beim Metadatenupload das CaptureDate beizubehalten)?
   
   
3. Wenn ich mir dann die eaDir Verzeichnisse anschaue, enthalten diese immer die wohl von PhotoStatLr erzeugten Thumbs (User PhotoStation?) und noch eins mit Namen SYNOPHOTO_THUMB_PREVIEW.jpg, das später erzeugt wurde und root gehört, siehe:
   
   Werden nicht automatisch alle benötigten Thumbs vor dem Upload erzeugt? Bzw. warum / wozu von wem wird später noch das _PREVIEW erzeugt?
   
   
4. Auch wenn ich beim Export-Dialog unten Standort-Tag auswähle, ist auf der PhotoStation im Smart-Album Standort-Tag nichts drin. Ist das nicht dafür gedacht, oder verstehe ich hier was falsch?
   
   GPS-Daten sind in den Bildern drin, die Kartenansicht in LR und der PhotoStation funktioniert.

Vielen Dank, Grüße und einen guten Rutsch

 

[flingo]

Hallo hadi,
zu 1) kann ich Dir nichts sagen, in Lr 6.x sieht der Dialog noch anders aus und man kann mit Rechtsklick auf einen Eintrag ein Aktualisierung mit den aktuellen Einstellungen vornehmen.
zu 2) Ja, das ist leider so: wenn man mit Metadata-Upload (implizit oder explizit) arbeitet, wird das Dateidatum auf das aktuelle Datum geändert, es gibt keinen Parameter in der API um das zu verhindern. Metadata-Upload passiert implizit (also automatisch) bei Videos und wenn man Location Tags aktiviert hat. Falls das Dateidatum wichtig ist für Dich, kannst Du diese Funktionen nicht verwenden.
zu 3) Das Preview ist das in den Fotos selbst gespeicherte Vorschaubild, was z.B. auch Windows als Vorschaubild verwendet. Es wird als nicht durch rechenaufwändige Konvertierungen erzeugt, sondern einfach aus dem Bild extrahiert, Auch hier gilt: die API bietet mir nicht die Möglichkeit das selber mit hochzuladen, deshalb macht es der Indexer-Prozess, ist wie gesagt aber keine rechenintensive Operation.
zu 4) GPS-Tags wie Country, City usw. müssen im Foto vorhanden sein, damit Photo StatLr sie in ein PS Standort-Tag übersetzen kann. Lr macht zwar ein Reverse Geocoding von Fotos mit GPS-Daten, schreibt sie aber nicht in die Foto-Metadaten. Das sieht man daran, das die entsprechenden Felder in Lr zwar vorbelegt sind (schattierte Schrift), wenn man aber reinklickt, verschwinden sie, ziemlich bescheuert das Ganze. Wenn Du Location Tags verwenden willst. empfehle ich Dir das Plugin 'jf Geocoding support' von Jeffrey Friedl. Damit kannst Du relativ komfortabel Fotos mit GPS-Daten reverse-geokodieren, spricht mit den zugehörigen Location Tags versorgen. Erst dann ergibt das Standort-Tag-Feature von Photo StatLr Sinn. Wenn Du den Aufwand nicht treiben willst, kannst Du das Standort-Tag deaktivieren, mit dem Nebeneffekt, dass dann auch kein Metadata-Upload für die Fotos nötig ist, was Auswirkungen auf die Upload-Geschwindigkeit und auf das Dateidatum hat (s.o.)

Viele Grüße und einen guten Rutsch,
Martin

 

[hadi]

Hallo Martin,

Ein frohes und gesundes neues Jahr!
Danke für deine schnelle Antwort.

zu 1) Also hast du nicht die Abo-Variante zum Testen? Ist irgendwie seltsam unter LrC 10 (wohl ein Bug), irgendwie werden Änderungen doch übernommen, aber die Checkbox bleibt ausgegraut.

zu 3) Ok, verstanden.

zu 2 & 4) Da die GPS-Tags (Country, City, etc) ja grundsätzlich sehr einfach zu erstellen sind (Danke für den Tip mit dem Plugin 'jf Geocoding support' von Jeffrey Friedl, funktioniert super), würde ich die schon gerne nutzen, da man dann doch auch sehr gut suchen kann (und zB auf der PhotoSation auch entsprechende Smart-Alben erstellen kann). Da ich aber trotzdem gerne das Aufnahmedatum als Datum auch beim Auflisten in der Shell der DSM (ls -al) möchte, habe ich ein kleines Script geschrieben, das aus der JPG das Aufnahmedatum (bzw. xmp:CreateDate=) rausliest, und das Datum der Datei entsprechend setzt. Hier ist es (kann man sicher schöner machen, aber es funktioniert), trotzdem ohne Gewähr (falls es jemand benutzen will):

#! /bin/sh

typeset -i counter=0;

if [ "$1" = "" ] ; then
    echo "Missing Parameter - Usage: $0 <Path containing JPGs>";
    exit 1;
fi;
if ! [ -d "$1" ]; then
    echo "Directory not existing - Usage: $1 <Path containing JPGs>";
    exit 1;
fi;

for file in $(find $1 -maxdepth 1 -type f -iname "*.JPG");
    do
        file_date=$(grep --binary-files=text "CreateDate=" $file | tr ' ' '\n' | grep --binary-files=text "CreateDate=" | cut -b17-35);
        year=${file_date:0:4};
        month=${file_date:5:2};
        day=${file_date:8:2};
        hour=${file_date:11:2};
        minute=${file_date:14:2};
        second=${file_date:17:2};
        touch -amt $year$month$day$hour$minute.$second $file;
        counter=$counter+1;
        echo $file ": File Date changed to " $year$month$day$hour$minute.$second;      
    done

echo $counter "files changed.";

Aufrufen mit dem Pfad als Parameter, wo die JPGs zu finden sind. Unterverzeichnisse werden nicht durchsucht, sonst werden auch die ganzen @eaDir Verzeichnisse durchsucht. Könnte man noch ergänzen und abfangen, mir reicht es aber so.

Grüße

 

[freddy1962]

Moin,
die Suche hier im threat hat nichts gebracht...
Wie kann ich denn in LR unter Veröffentlichungsdienst PhotoStatLR die dort erstellten Smart-Sammlungen in der Reihenfolge umsortieren? (Hab sie nach Jahren angelegt und die für 2021 hat sich einfach oben rangeheftet während ich eigentlich aufsteigende Reihenfolge haben möchte)
Einfaches Ziehen und Fallenlassen funktioniert bei mir nicht (MacOS Mojave).
Danke und CU
Fred

 

[hadi]

Hallo nochmals,

Ich habe noch eine Frage, hatte bei den bisherigen Versuchen die Bilder immer über Export auf die PhotoStation hochgeladen, und jetzt den Veröffentlichungsmanager getestet. Ist es korrekt, dass ich da Umbenennungen der Dateien nur über die Metadatenplatzhalter vornehmen kann, und keine eigene neue Nummerierung erzeugen kann?
Also Originaldateinamen lauten img_1234.jpg oder ip8_3456.jpg, und ich würde die beim Hochladen gerne umbennen in sowas wie NeuerName_NeueNummer_AlterName.jpg, d.h. dann in urlaub_0001_img_1234.jpg bzw. urlaub_0002_ip8_3456.jpg.
Es wird ja nicht alles hochgeladen, aber die hochgeladenen sollen dann neu und fortlaufend nummeriert sein gemäß der Sortierreihenfolge in der Bibliotheksansicht (beim Exportieren geht das ja).

Die Nummer (bzw. Reihenfolge) muss ja irgendwo vorhanden sein, denn in der Photostation werden die ja wieder richtig sortiert angezeigt (so wie in der Bibliotheksansicht benutzerdefiniert festgelegt).

Danke & Grüße