Ich frage mich gerade, was bei Immich der Unterschied zwischen /import und /libraries ist.

Standardmäßig gabs früher /import vorkonfiguriert, jetzt ist es /libraries.

Verhalten diese sich unterschiedlich?
Ich kenn es z.B. von Paperless, dass die import ordner ("Consume") nach dem import leer geräumt werden.

Gibt es bei Immich auch so eine Funktion?
Fänd ich ja prakitsch, wenn quasi alles hochgeladene "verarbeitet" wird, aber die Datein in "libraries" nur stumpf angezeigt werden.

So hat man eine klare Trennung zwischen alten Daten, die nicht durch Immich durchgelaufen sind und neuen Daten, die ausschließlich in Immich hochgeladen wurden.

Ich denke hier an Bilder, die man z.B. per Mail bekommen hat, die man aber nicht händisch in seine alte Sammlung einpflegen will und sie stattdessen durch Immich jagt und sie dann dort im /photos dauerhaft abgelegt werden. der Import kann dann wieder leer geräumt werden

 

4 hours ago, cottec said:

jetzt ist es /libraries.

Hier würde ich die immich Doku zu Rate ziehen.

hab mal kurz reingeschaut, scheint optimal zu sein: 

 

External libraries to track assets stored outside of Immich

2 hours ago, cz13 said:

Hier würde ich die immich Doku zu Rate ziehen.

hab mal kurz reingeschaut, scheint optimal zu sein: 

 

External libraries to track assets stored outside of Immich

Die lassen sich in der Doku leider nicht über die verschiedenen Namen aus.

Das wird nur noch unter dem Kapitel external libraries behandelt und da kannst du auch selbst komplett frei den pfad im container angeben, über den eine externe library gescannt werden soll. demnach wäre es ab jetzt egal, wie die ordner heißen.

Hätte ja sein können, dass noch andere Funktionen speziell mit /import möglich sind.
Egal, dann kein Automatismus a la Paperless, dann lad ich einfach sowas per Hand hoch über das WebUI, wenn der (vermutlich seltene) Fall mal auftritt...



Noch was anderes...

Speicherort von /photos....
Wenn man Immich mit den diversen verfügbaren Youtube Anleitungen aufsetzt, dann hauen die alle den /photos Ordner in einen eigenen Share.

Aber ich frage mich gerade, wozu?!

Die Fotos werden da entweder "chaotisch" abgelegt in diesen kryptischen Ordnern (Hex Numerierung?) oder man aktiviert die Ordnerstruktur.

 

Aber ist das wirklich ein usecase, dass man da über den Share drauf zu greifen muss?

Eigentlich hat man doch dafür eben das WebUi und die Smartphone Apps...

 

Oder ist das genau der Angriffspunkt für Bildbearbeitungssoftware, dass ich da komfortabel auf die Bilder zugreifen kann?

Da wären wir dann aber wieder beim Stichwort Sicherheit --> Schreibender Zugriff vom beispielsweise PC aus.

 

 

Also die Frage konkret: Wenn ich nicht außerhalb von Immich auf die Fotos zugreifen muss, dann hau ich die einfach in Appdata/Immich/Photos und habe Bilder, die über Immich App oder händischen Upload reingekommen sind sauber dort verstaut?

 

Oder machts dann eher Sinn EINEN Order "Fotos" im Share zu erstellen, dort dann zwei Unterordner einer für "alte Bilder vor Immich" und einer für Immich /photos?

 

 

Ich weiß, 5 User 8 Meinungen, aber interessiert mich wie ihr das handhabt, ich bin noch frisch 😆

@cottec

Ich selbst nutze Immich nicht.

 

Aber:

Ein extra Share für Fotos zeigt im Idealfall auf das Array. Für sehr große Sammlung interessant.

 

Wenn Du die Fotos in appdata beläßt, liegen sie halt ständig im Cache.

Bei den meisten Usern ist dieser vom Speicherplatz deutlich kleiner als das Array.

 

Davon ausgehend, das appdata so konfiguriert ist, das es halt auf dem Cache bleibt und nicht vom Mover ins Array verschoben wird.

Was die empfohlene Einstellung ist.

Edited January 9, 20251 yr by saber1

9 minutes ago, saber1 said:

Davon ausgehend, das appdata so konfiguriert ist, das es halt auf dem Cache bleibt und nicht vom Mover ins Array verschoben wird.

Was die empfohlene Einstellung ist.

Ich hätte da jetzt Cache <-- Array behalten, wie es standardmäßig ist. Das erlaubt dann ja, dass bei vollem Cache eben ein Teil ausgelagert wird und das könnten dann ja genau alte Fotos aus dem Immich/photos sein, auf die länger nicht zugegriffen wurde.

 

Ich will ja Zugriff auf neue Fotos auf dem SSD Cache, damit dafür die Festplatten nicht geweckt werden. Dies sind ja Fotos, die mit hoher Wahrscheinlichkeit nochmal gelesen / geschrieben werden, wenn man sie taggt oder teilt oder "bildbearbeitet".

Mein alter Fotos Ordner liegt auf dem Array und das wird dann nur geweckt, wenn ich wirklich mal was altes Suche und auch öffne (Thumbnails sollten ja trotzdem im Cache liegen und die Platte nicht wecken)

 

Meine bisherige Fotosammlung habe ich jetzt quasi komplett auf simple Ordner mit Jahreszahlen umgebaut.

Ich könnte ja nun einfach hingehen und händisch jedes Jahr das alte Jahr oder meinentwegen das vorletzte Jahr von Immich/photos auf Array/Fotos schieben.

Immich sieht die Bilder ja trotzdem über die external libraries und ich hab meinen Cache damit nicht "zugemüllt"

Edited January 9, 20251 yr by cottec

Ja, halt

31 minutes ago, cottec said:

5 User 8 Meinungen

 

Du wolltest den Grund für den extra Share wissen. 😉

 

kannst du meine Überlegungen denn nachvollziehen?

Ich finde das gerade mit dem händischen Verschieben ganz gut glaube ich.

Dann bin ich auch nicht so ganz mit dem Daten der Immich Struktur "ausgeliefert" , wenn ich mal was anderes benutzen will und hab alles bis auf 1 Jahr sowieso in meinem gewohnten Foto Archiv.

 

Den schreibenden Zugriff auf den Immich/photos Share werde ich ja eh nicht los, wenn ich die Bilder von Windows aus bearbeiten will.

Den werde ich wohl auch auf  dem Archiv lassen, ich wollte das gerne durchtaggen, wenns mir mal ganz langweilig werden sollte

Edited January 9, 20251 yr by cottec

32 minutes ago, cottec said:

kannst du meine Überlegungen denn nachvollziehen?

Nicht wirklich.

"Nutzdaten" für Docker würde ich nie in "appdata" belassen.

 

Wenn es denn unbedingt

45 minutes ago, cottec said:

Cache <-- Array

sein soll, würde ich ein Share anlegen, der diese Voraussetzungen erfüllt.

Aber eben außerhalb "appdata".

9 minutes ago, saber1 said:

"Nutzdaten" für Docker würde ich nie in "appdata" belassen.

Okay, sollte ich dann auch mal überdenken. Dachte das passt für mich, wenn ich die AppData sowieso täglich inkrementell vom Cache aufs Array sicher.

Aber klar, ist natürlich schöner wenn man auf einen Blick alle Daten sieht und nicht wissen muss, wo sie sich verstecken (Stichwort Windows AppData, und dann noch 3 Stück davon + mehrere User, in denen mittlerweile so viele wichtige Dateien von Software liegen, ohne die man echt aufgeschmissen ist, wenn man mal ein System neu aufsetzt)

 

 

Das kuriose ist ja, dass alle Paperless Anleitungen den Datenkram in appdata belassen und das mit keinem Wort erwähnt wird.

Denken da nur wenige drüber nach oder hab ich was verpasst?

 

Ich hätte ja gedacht, wenn man sich schon nen eigenen Server ans Bein bindet und sein Leben digitalisiert, dass man dann automatisch das Tag "backup-nerd" setzt. Sonst läuft doch irgendwas falsch, wenn man sich da keine Gedanken drum macht...

 

Edited January 9, 20251 yr by cottec

ich hatte gerade noch ein nettes Problem:

Alles mit den external libraries richtig eingestellt, aber er hat kein einziges Bild gefunden.
Weder auf Hauptebene, noch in Unterordnern.
 

In einem Import Ordner war ein .luckybackup-log Ordner oder so ähnlich.

Das war durch den Punkt vorne natürlich der erste Ordner in der Liste.

Hier hatte user:others keine Leserechte und Immich hat sofort den Scan abgebrochen, anstatt den Ordner zu überspringen.
MMn ein Bug, aber ob das gelöst wird, keine Ahnung.

Muss man aber wissen, wenn man sich wundert, warum er null komma gar nix findet

Edited January 22, 20251 yr by cottec