Dlaczego Immich działa inaczej w natywnych klientach i przeglądarce?
Wynik Immich może się różnić, ponieważ klienci natywny i przeglądarkowy przetwarzają tę samą odpowiedź serwera za pomocą różnych żądań, pamięci podręcznych, dekoderów i potoków renderowania.
Zdjęcie może pojawić się natychmiast w przeglądarce na komputerze, ale ładować się powoli, być inaczej przycięte lub nie otwierać się w aplikacji na telefonie na tym samym koncie. Serwer jest tylko jednym z etapów; ostateczny widoczny rezultat zależy od zachowania klienta w sieci, zapisanych danych, uprawnień platformy i możliwości obsługi multimediów.
Odpowiedź serwera nie jest końcowym widokiem
Immich może zwrócić tę samą tożsamość zasobu i ten sam plik pochodny, a mimo to dwaj klienci wyświetlą go inaczej. Każdy klient musi zaplanować żądania, odebrać bajty, zdekodować multimedia, zastosować orientację lub układ, a następnie wyrenderować interfejs. Opóźnienie lub różnica wizualna powstałe po otrzymaniu odpowiedzi nie oznaczają, że zawartość bazy danych musi być inna.
Artykuł ZimaSpace o ścieżce danych Immich oddziela wybór danych w bazie od odpowiedzi multimedialnej i zakończenia widocznego dla klienta. Taki model zapobiega częstemu błędowi diagnostycznemu: uznawaniu każdego powolnego lub niespójnego ekranu za dowód, że serwer wygenerował inną odpowiedź.
W miarę możliwości zmierz dwa znaczniki czasu: moment zakończenia odpowiedzi API oraz moment, w którym multimedia stają się widocznie użyteczne. Jeśli czas odpowiedzi jest taki sam, ale czas wyświetlenia się różni, skup się na dekodowaniu, renderowaniu, pamięci lokalnej i stanie platformy. Jeśli odpowiedzi się różnią, przejdź do wcześniejszych etapów: żądań, zakresu konta lub przetwarzania serwera.
Klienci natywni i przeglądarkowi generują różne wzorce żądań
Aplikacja natywna może wstępnie pobierać elementy osi czasu, ponawiać żądania w tle, synchronizować przesyłane pliki lub grupować żądania inaczej niż karta przeglądarki. Przeglądarka ma własne limity połączeń, zasady buforowania, service workery i cykl życia strony. Dlatego identyczne gesty przewijania nie muszą generować identycznego ruchu.
W jednym z przypadków opisanych przez społeczność interfejs przeglądarkowy był dostępny, podczas gdy aplikacja mobilna odrzucała punkt końcowy serwera. Dokładna konfiguracja nie jest ogólnym dowodem dotyczącym każdego klienta, ale pokazuje, że dostarczanie strony internetowej i natywna walidacja API mogą opierać się na różnych oczekiwaniach dotyczących żądań i adresów URL.
Zarejestruj krótki ślad żądań dla tego samego konta, albumu i połączenia sieciowego. Porównaj adresy URL punktów końcowych, kody statusu, równoległość żądań, rozmiary przesyłanych plików pochodnych oraz odstępy między ponowieniami. Seria żądań widoczna tylko w jednym kliencie wyjaśnia różnicę w obciążeniu bez konieczności zmiany zapisanego zasobu w Immich.
Pamięci podręczne i dekodery multimediów zmieniają pozorny rezultat
Przeglądarki i aplikacje natywne przechowują różne miniatury, zasoby aplikacji, dane uwierzytelniające i zdekodowane multimedia. Mogą też wybierać różne ścieżki dekodowania sprzętowego lub formaty plików pochodnych. Jeden klient może ponownie użyć gotowej miniatury, podczas gdy drugi pobierze ją lub zdekoduje ponownie, przez co serwer będzie wydawał się niespójny, gdy w rzeczywistości różni się stan klienta.
W dyskusji społeczności dotyczącej alternatywnego natywnego klienta Androida wskazano, że decyzje implementacyjne klienta mogą wpływać na szybkość działania i doświadczenie użytkownika. Nie jest to kontrolowany test porównawczy, ale potwierdza architektoniczny fakt, że oddzielne interfejsy nie udostępniają dokładnie tej samej ścieżki wykonywania.
Wyczyść tylko pamięć podręczną testowanego klienta, pozostawiając stan serwera bez zmian, i ponownie otwórz znany zasób. Następnie porównaj natychmiastowe powtórzenie bez czyszczenia pamięci. Jeśli różnica zniknie po rozgrzaniu pamięci, znaczenie ma ponowne wykorzystanie danych przez klienta. Jeśli jeden format zawsze zawodzi, sprawdź obsługę kodeka, wybór pliku pochodnego i dekodowanie sprzętowe zamiast położenia danych w bazie.
Przeprowadź test różnic między dwoma klientami
Wybierz jedno konto, jeden znany album, jedno zdjęcie i jeden film. Podłącz obu klientów do tej samej sieci i zapisz wersję serwera, wersję klienta, adres URL oraz stan pamięci podręcznej. Przetestuj logowanie, odpowiedź osi czasu, otwarcie pełnego obrazu, uruchomienie filmu i jedno wyszukiwanie, zawsze w tej samej kolejności.
Projekt społeczności SailfishOS omawiający natywnego klienta Immich podkreśla, że oddzielna implementacja klienta musi samodzielnie podejmować decyzje dotyczące integracji z platformą i doświadczenia użytkownika. Potwierdza to, że tożsamość klienta jest rzeczywistą zmienną, nawet gdy każda implementacja komunikuje się z tym samym zapleczem.
Oznacz pierwszą rozbieżność jako dotyczącą żądania, odpowiedzi, transferu, dekodowania, renderowania lub uprawnień. Zmieniaj tylko tę warstwę: adres URL, stan pamięci podręcznej, format multimediów, uprawnienia klienta lub wersję aplikacji. Wyjaśnienie można uznać za potwierdzone dopiero wtedy, gdy kontrolowana zmiana usunie różnicę bez modyfikowania rekordów serwera ani własności danych użytkownika.
Polecane produkty
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania
Dlaczego Immich ponownie przetwarza istniejące dane po aktualizacji?
Immich może ponownie przetwarzać zasoby, gdy aktualizacja unieważni wcześniejsze wersje pochodne, metadane, modele lub stan zadań; powtarzająca się, niekończąca praca to osobna usterka.
Które zależności najczęściej wyznaczają rzeczywistą granicę wydajności Immich?
Immich jest ograniczony przez najwolniejszą zależność na każdej mierzonej ścieżce, dlatego przesyłanie, wyszukiwanie, przeglądanie i odtwarzanie mogą mieć różne limity.
Sieciowanie Immich: jak wykrywanie, DNS i routing zapewniają dostępność
Immich jest dostępny tylko wtedy, gdy wybór punktu końcowego, DNS, routing, NAT lub obsługa serwera proxy, TLS oraz odpowiedź aplikacji tworzą jedną prawidłową ścieżkę.
