J'ai récemment remarqué un énorme fichier (>3,5 Go) dans le dossier DCIM/.thumbnails. J'ai essayé de le supprimer, mais la prochaine fois que j'ouvre l'application Appareil photo, elle reconstruit le fichier (et verrouille le téléphone, en affichant parfois un message "analyse des médias en cours").
La taille totale des fichiers de toutes les photos (environ 2 000) affichées dans la galerie est d'environ 500 Mo. Il y a en outre environ 35 000 images dans des dossiers qui contiennent des fichiers .nomedia pour indiquer à Android d'ignorer les médias qu'ils contiennent. La taille totale de ces fichiers est d'environ 1,5 Go. L'application Galerie ignore correctement ces images, mais je me demande si l'application Appareil photo ne se comporte pas mal et ne les traite pas.
Je pense que ce problème est apparu depuis la mise à jour ICS... soit lorsque le téléphone (Samsung Galaxy Note) a été mis à jour pour la première fois depuis Gingerbread, soit à une date ultérieure.
Des idées, s'il vous plaît ?
1 votes
Le fichier thumbdata stocke une micro-vignette de 10kbyte pour chaque image (en ignorant les .nomedia) je crois. Si cela devient aussi énorme, Samsung a peut-être cassé quelque chose. MiniThumbFile.java
0 votes
Le MiniThumbFile Hmm stocke des données décalées avec l'id qui est un numéro attribué à tous les fichiers de votre appareil, y compris les fichiers nomedia. Si vous avez beaucoup de fichiers et que vos images obtiennent un id élevé, elles seront positionnées très tard dans le minithumbfile. Vous pouvez peut-être obtenir un fichier plus petit si vous essayez d'obtenir des identifiants plus bas pour vos images réelles (renommer les dossiers des images nomedia en quelque chose avec Z ou quelque chose comme ça pourrait fonctionner - réinitialiser également le media db quelque part dans les paramètres système > apps > Media Provider ou quelque chose comme ça).
0 votes
Merci pour vos suggestions, zapl. Je ne comprends pas pourquoi votre suggestion de nommer les dossiers nomedia plus tard dans l'alphabet serait utile ; les numéros d'identification plus élevés prennent-ils plus d'espace ? Heureusement, je semble avoir trouvé une solution de contournement. Voir ma réponse ci-dessous.
0 votes
Par ailleurs, je constate qu'il y a eu un vote pour "clore" cette question avant même qu'elle ait reçu une réponse. Je ne comprends pas. Quelqu'un pense-t-il que la question était d'une certaine manière inappropriée ?
1 votes
La question n'est pas liée à la programmation et serait, selon l'OMI, mieux adaptée à la rubrique suivante Les passionnés d'Android . En ce qui concerne l'identification plus grande : je ne suis pas sûr à 100% mais le fichier thumbfile utilise
long pos = id * BYTES_PER_MINTHUMB;comme position dans le fichier, donc plus l'identifiant est grand, plus le fichier doit être grand. 2000 de ces pouces (avec les ids 0-1999) ne devraient nécessiter qu'environ 20mb. La partie qui me trouble est que vous avez un fichier minithumb4 alors que la source officielle n'a qu'une version 3 de minithumb.0 votes
Je ne connaissais pas les enthousiastes d'Android. Je ne pense pas l'avoir déjà rencontré dans mes recherches sur Google. Merci de me l'avoir signalé. Désolé d'avoir posté au mauvais endroit. (Mon fichier thumbdata4 n'a pas changé de taille depuis qu'il a été reconstruit initialement après que j'ai effectué la réinitialisation d'usine il y a trois jours, donc peut-être que mon problème a été résolu).