Android: ogromny plik thumbdata4 w folderze DCIM


22

Niedawno zauważyłem ogromny (> 3,5 GB) plik w folderze DCIM / .thumbnails. Próbowałem go usunąć, ale przy następnym otwarciu aplikacji Aparat odbudowuje plik (i blokuje telefon, czasami wyświetlając komunikat „Trwa skanowanie multimediów”).

Całkowity rozmiar wszystkich (około 2000) zdjęć wyświetlanych w galerii wynosi około 500 MB. Ponadto w folderach zawierających pliki .nomedia znajduje się około 35 000 obrazów, które instruują Androida, aby zignorował zawarte w nich multimedia. Ich całkowity rozmiar wynosi około 1,5 GB. Aplikacja Galeria poprawnie ignoruje te obrazy, ale zastanawiam się, czy aplikacja Aparat działa nieprawidłowo i faktycznie je przetwarza.

Myślę, że ten problem pojawił się od czasu aktualizacji ICS ... albo kiedy telefon (Samsung Galaxy Note) został po raz pierwszy zaktualizowany z Gingerbread, albo później.

Jakieś pomysły, proszę?


1
plik thumbdata przechowuje mikro miniaturę 10 KB dla każdego obrazu (ignorując te .nomedia) iirc. Jeśli robi się tak ogromny, Samsung mógł coś zepsuć. patrz MiniThumbFile.java

Hmm MiniThumbFile przechowuje przesunięcie danych z identyfikatorem, który jest liczbą przypisaną do wszystkich plików na urządzeniu, w tym plików nomedia. Jeśli masz dużo plików, a twoje zdjęcia mają wysoki identyfikator, zostaną umieszczone bardzo późno w pliku minithumb. Możesz uzyskać mniejszy plik, jeśli spróbujesz uzyskać niższe identyfikatory dla twoich prawdziwych obrazów (być może zmiana nazwy folderów obrazów nomedia na coś z Z lub tak może działać - również zresetuj db db o media gdzieś w ustawieniach systemu> aplikacje> Media Provider lub tak)

Dzięki za sugestie, zapl. Nie rozumiem, dlaczego twoja sugestia dotycząca nazwania folderów nomedia później w alfabecie pomogłaby; czy wyższe numery id zajmują więcej miejsca? Na szczęście chyba znalazłem obejście. Zobacz moją odpowiedź poniżej.

Nawiasem mówiąc, widzę, że istniał jeden głos, aby „zamknąć” to pytanie, zanim jeszcze udzielono odpowiedzi. Nie rozumiem. Czy ktoś uważa, że ​​pytanie było w jakiś sposób nieodpowiednie?

1
Pytanie nie ma związku z programowaniem i IMO lepiej pasowałoby do entuzjastów Androida . Jeśli chodzi o większy identyfikator: nie jestem w 100% pewien, ale plik kciuka używa long pos = id * BYTES_PER_MINTHUMB;jako pozycji w pliku, więc im większy identyfikator, tym większy musi być plik. 2000 takich kciuków (o identyfikatorach 0-1999) powinno potrzebować tylko około 20 MB. Część, która mnie myli, jest to, że masz plik minithumb4, podczas gdy oficjalne źródło ma tylko wersję minithumb 3.

Odpowiedzi:


4

Dzieje się tak, gdy ładujesz wiele obrazów jednocześnie za pomocą aplikacji innych firm, takich jak whats'app lub pixlrxperss. Jedynym znanym rozwiązaniem do tej pory jest zastąpienie pliku .thumbnail małym plikiem .thumbnail o tej samej nazwie. Mogą istnieć maksymalnie 2 takie pliki, które możesz za każdym razem wymieniać.


2

Jest to normalne i zwykle nie jest to błąd.

Zwykle.

Zanim zrobisz cokolwiek innego, spróbuj dowiedzieć się, czy pamięć telefonu używa systemu plików innego niż FAT lub którykolwiek z jego braci.

Jeśli nie używasz FAT lub podobnego, pliki te zgłaszają maksymalny rozmiar, ale w rzeczywistości nie zajmują znacznej ilości miejsca, ponieważ są to tak zwane pliki rzadkie . Oznacza to, że możesz je po prostu usunąć raz, a zostaną one odtworzone, ale będą miały rozmiar zerowy, pomimo zgłaszania maksymalnego rozmiaru.

Jeśli za pomocą FAT lub podobny, albo Podawane wielkość tych plików jest przyczyną problemów z innymi aplikacjami, postępuj zgodnie z instrukcjami w odpowiedzi prepbgg jest , aby zresetować miniatury indeksowania powrotem na zero, operację, która może chcesz powtórzyć sporadycznie.


1
przynajmniej na CyanogenMod9, partycja / mnt / sdcard, jeśli VFAT, więc nie obsługuje rzadkich plików - próba utworzenia takiego spowoduje utworzenie PRAWDZIWEGO ogromnego pliku wypełnionego zerami, a nie rzadkiego pliku.
Matija Nalis,

1

Przeglądając go, znalazłem odniesienia do błędu w ICS, który może powodować ten problem.

Następujące informacje tutaj mam:

  1. Usunięto plik thumbdata (w DCIM / .thumbnails)

  2. W Ustawienia-> Aplikacje-> Wszystko-> Galeria: wyczyszczone dane (tylko kilka MB), (wyczyściłbym również pamięć podręczną, jeśli coś tam było), a następnie „Wymuś zatrzymanie”

  3. W Ustawienia-> Aplikacje-> Wszystko-> Pamięć masowa: wyczyszczone dane (tylko około 30 MB), (wyczyściłbym również pamięć podręczną, jeśli coś tam było), a następnie „Wymuś zatrzymanie”

  4. Uruchomiłem ponownie telefon

Kiedy następnym razem uruchomiłem aplikację Aparat, przez długi czas nie odpowiadał, być może od 20 do 30 minut, prawdopodobnie podczas ponownego skanowania plików multimedialnych. Po odczekaniu, aż to się zakończy, wszystko wydaje się być w porządku:

  • Aparat, Galeria i QuickPic wydają się działać

  • thumbdata4 wydaje się mieć około 500 MB (wciąż zaskakująco duże, ale możliwe do zarządzania).


1
Mówiłem za wcześnie. Po przyklejeniu tego samego rozmiaru przez 4 lub 5 dni plik .thumbdata4 przeskoczył do 1,1 GB.

Usuń folder .thumnails i utwórz plik o tej samej nazwie w jego miejscu, co uniemożliwi odtworzenie folderu: forum.xda-developers.com/showthread.php?t=1318827&page=3

3
istnieje sugerowane rozwiązanie problemu: skopiuj plik .thumbnail .. nazwa pliku, usuń go i utwórz folder w dcim / thumbnails / o takiej samej nazwie, jak plik. Zapobiega to ponownemu tworzeniu pliku przez galerię. Ale chyba po pewnym czasie stworzy go pod inną nazwą. Mam w telefonie może 2 GB zdjęć. I około 3-4 GB plików .thumbnail .. jest to zasadne
Kokesh

@ 79E09796 Działa tylko do momentu zrobienia kolejnego zdjęcia lub przeniesienia zdjęć w telefonie.
Secko

1

Wiem, że pytanie jest stare, ale próbowałem znaleźć rozwiązanie tutaj i na forach z Androidem. Nikt nie wydawał się działać.

Utworzenie linku do / dev / null na .thumbnails rozwiązało problem i teraz wydaje się takie oczywiste:

  1. Podłącz telefon do komputera
  2. Znajdź ogromny folder DCIM / .thumbnails i usuń go
  3. Utwórz link do / dev / null jako root z nazwą folderu:

    $ sudo ln -s / dev / null .thumbnails

Dzięki temu folder nie zostanie utworzony ponownie. Nie zauważyłem, aby coś poszło nie tak w moim urządzeniu, nawet w przypadku miniatur na WhatsApp lub Quickpic.


1
Niestety, przynajmniej na CynogenMod 9 (oparty na Androidzie 4.0.4) / mnt / sdcard jest typu VFAT, więc dowiązania symboliczne nie są obsługiwane (ani inne fajne rzeczy, które działałyby na systemach plików ext2 / 3/4 - jak "chown root .thumbnails ; chmod 000 .thumbnails; chattr + i .thumbnails ")
Matija Nalis

0

W Androidzie 6.0 (Marshmallow) aplikacja Galeria została zastąpiona zdjęciami Google. Powinieneś być w stanie usunąć folder miniatur, ponieważ nie sądzę, że aplikacja Zdjęcia go używa.


-1

Jedynym sposobem jest usunięcie aplikacji Galeria i zainstalowanie innej aplikacji. QuickPic to aplikacja zastępcza, która nie buduje żadnych miniatur i jest szybka i wydajna.

Odpowiedź udzielona przez Andión również działa.

Pamiętaj, że musisz wyłączyć funkcje w różnych aplikacjach, aby uniknąć nakładania się. W menedżerze plików X-plore wyłącz opcję „Pokaż pliki multimedialne”, a miniatury nie będą generowane. Na koniec dodaj kilka .nomediaplików do folderu obrazów, do którego zwykle nie docierasz.


-1

Podaj nazwy plików wideo i obrazów, które zaczynają się od ., np .video. W folderze DCIM nie zostaną utworzone miniatury.

Innym rozwiązaniem jest wyłączenie aplikacji galerii dla listy aplikacji w ustawieniach.


1
Twoja pierwsza sugestia całkowicie ukryłaby również pliki obrazów i wideo - co raczej nie leży w interesie PO. I drugi, którego nie mógłeś poważnie powiedzieć (przynajmniej nie bez zaproponowania alternatywy, którą OP mógłby wykorzystać do oglądania tych mediów - w takim przypadku odpowiedź ta ma już lepiej).
Izzy

-2
  1. Najpierw usuń folder .thumbnails z folderu DCIM
  2. Następnie w folderze DCIM utwórz plik o nazwie „.thumbnails”

Gotowe.

Uwagi: Utwórz plik, a nie folder. Jeśli nie masz menedżera plików, pobierz bezpłatnie menedżera plików ES ze Sklepu Play.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.