Immich 3.0

 (github.com/immich-app)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Immich v3.0.0 ist das nächste Major Release nach monatelanger Arbeit und umfasst mobiles nicht-destruktives Bearbeiten, eine Workflow-Vorschau, verbesserte Hintergrund-Backups, Integritätsprüfungen, Vorschauen für Video-Transkodierung in Echtzeit und mehr
  • Dieses Release enthält Breaking changes, viele davon betreffen jedoch Änderungen an Immich-API-Endpunkten und wirken sich daher vor allem auf Drittanbieter-Tools aus, die sich in die Immich API integrieren; die meisten Nutzer können wie bisher aktualisieren
  • Für das Upgrade wird in .env IMMICH_VERSION von v2 auf v3 geändert und anschließend docker compose pull && docker compose up -d ausgeführt; v3.0.0 stellt die Unterstützung für pgvecto.rs ein, daher ist in Umgebungen vor v1.133.0 eine VectorChord-Migration erforderlich
  • Die mobile App übernimmt dasselbe nicht-destruktive Bearbeitungsmodell wie das Web, verbessert Android-Hintergrund-Backups mit einem periodischen Task-Scheduler, und auf iOS laufen Synchronisierung und Upload parallel innerhalb der kurzen verfügbaren Hintergrundzeit
  • Video-Transkodierung in Echtzeit ist weiterhin eine experimentelle Funktion und derzeit nur in der Web-App implementiert; die mobile App befindet sich noch in Arbeit, daher wird das manuelle Löschen bestehender Offline-Transkodierungsdateien nicht empfohlen

Updates und Kompatibilitätsänderungen

  • Immich v3.0.0 wurde als nächste Major-Version veröffentlicht und enthält mehrere Breaking changes
  • Viele dieser Breaking changes sind Updates an API-Endpunkten und betreffen daher vor allem Drittanbieter-Tools, die sich in die Immich API integrieren
  • Die meisten Nutzer können wie bisher aktualisieren
  • Der vollständige Migrationsleitfaden ist in den Release-Hinweisen über einen separaten Link verfügbar
  • v3.0.0 stellt die Unterstützung für pgvecto.rs ein
  • Update-Verfahren:
    • In der Datei .env IMMICH_VERSION=v2 auf IMMICH_VERSION=v3 ändern
    • docker compose pull && docker compose up -d ausführen

Release Candidates und Benachrichtigungskanäle

  • v3.0.0 ist das erste Release von Immich, das Release Candidates verwendet
  • Release Candidates sind getestete, aber noch keine offiziellen Releases, also Prereleases, die dazu dienen, verbleibende Bugs vor dem finalen Release zu finden und zu beheben
  • Wer in Immich Benachrichtigungen zu Release Candidates erhalten möchte, kann unter Admin settings > Version check den Release-Kanal von Stable auf Release candidate umstellen

Mobile Bearbeitung und verbesserte Backups

  • Mobiles nicht-destruktives Bearbeiten ist die Fortsetzung der Bildbearbeitungsfunktionen, die in v2.5.0 zuerst im Web eingeführt wurden
  • Der bisherige mobile Editor nutzte ein separates System, das Fotos nicht direkt änderte, sondern neue Assets erzeugte
  • Der mobile Editor in v3.0.0 bietet dieselben Funktionen wie die Web-Version und ermöglicht Zuschneiden, Drehen und Bildanpassungen, ohne die Originaldatei anzutasten
  • Bearbeitungen sind nicht-destruktiv, können später erneut geändert oder rückgängig gemacht werden, und nach einer Bearbeitung auf dem Mobilgerät kann die Anpassung im Web fortgesetzt werden
  • Einige Funktionen der früheren mobilen Bearbeitungsimplementierung wurden entfernt
    • Ändern von Fotofarben
    • Bearbeitung von Live Photos
    • Bearbeitung lokaler Assets
  • Einige Funktionen sollen in künftigen Releases zurückkehren
  • Android-Hintergrund-Backups arbeiten mithilfe eines periodischen Task-Schedulers zuverlässiger
    • Zuvor war dies auf neu aufgenommene Fotos beschränkt
    • Jetzt kann die gesamte Bibliothek im Hintergrund hochgeladen werden
    • Das passt besser zu Android-Beschränkungen für Hintergrundausführung und berücksichtigt Aufgabenbereinigung sowie Warnungen zu Batterieoptimierung und Benachrichtigungseinstellungen
  • iOS-Hintergrundaktualisierungsjobs führen Synchronisierung und Upload parallel aus, damit Uploads innerhalb der von iOS erlaubten kurzen Zeitspanne starten können

Workflow-Vorschau

  • Workflows sind die erste Vorschaufunktion zur Automatisierung von Bibliotheksverhalten
  • Automatisierungen lassen sich erstellen, indem Trigger, Filter und Aktionen in einem Drag-and-Drop-Builder verbunden werden
  • Zugriff erfolgt im Web unter Utilities > Workflows
  • Es kann ein neuer leerer Workflow erstellt oder durch vorbereitete Vorlagen geblättert werden
  • Der Editor bietet einen Visual editor und einen JSON editor
    • Der Visual editor eignet sich zum Konfigurieren von Workflows
    • Der JSON editor eignet sich zum Teilen oder Übernehmen von Workflow-Inhalten
  • Jeder Workflow besteht aus einem trigger und einer Reihe von steps
    • Der Trigger ist der Einstiegspunkt des Workflows; wenn er ausgelöst wird, werden die Schritte ausgewertet
    • Steps enthalten Filters für Bedingungen und Actions für Effekte
  • Es gibt zwei Freigabeformen: Text und JSON
    • Text eignet sich für das Teilen im Forum oder für Demos
    • JSON eignet sich für das exakte Replizieren von Workflow-Konfigurationen
  • Feedback zu neuen Ideen für Trigger und Aktionen wird in einem separaten Discussion Thread gesammelt

Bibliotheksnavigation und Integritätsprüfung

  • Eine Recently Added-Seite wurde für Web und Mobilgeräte hinzugefügt
    • Damit lässt sich die Bibliothek nach dem Zeitpunkt durchsuchen, zu dem Assets zu Immich hinzugefügt wurden, statt nach dem Aufnahmezeitpunkt
    • So ist beim Durchsehen neu importierter Stapel leichter zu erkennen, was neu hinzugekommen ist
    • Im Web ist die Seite im Tab Explore, mobil im Tab Search zu finden
  • Auf der Wartungsseite wurden integrity reports hinzugefügt
    • Immich scannt Verzeichnisse im Dateisystem und vergleicht sie mit den in der Datenbank gespeicherten Informationen
    • Dateien in Verzeichnissen, die Immich nicht kennt, werden als untracked markiert
    • Gibt es einen Datenbankverweis, aber keine Datei an diesem Ort, wird dies als missing markiert
    • Wenn die Prüfsumme einer Datei auf dem Datenträger von der in Immich gespeicherten Prüfsumme abweicht, wird dies als checksum mismatch markiert
  • Prüfsummenabweichungen entstehen typischerweise durch Dateibeschädigungen, können aber auch das Ergebnis falscher Umbenennungen sein
  • Für Integritätsprüfungsjobs lässt sich einstellen, wann und wie lange sie jede Nacht laufen sollen

Video und Medienwiedergabe

  • Die mobile App erhält eine Slideshow-Funktion, mit der Fotos und Videos wie im Web automatisch auf dem Bildschirm abgespielt werden können
  • HLS und Video-Transkodierung in Echtzeit wurden als Vorschaufunktion hinzugefügt
    • Videos können während der Wiedergabe umgewandelt werden, ohne vorab Offline-Transkodierungen zu erstellen
    • Manuelle und automatische Qualitätsumschaltung wird unterstützt
    • Es kann in den besten Codec transkodiert werden, den der Client unterstützt
    • Wenn Offline-Transkodierung deaktiviert wird, lässt sich der Speicherbedarf verringern
  • Auch noch nicht umgesetzte Punkte werden genannt
    • HDR für kompatible Clients
    • Remuxing statt Transkodierung des Originals, wenn die Bandbreite es erlaubt
  • Echtzeit-Transkodierung ist experimentell und ihr Verhalten kann sich zwischen Versionen ändern
  • Derzeit ist sie nur in der Web-App implementiert; die mobile App wird noch entwickelt
  • Aktiviert wird sie in den Video-Transkodierungseinstellungen
  • Auch wenn Echtzeit-Transkodierung aktiviert wird, hat das keinen direkten Einfluss auf Offline-Transkodierung; um Offline-Transkodierung zu deaktivieren, muss auch die Transcode Policy angepasst werden
  • Assets, die vor v3 importiert wurden, werden erst nach erneutem Ausführen von Metadata Extraction im Aufgaben-Panel neu verarbeitet
  • Der Server muss leistungsfähig genug sein, um Echtzeit-Transkodierung zu verarbeiten; Hardwarebeschleunigung wird empfohlen, ist aber nicht zwingend erforderlich
  • Die Web-App enthält einen neuen benutzerdefinierten Videoplayer, der zum Immich-Design passt
    • Er bietet auf allen Geräten dieselben Bedienelemente und dasselbe Layout
    • Er unterstützt grundlegende Funktionen wie das Ändern der Wiedergabegeschwindigkeit
    • Er kann auch das Problem lösen, dass unter iOS OS-Bedienelemente hinter der Navigationsleiste von Immich verborgen werden

Android, OCR, Teilen und Album-Workflows

  • Unter Android kann Immich wie eine Galerie-/Bildbetrachter-App verwendet werden
    • Wenn in anderen Apps auf ein Foto oder Video getippt und Immich ausgewählt wird, öffnet es sich direkt im Asset Viewer
    • Es werden Optionen zum Teilen von Dateien oder zum Hochladen in die Bibliothek angeboten
    • Die Erkennung von Dateien, die sich bereits in der Bibliothek befinden, soll künftig verbessert werden
  • Im mobilen Asset Viewer gibt es jetzt einen OCR-Umschalter, der erkannten Text in Fotos hervorhebt
    • Text in Bildern kann ausgewählt und kopiert werden
  • In der mobilen App können lokale Fotos direkt in Alben hochgeladen werden
    • Auch über das Asset Bottom Sheet lassen sie sich direkt zu einem Album hinzufügen
    • Das reduziert Reibung in einem Workflow, bei dem zuerst hochgeladen und später organisiert wird
  • Beim Teilen auf Mobilgeräten kann die Bildgröße vor dem Senden gewählt werden
    • So lassen sich Dateien für Messaging-Apps kleiner halten
    • Bei Bedarf kann auch in voller Qualität geteilt werden
    • Das Standardverhalten kann unter App Settings > Preferences geändert werden
    • Durch langes Drücken auf den Teilen-Button lassen sich Optionen direkt auswählen
  • Die Performance beim Navigieren in der Timeline wurde verbessert, wenn in einem Monat viele Assets vorhanden sind, wodurch sich Situationen mit blockierten Browser-Tabs verringern

Wichtige Änderungspakete

  • Zu den Breaking changes gehören die Migration von class-validator zu zod, das Entfernen von Replace Asset, das Entfernen alter Timeline-Sync-Endpunkte, das Ende der Unterstützung für pgvecto.rs sowie Änderungen an der Struktur von Fehlerantworten
  • Zu den Deprecated changes gehört die Deprecation zugunsten des Ersetzens von PUT-Routen durch PATCH
  • Zu den Sicherheitsänderungen gehört eine Anpassung, durch die Profilbilder die Thumbnail-Pipeline durchlaufen
  • Zu den neuen Funktionen gehören mobile Bearbeitung, Android periodic work manager task, benutzerdefinierter Web-Videoplayer, Recently Added Assets Page, Workflows & Plugins, HLS-Echtzeit-Transkodierung, mobiles OCR und Integritätsprüfungsjobs
  • Zu den Bugfixes gehören E-Mail-Normalisierung bei OAuth, Bereinigung von Dateinamen vor dem Hinzufügen zu ZIP-Dateien, Verhinderung der Partner-Sichtbarkeit gesperrter Assets, Behebung unautorisierter Face-Erstellung und die Vermeidung von Out-of-Memory-Problemen bei CLI-Uploads

In der Diskussion bestätigte Einschränkungen und Antworten

  • Für ein Upgrade von v2.0.1 auf v3.0.0 gibt es keine besonderen Sonderanweisungen; laut Antwort genügt es, dem Update-Verfahren in den Release Notes zu folgen
  • Fälle, in denen nach einem mobilen Update keine Alben sichtbar waren, schienen auf einen Migrationsbug auf mobiler Seite zurückzugehen; Ab- und erneutes Anmelden oder ein Server-Update auf v3 können helfen
  • Zum Workflow nach einer Wiederherstellung eines iPhone-Backups, bei dem die auf dem Server befindlichen Fotos erneut lokal auf die mobile App geladen werden sollen: Die mobile App hat noch keine bulk download-Option, nur den Download einzelner Fotos
  • Auf die Frage, ob nach dem Aktivieren der Echtzeit-Transkodierung bestehende transkodierte Videos gelöscht werden können, lautete die Antwort, dass die mobile App Echtzeit-Transkodierung noch nicht unterstützt und die bisherigen transkodierten Videos daher weiterhin benötigt werden; manuelles Löschen wird nicht empfohlen
  • Zur Funktion, HEIC-Fotos spontan in JPG umzuwandeln, wurde geantwortet, dass dies nicht geplant ist und die aktuell erzeugten Vorschaubilder JPEG/WEBP sind, wodurch sie mit allen Browsern und Clients kompatibel bleiben
  • Die Verbesserungen beim Android-Hintergrund-Backup dienen nicht der Lösung von Problemen mit großen Bildern über 100 MB oder Cloudflare-Beschränkungen, sondern sorgen dafür, dass Hintergrundjobs regelmäßiger ausgeführt werden
  • Bei Echtzeit-Transkodierung wählt nicht der Server den Codec, sondern der Client; wenn der Server eine AV1-Variante anbietet, können Clients mit AV1-Decodierung diese verwenden
    • Es ist geplant, eine Einstellung hinzuzufügen, mit der festgelegt werden kann, welche Codecs und Auflösungen der Server ankündigt
  • Verbesserungen beim Casting stehen auf der To-do-Liste; laut Antwort müssen das gesamte Casting und auch die Echtzeit-Transkodierung neu geschrieben bzw. ergänzt werden
  • Ein Nutzer, der nach dem Upgrade den Fehler No vector extension found. Available extensions: vchord, vector gemeldet hatte, schrieb später, dass das Problem gelöst wurde
  • Zur neuen Prüfung auf Prüfsummenabweichungen wurde angemerkt, dass Nutzer, die Bilder in der Vergangenheit außerhalb von Immich bearbeitet und hochgeladen haben, Hunderte von checksum mismatch-Einträgen sehen könnten; eine Funktion zur Neuberechnung von Prüfsummen wäre daher nützlich
  • Im Zusammenhang mit der VectorChord-Migration wurde angemerkt, dass Nutzer vor v1.102 möglicherweise die Opt-in-Änderung bei DB_DATA_LOCATION verpasst haben; ein entsprechender Warnhinweis wäre hilfreich

Unterstützung und Merchandise

  • Zusammen mit dem Release von v3.0.0 wurde auch neues Immich-Merchandise vorgestellt
    • Kinderkleidung
    • Kleidung mit vollfarbig gesticktem Immich-Logo
    • Merchandise-Seite: https://immich.store
  • Das Projekt kann durch den Kauf eines Product Keys oder von Merchandise unterstützt werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Meinungen auf Hacker News

  • Ich unterrichte Studierende in einem kostenlosen Kurs für Softwareentwicklung, und es ist wirklich aufregend, wenn Arbeiten aus den Kursaufgaben in echten Projekten auftauchen.
    Ich bin stolz darauf, dass der zuerst aufgeführte Bugfix der letzte von drei Pull Requests war, die dieser Student während des Kurses in Immich gemergt hat.

  • Da in den Kommentaren viel über Verschlüsselung gesprochen wird, teile ich meine Konfiguration. Ich betreibe seit etwa anderthalb Jahren Immich für Familie und Freunde auf einem Hetzner-Auktionsserver.
    In der Hetzner-Community gibt es eine offizielle Anleitung zur vollständigen Festplattenverschlüsselung: https://community.hetzner.com/tutorials/install-debian-with-...
    Mit Letsencrypt nutze ich kostenloses SSL, und Immich lässt sich problemlos hinter einem Nginx-Proxy verstecken, der SSL übernimmt.
    Mit cron-basierten automatischen Backups, die alle Immich-Daten auf einem lokal verschlüsselten NAS speichern, erhält man ein zuverlässiges Setup, bei dem die Daten sowohl während der Übertragung als auch im Ruhezustand verschlüsselt sind. Bisher gab es exakt 0 Wartungseinsätze.
    Auf IP-Ebene verwerfe ich Traffic außerhalb von drei Regionen, was es noch sicherer macht; außerdem könnte man dem Nginx-Proxy auch eine WAF hinzufügen.
    Ich halte es sogar für sicherer als Google/iCloud, weil der Angriffsvektor „Mitarbeiter des Unternehmens“ deutlich kleiner ist. Es ist auch dokumentiert, dass Google Fotos durchsucht und sogar zu falschen Polizeimeldungen bereit ist: https://www.eff.org/deeplinks/2022/08/googles-scans-private-...
    Natürlich könnte ein Hetzner-Mitarbeiter theoretisch physischen Zugriff auf den Server nehmen und Verschlüsselungsschlüssel aus dem RAM extrahieren oder mit einem gefälschten SSH-Server Schlüssel stehlen, aber das ist ein deutlich komplexerer und bislang nicht dokumentierter Angriff, bei dem außerdem das Risiko besteht, entdeckt zu werden.

    • Die beschriebene Konfiguration ist keine Ende-zu-Ende-Verschlüsselung. Ende-zu-Ende-Verschlüsselung bedeutet Verschlüsselung zwischen den Clients, sodass der Server nur verschlüsselte Bits verarbeiten sollte.
      Diese Konfiguration bietet Verschlüsselung während der Übertragung und Verschlüsselung im Ruhezustand. Für große Cloud-Anbieter ist Verschlüsselung im Ruhezustand möglicherweise vergleichsweise weniger wichtig, weil sie den Lebenszyklus von Datenträgern wahrscheinlich besser verwalten als die meisten Unternehmen oder Privatpersonen.
      Die Wahrscheinlichkeit ist gering, dass jemand ein Rechenzentrum physisch ausräumt oder an eine wiederaufbereitete Festplatte gelangt, die nicht ordnungsgemäß verarbeitet oder gelöscht wurde.
      Man kann auch schwer behaupten, dass es unbedingt sicherer ist als ein Managed Provider. Wahrscheinlich ist man kein Security Engineer und hat auch deutlich weniger Ressourcen, um den Server zu schützen.
      Es verhindert zwar, dass Google/iCloud die Daten abgreifen, bedeutet aber nicht, dass Hetzner keinen Zugriff auf die Daten hat. Hetzner kontrolliert den übergeordneten Hypervisor und die Control Plane, die den Server bzw. die VM verwalten, daher weiß man nicht, welche Funktionen dort implementiert sind.
      Das meiste, was Nachrichtendienste tun können, ist weder geleakt noch öffentlich dokumentiert.
    • Das ist keine Ende-zu-Ende-Verschlüsselung. Sobald die Disk auf dem Host gemountet ist, ist sie entschlüsselt und nutzbar; es gibt also keinen Mechanismus, der verhindert, dass du oder Hetzner auf die Daten deiner Familie zugreifen.
      Bei echter Ende-zu-Ende-Verschlüsselung müssten alle Daten auf der Disk durch die von der Familie genutzten Clients verschlüsselt werden, und beim Durchsuchen des Disk-Volumes dürfte nur Ciphertext sichtbar sein.
    • Für Fotogalerien halte ich Ende-zu-Ende-Verschlüsselung für unverzichtbar. So schützt man sich vor Server-Fehlkonfigurationen, künftigen Schwachstellen und ungepatchter Software.
    • Mich würde interessieren, wie viel Speicherplatz du bei Hetzner nutzt und wie viel du dafür bezahlst.

  • Wirklich großartige Software und auf Augenhöhe mit Google Photos. Seit ich mit meinem Homelab angefangen habe, nutze ich es seit einigen Monaten hinter Tailscale, und es gab keinerlei Probleme.
    Tatsächlich war der Auslöser für meinen Einstieg ins Self-Hosting, dass ich nach Erreichen des 100-GB-Speicherlimits von Google Photos zu Immich gewechselt bin, und der Prozess hat wirklich Spaß gemacht.
    Es ist kaum zu glauben, dass ein Self-Hosting-Produkt mit diesem Reifegrad kostenlos ist. Aus demselben Grund auch großen Applaus für HomeAssistant, PiHole, paperless-ngx, Dawarich und unzählige weitere Projekte.
    Glückwunsch und Dank an das Team, das mir geholfen hat, meine persönlichen Erinnerungen zu organisieren.

    • Wenn dir das Projekt gefällt, wäre es gut, eine Lizenz zu kaufen. Es ist kostenlos, aber mit einem sehr kleinen Teil des gesparten Geldes kann man eine Lizenz kaufen.
    • Ich finde, es ist inzwischen besser als Google Photos. Das Team ist wirklich hervorragend, und es ist erstaunlich, dass die App, die ich für die beste allgemeine Foto-App halte, Open Source ist.

  • Es gibt hier viele Kommentare dazu, dass es keine Ende-zu-Ende-Verschlüsselung gibt, aber ehrlich gesagt verstehe ich nicht, warum sie nötig sein soll.
    Nehmen wir an, ein Dieb bricht ein und stiehlt das Homelab. Weil es keine Ende-zu-Ende-Verschlüsselung gibt, kann er Fotos der verstorbenen Großmutter ansehen – was für eine Katastrophe!
    Das wahrscheinlichere Szenario ist doch eher, dass mit dem Smartphone etwas passiert. Ohne Ende-zu-Ende-Verschlüsselung verliert man beim Verlust des Schlüssels nicht auch noch die letzten Erinnerungen an die Großmutter, sondern kopiert einfach die .jpg-Dateien auf ein neues Gerät.

    • Ermöglicht es, eine Instanz für Familie oder Freunde zu hosten.
      Allerdings machen mir die Abstriche bei der Zugänglichkeit, die Ende-zu-Ende-Verschlüsselung für normale Nutzer mit sich bringt, Sorgen. Wenn man in diesem Fall den Schlüssel oder das Passwort verliert oder vergisst, verliert man eine ganze Sammlung sehr wichtiger Fotos, und das ist ziemlich fatal.
      Google Photos oder iPhotos geben den Leuten das Gefühl, dass ihre Fotos sicher sind.
      Außerdem wird es einfacher, eine Cloud-Instanz für Immich zu hosten, ohne das Dateisystem eines entfernten Servers/VPS zu verschlüsseln. Gerade wenn man Server bei kleinen Anbietern mietet, ist man immer vorsichtig, wie sehr man deren Zugriffskontrolle für Mitarbeitende vertrauen kann.
      Ich weiß, dass bei physischem Zugriff ein gewisses Maß an Vertrauen unvermeidlich ist, aber auch der Umgang mit Datenträgern bei der Wartung ist wichtig.
    • Der Kern von Ende-zu-Ende-Verschlüsselung liegt meiner Ansicht nach darin, dass selbst bei Hosting durch einen Cloud-Anbieter dieser Anbieter die Daten nicht sehen kann. Ähnlich wie Proton Drive behauptet, nicht zu wissen, welche Dateien man dort hat.
      Damit müssten Funktionen wie semantische Suche, Gesichtserkennung, Video-Transcoding und Thumbnail-Erzeugung auf den Client verlagert werden.
      Immich setzt voraus, dass man dem Server den Zugriff auf die Fotos anvertraut. Beim Self-Hosting ist die Architektur immer so.
      Da die meisten Nutzer Google und Apple ebenfalls dieses Vertrauen geben, halte ich das für vernünftig.
    • Man kann nicht einfach sagen, dass alle Fotos unempfindlich seien.
      Mit einer echten Ende-zu-Ende-verschlüsselten Architektur ließen sich Cloud-Speicher, Managed Hosting und Offsite-Backups wohl flexibler nutzen.
    • Bei Immich halte ich die Anwendungsschicht nicht für die richtige Ebene für Verschlüsselung. Ich verschlüssele einfach die gesamte Server-Festplatte.
      Beim Self-Hosting muss man nicht verhindern, dass der Betreiber auf Dateien zugreifen kann.
    • Stimme zu. Früher bewahrte man Fotoalben im Schrank auf; wenn das Haus abbrannte, verbrannten sie, wenn der Boiler kaputtging, wurden sie nass, und sie konnten sogar gestohlen werden.
      Heute kann man sie digital aufbewahren und extern sichern. Das ist die Veränderung, die Immich braucht, und das reicht.
      Wenn alles vollständig verschlüsselt ist, lädt man sich eher noch mehr Probleme ein.

  • Beim Wechsel von iOS zu GrapheneOS habe ich beschlossen, meine Fotos selbst zu hosten, und mir auch Immich angesehen, mich wegen der Verschlüsselung aber für Ente entschieden.
    Ente Photos ist sehr ausgereift und qualitativ mit Apple Photos vergleichbar.
    Mir gefällt, dass sie nicht wie viele Ende-zu-Ende-Verschlüsselungsprojekte nur den Client offenlegen, sondern auch den Server veröffentlichen und Self-Hosting möglich halten.
    Außerdem kann man Alben so teilen, dass jeder ohne Account dazu beitragen kann, und es gibt eine Funktion, mit der man beim Weitergeben des Smartphones nur ausgewählte Fotos sichtbar macht.

    • Der Aussage „Ente Photos ist sehr ausgereift und qualitativ mit Apple Photos vergleichbar“ kann ich schwer zustimmen.
      Beim Self-Hosting schafft es nicht einmal, Fotos zuverlässig hochzuladen. Ich hatte Phasen, in denen tagelang nichts hochgeladen wurde, und weil es keine Diagnoseinformationen gab, musste ich selbst bauen und debuggen.
      Ich ließ die App im Vordergrund laufen, steckte das Gerät stundenlang ans Ladegerät und deaktivierte sowohl Video-Uploads als auch Machine-Learning-Funktionen, damit sie sich nur auf Fotos konzentriert – trotzdem passierte es.
      Serverseitig ist alles in Ordnung, und Web-Uploads funktionieren problemlos, nur die App nicht. Die Ursache habe ich noch nicht gefunden.
    • Für alle, die es interessiert: „Ente Photos ist ein kostenpflichtiger Dienst, bietet aber 10 GB kostenlosen Speicher. Man kann dieses Repository klonen und selbst hosten.“
      Beide Varianten sind also möglich.
      https://github.com/ente/ente
    • Ente Auth ist ebenfalls großartig. Es funktioniert nämlich auf jedem Gerät, einschließlich genau des Geräts, auf das man zugreifen will.
      Vielleicht untergräbt das den Zweck der Zwei-Faktor-Authentifizierung, aber manchmal ist mir das ziemlich egal.
    • Ich habe angefangen, Ente zu nutzen, weil ich Upload-Links für Fotos pro Event erstellen wollte. Wenn ich Freunden sage: „Wenn ihr heute Abend Fotos oder Videos macht, ladet sie bitte über diese URL hoch“, funktioniert es einfach.
      Es braucht keine App, ist sehr simpel und sehr günstig. Danach habe ich auch den Foto-Backup-/Archivdienst genutzt.
      Weil der Dienst genau das ist, was er nach außen zu sein scheint, bin ich Fan geworden.

  • Immich ist eine viel zu naheliegende Wahl, um Apple Photos oder Google Photos zu ersetzen. Zusammen mit einem VPN wie Tailscale kann man es fast direkt austauschen.

    • Man sollte beachten, dass eine Migration von Immich zurück zu iCloud/Google nicht in den Bereich fällt, um den sich Immich kümmert. Es gibt nirgends „alles herunterladen“, und der beste Weg ist, auf den Server zu gehen und die Originaldateien zu holen.
      https://github.com/immich-app/immich/discussions/14365
    • Ich frage mich, ob es Nebenwirkungen hat, Immich öffentlich erreichbar zu machen. Ich glaube, das Risiko wird oft überschätzt.
      Regelmäßig aktualisieren, einfache Regeln befolgen und etwas wie CrowdSec einrichten – das reicht.
      Ich verstehe, dass Tools wie Tailscale einfacher sind, aber heutzutage scheint es eine Tendenz zu geben, andere Optionen gar nicht mehr in Betracht zu ziehen.
    • Ich nutze photoprism und frage mich, ob ich wechseln sollte.
    • Schade, dass verschachtelte Alben oder Alben innerhalb von Ordnern nicht unterstützt werden; damit ließe sich auch Lightroom Cloud leicht ersetzen.
      Meine Fotos sind etwa nach events -> year/month - holiday -> (album_1, ...), home town -> year -> (album_1, ...) organisiert.
      Fotos können in mehreren Alben sein, es gibt auch bearbeitete Versionen, und Auswahl-/Ablehnungsstatus müssen ebenfalls nachverfolgt und gefiltert werden.
      Der einzige Grund, warum ich noch nicht zu Immich gewechselt bin, ist, dass es mir schwerfällt, meine Art der Fotoorganisation sauber auf Immichs Modell abzubilden. Meine bisherigen Versuche waren umständlich zu handhaben.
    • Ich frage mich, ob es Nebenwirkungen hat, das Smartphone den ganzen Tag mit dem Tailscale VPN verbunden zu lassen.

  • Mich stört noch mehr als die fehlende Ende-zu-Ende-Verschlüsselung, dass der Import aus anderen Diensten wie Google Photos oder iCloud nicht einfacher gemacht wurde; das sollte meiner Meinung nach Priorität haben
    Immich ist auf das Projekt immich-go angewiesen, das voller Bugs ist und praktisch verwaist wirkt
    Die eigene iOS-App kann zwar auch zur Synchronisierung der iCloud-Galerie genutzt werden, scheitert aber wegen eines seit etwa zwei Jahren offenen Bugs am Upload von Live-Motion-Fotos
    Von den Fotos, die ich nach Immich exportiert habe, sind etwa 9000 kaputte oder nur halb importierte Live Photos, und ich habe keine Zeit, das zu reparieren
    Ich kann nicht verstehen, dass das keine Priorität hat. Das ist doch die Funktion, die am gründlichsten A/B-getestet werden müsste
    Wenn ich nicht darauf vertrauen kann, dass meine importierten Erinnerungen nicht beschädigt wurden, sehe ich nicht, welchen Sinn OCR haben soll

    • Bei Open Source konzentrieren sich freiwillige Entwickler oft auf Dinge, die ihnen Spaß machen oder ihre eigenen Probleme lösen
      Sich mit den halb kaputten Exporten von Google Photos herumzuschlagen, klingt für niemanden besonders spaßig, und wenn man den Importschmerz einmal hinter sich hat, verschwindet auch der Juckreiz, den man noch kratzen müsste
    • Das Anspruchsdenken, das hier durchscheint, ist erstaunlich
    • In einer ähnlichen Situation habe ich letzte Woche 12.000 Fotos/Videos per Google Takeout zu Immich migriert
      Ich habe Immich mit Ceph als Backend eingerichtet und mit immich-go alle Metadaten und sogar die Alben vollständig übertragen
      Ich musste die Parallelisierungsoptionen etwas anpassen, aber abgesehen davon war es sehr einfach
    • Liegt das nicht daran, dass solche Dienste geschlossene Blackboxes sind und außer über ziemlich umständliche Wege keinen echten Zugriff erlauben?

  • Es gibt vieles, in dessen Einrichtung man enorm viel Zeit steckt und das man einmal nutzt und dann nie wieder, und vieles, das leicht einzurichten ist und jeden Tag ein bisschen Nutzen bringt
    Immich hat lange zum Einrichten gebraucht und ich nutze es nur sehr selten, aber jedes Mal, wenn ich es einmal im Jahr brauche, denke ich mir, wie gut es war, es installiert zu haben

    • Bei mir hat die Einrichtung nicht besonders lange gedauert, und ich habe wegen gelegentlich brechender Änderungen etwas Zeit mit manuellen Schritten bei Upgrades verbracht, aber das kam nicht oft vor
      Ich nutze es jede Woche, und es funktioniert einfach gut, also ist es großartig
    • Ich wünschte, meine Erfahrung wäre auch so gewesen. Ich habe es in einem Proxmox-LXC betrieben, aber nach zwei Monaten Aufräumen kam es zu Datenkorruption, und ich hatte nicht die Energie, das bis zum Ende zu debuggen
      Wenn ich mich richtig erinnere, könnte es mit der Migration auf eine große Version zusammengehangen haben. Danach war ich von diesem Stack ziemlich abgekühlt
      Upgrades waren nicht so unkompliziert, wie ich es mir gewünscht hätte, und ich vermute, dass es heute nicht viel anders ist
      Ich will einfach nur Ordner außerhalb eines dummen Library-Systems organisieren, und damals passte Immich auch zu diesem Ansatz nicht besonders gut

  • Ich frage mich, ob die iOS-Fotosynchronisierung besser geworden ist. Ich habe 20.000 Fotos auf dem Handy, und beim letzten Versuch wurde der Telefonspeicher mit Originalen vollgeschrieben; selbst nachdem das Handy mehrere Tage im selben lokalen Netzwerk entsperrt war und die Immich-App im Vordergrund lief, wurde es nicht fertig
    Ich weiß, dass daran gearbeitet wird, aber ich habe es nicht weiter verfolgt. Ich würde gern wissen, ob es inzwischen besser funktioniert und einen neuen Versuch wert ist

    • In den Release Notes steht Folgendes
      „Unter iOS führen Background-Refresh-Aufgaben Synchronisierung und Upload jetzt parallel aus, sodass Uploads innerhalb des kurzen Zeitfensters, das iOS erlaubt, tatsächlich gestartet werden“
      Ich weiß allerdings nicht, ob das dieses Problem behebt
    • Ich habe im Februar rund 9000 Bilder vom Handy synchronisiert, und das lief ziemlich gut. Es war nach etwa 10 Stunden fertig
      Ich erinnere mich nicht, ob die Originale heruntergeladen und danach automatisch gelöscht wurden, aber der gesamte Ablauf fühlte sich reibungslos an
    • Uploads großer Dateien können nicht fortgesetzt werden. Wenn man Videos mit ordentlicher Bitrate und Auflösung hat, muss die komplette Datei in einer Sitzung hochgeladen werden können
      iOS macht das mit Hintergrund-Uploads nicht einfach. Ich habe die App über Nacht offen gelassen und so alles hochgeladen
    • Das ist wahrscheinlich eher ein iOS-Problem als ein Immich-Problem. Apple freut sich nicht über Apps, die es leichter machen, iCloud zu verlassen

  • Ich frage mich, ob „Assets in der Mobile-App direkt in ein Album hochladen“ dieses Problem behebt: https://github.com/immich-app/immich/discussions/12748
    Für mich ist das ein ziemlich großes Problem, weil mehrere Geräte und mehrere Personen Katzenfotos in einem Album sammeln wollen
    Derzeit muss ich es etwa so aufbauen: Per Syncthing werden Fotos auf den Homelab-Server, auf dem Immich läuft, nach /mnt/Syncthing/a1/cats/, /mnt/Syncthing/a2/cats/, /mnt/Syncthing/b/cats/ synchronisiert
    Ein cron-Job kopiert die Fotos per Hardlink in den Ordner /mnt/immich/ext-lib/cats/, der als schreibgeschütztes externes Library-Volume gemountet ist
    Ein weiterer cron-Job führt das Skript https://github.com/Salvoxia/immich-folder-album-creator aus, das aus der Ordnerstruktur der externen Library automatisch Alben erstellt
    Schließlich läuft ein cron-Job, der Fotos, die älter als ein Jahr sind, aus dem Syncthing-Ordner aufräumt, um Speicherplatz auf den Handys freizugeben. Insgesamt sind es etwa 1 TB, also gibt es durchaus Probleme
    Trotzdem Glückwunsch zum 3.0-Release. Ein bisschen schade ist es allerdings, weil ich dieses Programm erst vor einem Monat entdeckt und meine Self-Hosting-Konfiguration erst vor einer Woche stabil bekommen habe