Posts by Herr Kaiser


    The target platform is not supported!


    Die Huerde hatte ich auch, als ich es mit der git-Version probiert hatte. Die liess sich relativ leicht ueberwinden, in dem man in der CMakeLists.txt drei Zeilen auskommentiert, die die Meldung verursachen. Ich meine, es waere irgendwo um Zeile 112 herum gewesen. Ich weiss es nicht mehr ganz genau, weil ich es derzeit mit der frueheren Darktable-Version 2.0.7 usprobiere, deren Abhaengigkeiten wesentlich leichter zu erfuellen sind, und da enthaelt die CMakeLists.txt gar nicht diesen Platform-Check.



    Hier der Installationsweg, den ich ich probiere
    https://redmine.darktable.org/…iki/Building_darktable_20


    was mir grad noch eingefallen ist: schau doch mal, wo dieser Wert Threads_FOUND gesetzt wird und setze den evtl. mal fest auf 1 oder was immer da erwartet wird.


    Hab zunächst mein Installationsverzeichnis und dann mein gesamtes System (inkl. versteckter Dateien) rekursiv nach einer Datei durchsuchen lassen, die den Text Threads_FOUND enthält. Leider wurde keine entsprechende Datei gefunden.

    Vorweg nochmal herzlichen Dank fuer eure Hilfsbereitschaft. Find ich richtig klasse!


    Leider weiss ich nicht genau, welches Script hier konkret diesen Fehler provoziert. Vielleicht bring die CMakeError.log Licht ins Dunkle. Leider hagelt es dort Warnungen und Fehlern.


    Danke euch beiden! :-)


    Der Installationsversuch der git-Version ist ein Alptraum, da zahlreiche Bibliotheken manuell installiert werden müssten, die lediglich in der Vorgängerversion des Raspbian-Repositorys enthalten sind. Ich habe mich dann an einer etwas älteren Darktable-Version (2.0.4) versucht und siehe da: cmake läuft relativ sanft durch, alle Abhängigkeiten werden erfüllt (das ist ja schonmal ein riesen Schritt), endet aber trotzdem mit einer Fehlermeldung:


    -- Could NOT find Threads (missing: Threads_FOUND)


    Klingt irgendwie ziemlich grundsätzlich, ich finde aber keinen Hinweis, wo es genau klemmt :-(

    Hallo Forum,


    ich habe meinen Raspberry als Desktop-PC-Ersatz eingerichtet. Inzwischen laufen tatsächlich alle relevanten Anwendungen, die auch auf meinem "großen" Desktop installiert sind, bis auf Darktable. Es gab vor zwei Jahren schonmal einen Thread zum Versuch, Darktable zum Laufen zu bringen. Der wurde offensichtlich wegen Aussichtslosigkeit aufgegeben. Allerdings sind jetzt zwei Jahre vergangen, inzwischen gibt es den Raspi 3 und vor allem diesen Beitrag:
    http://www.darktable.org/2016/…ing-on-non-x86-platforms/
    Es scheint also prinzipiell zu gehen. Ich finde nur nirgendwo irgendwelche Installationsbeschreibungen. Ich weiß, dass mit erheblichen Performanceeinschränkungen gegenüber der x64-Version zu rechnen sein wird, möchte es aber trotzdem einmal ausprobieren.
    Hat sich zwischenzeitlich jemand erfolgreich daran versucht oder weiß, wie man vorgehen müsste? Würde mich riesig freuen ...

    Hi und danke, Andreas,
    die Überlegung hatte ich auch schon und hab sie erstmal zu Seite gelegt, da aufgrund der deutlich unterschiedlichen Dateigrößen das Blinken vermutlich unregelmäßig und eher langsam erfolgt (des handelt sich um RAW-Bilddateien, bei der das Kopieren eines Files schon mal 3 bis 10 Sekunden dauert). Mir würde ein regelmäßiges Blinken in einem Herzschlag-Rhytmus besser gefallen. Aber ich glaube, ich probiere deinen Vorschlag mal aus und sehe mir an, wie es mir gefällt.
    Als Alternative bin ich gerade auf das Stichwort "Async-Function" gestoßen, welche offensichtlich ab Python 3.5 im Gepäck ist. Werde mal schauen, ob ich schlau draus werde ...

    Hallo Forum,


    ich habe Folgendes vor: ein Backup-Script soll automatisch Bilddateien einer SD-Karte auf einen USB-Stick kopieren. Der Verlauf der Aktion soll durch eine blinkende RGB-LED angezeigt werden. Nach jeweils 1/6 der übertragenen Daten soll sich die Farbe der blinkenden LED ändern. Mein Problem: das Blinken der LED wird über einen While-Loop realisiert, das Kopieren der Dateien über eine For-Schleife. Loop und Schleife für sich funktionieren, aber wie bringe ich beide zusammen? Wie muss der Programmablauf aussehen? Muss ich hier mit getrennten Threads arbeiten (was ich Anfänger leider noch nicht beherrsche) oder gibt es anderen Möglichkeiten, die Schleife und den Loop "gleichzeitig" zu durchlaufen? (Ihr merkt, so richtig viel Ahnung von all dem habe ich leider noch nicht) ...

    Hi Bernd, danke für die Info! Scheint wirklich keine Seltenheit zu sein, dass sich da 'was beißt. Habe inzwischen einige Beiträge von BT-Lautsprecher-Nutzern gelesen, die ihr Leid klagen und nur unschöne Workarounds gefunden haben, das Problem zu lösen. Mir ist auch nur eingefallen, einen externen WLAN-Dongle anzuschließen, mit dem es keine Probleme mehr gibt. Der funkt auf dem gleichen Kanal wie das Onboard-Modul, so dass eine Änderung des WLAN-Kanals vielleicht doch nicht hilft (ich war aber auch nicht intelligent genug, die Änderung der Kanalzuordnung hinzukriegen). Zu dumm, dass die verbaute Hardware deaktiviert werden muss, um externe Gerätschaften einzusetzen und dadurch noch ein USB-Port blockiert wird. Hoffe, dass vielleicht eine zukünftige Firmware das Problem löst ...

    Hallo Forum,
    habe Bluetooth-Maus und -Tastatur mit dem Raspi gekoppelt und beide funktionieren gut, solange der interne WiFi-Empfänger deaktivert ist. Wenn ich das WLAN anschalte arbeitet die Maus problemlos weiter, die Tastatur ist aber wegen massiver Verzögerung bei der Übernahme der Tastenanschläge quasi nicht benutzbar. Ich verwende das offizielle Netzteil für den Raspberry Pi 3, hoffe also, dass es nicht an mangelnder Stromversorgung liegt. Habt Ihr ähnliche Erfahrungen? Könnte durch Anpassungen irgendwelcher Einstellungen möglicherweise das Problem behoben werden? (Bei mir läuft das aktuelle Raspbian auf dem Pi).

    Hallo Forum,
    ich habe mir nach folgendem Rezept einen Shutdown-Button eingerichtet:
    https://www.youtube.com/watch?v=A08IrJ3ECuA
    Funktioniert richtig gut, solange beim Bootvorgang ein Monitor angeschlossen ist. Im Headless-Modus allerdings fährt der Raspi damit unkontrolliert und eigenmächtig herunter. Habe festgestellt, dass dann der Status des betreffenden Pins (GPIO 3 - SCL) unabhängig von der Betätigung des Buttons scheinbar zufälig schwankt und damit falsche Schalterzustände vorgaukelt. Ich nehme an, dass das Signal im Headless-Betrieb stark störanfällig ist (blutige Anfängervermutung). Könnte das sein - und könnte man dagegen etwas tun?

    Huch ... scheint aber alles gut gegangen zu sein. Da ich keine Low-current-LEDs habe, habe ich den Widerstand auf 1kOhm erhöht. Außerdem habe ich zwischenzeitlich gelesen, dass über raspi-config die serielle Schnittstelle aktiviert werden muss. Das habe ich getan, und jetzt leuchtet die LED während des gesamten Betriebs und erlischt nach dem Shutdown. Das finde ich sogar noch besser als ein Glimmen. Trotzdem frage ich mich, woran es liegen könnte, dass bei mir nichts blinkt und glimmt ...

    So, da bin ich wieder. Habe festgestellt, dass ich mich doch tiefer in die Materie einarbeiten muss. Dafür sind die Stichworte "system.d" und "rc6.d" schon einmal gute Startpunkte. Vielen Dank! Werde mich da einlesen. Zwischenzeitlich finde ich die optische Variante per LED-Anzeige auch nicht uninteressant, daher:


    Andreas: Ich habe das jetzt mal so realisiert: Raspi 3, rote LED (Vf=2.0V, If=50mA), Anode an TXD (=GPIO14?), Kathode an GND, dazwischen ein Vorwiderstand von 100 Ohm. Die LED leuchtet sehr kräftig und durchgängig für einige Sekunden während des Hochfahrens, dann schaltet sie ab. Blinken während des Bootens oder Glimmen nach Shutdown zeigen sich nicht. Muss ich noch etwas Spezielles berücksichtigen, damit der Status wie von dir beschrieben angezeigt wird?


    Danke schonmal - und ich hoffe es ist ok, dass ich diese Zwischenfrage hier und nicht im GPIO-Unterforum stelle.