Warum unterscheidet sich die Ausgabe von Immich zwischen nativen Clients und Browser-Clients?

Die Ausgabe von Immich kann unterschiedlich ausfallen, weil native Clients und Browser-Clients dieselbe Serverantwort durch unterschiedliche Anfragen, Caches, Decoder und Rendering-Pipelines verarbeiten.

Ein Foto kann in einem Desktop-Browser sofort erscheinen, in einer Smartphone-App jedoch im selben Konto langsam laden, anders zugeschnitten sein oder gar nicht angezeigt werden. Der Server ist nur eine von mehreren Stufen; das Netzwerkverhalten des Clients, gespeicherte Zustände, Plattformberechtigungen und Medienfunktionen bestimmen das letztlich sichtbare Ergebnis.

Die Serverantwort ist nicht die endgültige Darstellung

Immich kann für zwei Clients dieselbe Asset-ID und dasselbe Derivat zurückgeben, während die Clients es unterschiedlich darstellen. Jeder Client muss Anfragen planen, Bytes empfangen, Medien decodieren, die Ausrichtung oder das Layout anwenden und die Benutzeroberfläche rendern. Eine Verzögerung oder ein visueller Unterschied, der erst nach der Antwort entsteht, bedeutet nicht zwangsläufig, dass der Datenbankinhalt unterschiedlich ist.

Der Immich-Datenpfad-Artikel von ZimaSpace trennt die Datenbankauswahl von der Medienantwort und dem für den Client sichtbaren Abschluss. Dieses Modell verhindert einen häufigen Diagnosefehler: Jeden langsamen oder inkonsistenten Bildschirm als Beleg dafür zu betrachten, dass der Server eine andere Antwort erzeugt hat.

Erfassen Sie nach Möglichkeit zwei Zeitpunkte: wann die API-Antwort abgeschlossen ist und wann das Medium sichtbar nutzbar wird. Stimmen die Antwortzeiten überein, weichen aber die Anzeigezeiten voneinander ab, sollten Sie Decoder, Rendering, lokalen Speicher und den Plattformzustand untersuchen. Unterscheiden sich die Antworten, sollten Sie bei Anfragen, dem Kontobereich oder der Serververarbeitung ansetzen.

Native und Browser-Clients erzeugen unterschiedliche Anfrageprofile

Eine native App kann Timeline-Elemente vorab laden, im Hintergrund Wiederholungsversuche durchführen, Uploads synchronisieren oder Anfragen anders bündeln als ein Browser-Tab. Der Browser hat eigene Verbindungsbeschränkungen, Cache-Regeln, Service-Worker und einen eigenen Lebenszyklus für Seiten. Identische Scrollbewegungen müssen daher nicht identischen Datenverkehr erzeugen.

Ein Community-Fall berichtet, dass die Browseroberfläche erreichbar ist, während die mobile Anwendung den Serverendpunkt ablehnt. Die konkrete Konfiguration ist kein allgemeiner Beleg für jeden Client, zeigt aber, dass die Auslieferung einer Webseite und die API-Validierung eines nativen Clients unterschiedlichen Erwartungen an Anfragen und URLs folgen können.

Erfassen Sie für dasselbe Konto, Album und denselben Netzwerkpfad einen kurzen Anfrage-Trace. Vergleichen Sie Endpunkt-URLs, Statuscodes, die Parallelität von Anfragen, die übertragenen Größen der Derivate und die Abstände zwischen Wiederholungsversuchen. Ein Datenverkehrsschub, der nur in einem Client sichtbar ist, erklärt den unterschiedlichen Druck, ohne dass das gespeicherte Asset in Immich geändert worden sein muss.

Caches und Mediendecoder verändern das scheinbare Ergebnis

Browser und native Anwendungen speichern unterschiedliche Vorschaubilder, App-Ressourcen, Anmeldedaten und decodierte Medien. Außerdem können sie unterschiedliche Hardware-Decodierungspfade oder Derivat-Formate wählen. Ein Client verwendet möglicherweise ein bereits geladenes Vorschaubild wieder, während ein anderer es erneut herunterlädt oder decodiert. Dadurch kann der Server inkonsistent erscheinen, obwohl sich der Client-Zustand unterscheidet.

Eine Community-Diskussion über einen alternativen nativen Android-Client argumentiert, dass Entscheidungen bei der Client-Implementierung die Reaktionsfähigkeit und Benutzererfahrung beeinflussen können. Dies ist kein kontrollierter Benchmark, unterstützt aber die architektonische Tatsache, dass getrennte Frontends nicht denselben Ausführungspfad offenlegen.

Löschen Sie nur den Cache des zu testenden Clients, lassen Sie den Serverzustand unverändert und wiederholen Sie den Test mit einem bekannten Asset. Vergleichen Sie anschließend eine unmittelbare Wiederholung ohne erneutes Löschen. Verringert sich der Unterschied nach dem Aufwärmen, ist die Wiederverwendung durch den Client relevant. Fällt ein Format immer aus, untersuchen Sie Codec-Unterstützung, Derivatauswahl und Hardware-Decodierung statt den Speicherort in der Datenbank.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Führen Sie einen Vergleichstest mit zwei Clients durch

Wählen Sie ein Konto, ein bekanntes Album, ein Bild und ein Video. Verwenden Sie für beide Clients dasselbe Netzwerk und notieren Sie Serverversion, Clientversion, URL und Cache-Zustand. Testen Sie Anmeldung, Timeline-Antwort, Öffnen des vollständigen Bildes, Start des Videos und eine Suche in derselben Reihenfolge.

Ein SailfishOS-Community-Projekt, das einen nativen Immich-Client diskutiert, macht deutlich, dass eine separate Client-Implementierung eigene Entscheidungen zur Plattformintegration und Benutzererfahrung treffen muss. Das unterstreicht, warum die Client-Identität eine echte Variable ist, selbst wenn jede Implementierung mit demselben Backend kommuniziert.

Markieren Sie die erste Abweichung als Anfrage, Antwort, Übertragung, Decodierung, Rendering oder Berechtigung. Ändern Sie nur diese Ebene: URL, Cache-Zustand, Medienformat, Client-Berechtigung oder Anwendungsversion. Die Erklärung gilt erst dann als bestätigt, wenn die kontrollierte Änderung den Unterschied beseitigt, ohne Serverdatensätze oder Besitzrechte der Benutzer zu verändern.