27

I have recently noticed a huge (>3.5GB) file in the DCIM/.thumbnails folder. I have tried deleting it, but the next time I open the Camera app it rebuilds the file (and locks up the phone, sometimes displaying a "media scanning in progress" message, in the process.)

The total file size of all the (approximately 2,000) photos displayed in the Gallery is around 500MB. There are in addition around 35,000 images in folders which contain .nomedia files to instruct Android to ignore the media therein. The total file size of these is around 1.5GB. The Gallery app is correctly ignoring these images, but I wonder whether the Camera app is misbehaving and actually processing them.

I think this problem has emerged since the ICS upgrade ... either when the phone (Samsung Galaxy Note) was first updated from Gingerbread or at some later date.

Any ideas, please?

6
  • 1
    the thumbdata file stores a 10kbyte micro thumbnail for each image (ignoring the .nomedia ones) iirc. If it is getting that huge, samsung may have broken something. see MiniThumbFile.java
    – zapl
    Sep 12, 2012 at 23:05
  • Hmm MiniThumbFile stores data offset with the id which is a number that is assigned to all files on your device including nomedia files. If you have a lot of files and your images get a high id they will be positioned very late in the minithumbfile. You can maybe get a smaller file if you try to get lower ids for your real images (maybe renaming the folders of the nomedia images to something with Z or so could work - also reset the media db somewhere under system settings > apps > Media Provider or so)
    – zapl
    Sep 12, 2012 at 23:46
  • Thanks for your suggestions, zapl. I don't understand why your suggestion about naming the nomedia folders later in the alphabet would help; do higher id numbers take up more space? Luckily, I seem to have found a workaround. See my Answer below.
    – prepbgg
    Sep 13, 2012 at 13:23
  • Incidentally, I see there was one vote to "close" this question even before it was answered. I don't understand. Does someone think the question was in some way inappropriate?
    – prepbgg
    Sep 13, 2012 at 13:24
  • 1
    The question is not programming related and would IMO fit better on Android Enthusiasts. Regarding the larger id thing: I am not 100% sure but the thumbfile uses long pos = id * BYTES_PER_MINTHUMB; as position in the file, so the larger the id is the larger the file has to be. 2000 of those thumbs (with ids 0-1999) should need only about 20mb. The part that confuses me is that you have a minithumb4 file while the official source has just a minithumb version 3.
    – zapl
    Sep 13, 2012 at 16:31

8 Answers 8

5

This is normal and usually not a bug.

Usually.

Before you do anything else, try and figure out whether your phone's storage is using a file system that is not FAT or any of its brethren.

If you are not using FAT or similar, then those files report a maximum size, but actually do not take up any significant amount of space, since they are so called sparse files. That means you can just delete them once and they'll be recreated but be of zero size, despite reporting a maximum size of whatever.

If you are using FAT or similar, or the reported size of those files is causing trouble with other applications, follow the instructions in prepbgg's answer, to reset the thumbnail indexing back to zero, an operation which you may wish to repeat occasionally.

1
  • 1
    on CyanogenMod9 at least, /mnt/sdcard partition if VFAT, so does not support sparse files - trying to create one will instead create REAL huge file filled with zeroes, not sparse file. Jun 20, 2014 at 17:01
4

This happens when you load many images at one time through third party applications like whats'app or pixlrxperss. The only known solution till now is replacing the .thumbnail file with a small .thumbnail file of same name. There might be utmost 2 such files you might have to replace everytime.

3

I know the question is old, but I tried to find a solution here and on those android forums. None seemed to work.

Creating a link to /dev/null on .thumbnails solved the problem and now seems so obvious:

  1. Connect your phone to your computer
  2. Find the huge DCIM/.thumbnails folder and delete it
  3. Create a link to /dev/null as root with the folder's name:

    $ sudo ln -s /dev/null .thumbnails

This avoids the folder to get created again. I didn't notice anything going wrong in my device, not even with thumbnails on whatsapp or quickpic.

1
  • 2
    Unfortunately, on at least CynogenMod 9 (android 4.0.4 based) /mnt/sdcard is of VFAT type, so symlinks are not supported (nor other nice things which would work on ext2/3/4 filesystems - like "chown root .thumbnails; chmod 000 .thumbnails; chattr +i .thumbnails") Jun 20, 2014 at 17:05
1

By googling I have found references to a bug in ICS that may be causing this problem.

Following advice here I have:

  1. Deleted the thumbdata file (in DCIM/.thumbnails)

  2. In Settings->Applications->All->Gallery: cleared data (only a few MB), (I would also have cleared the cache if there was anything there), then "Force stop"

  3. In Settings->Applications->All->Media Storage: cleared data (only about 30MB), (I would also have cleared the cache if there was anything there), then "Force stop"

  4. Restarted the phone

When I next ran the Camera app it was unresponsive for a long time, perhaps 20 to 30 minutes, presumably while it was re-scanning media files. After waiting for this to complete things now seem to be OK:

  • Camera, Gallery and QuickPic all seem to work

  • thumbdata4 seems to have settled at about 500MB (still surprisingly large, but manageable).

4
  • 2
    I spoke too soon. After sticking at the same size for 4 or 5 days the .thumbdata4 file has now jumped to 1.1GB.
    – prepbgg
    Sep 17, 2012 at 7:47
  • 1
    Delete the .thumnails folder and create a file with the same name in it's place, this will prevent the folder from being recreated: forum.xda-developers.com/showthread.php?t=1318827&page=3
    – 79E09796
    Mar 13, 2013 at 10:35
  • 4
    there is a suggested waz to solve this: copy .thumbnail.. file name, delete it and create folder in dcim/thumbnails/ with the same name as the file had. This prevents gallery from making the file again. But I guess after some time it will create it with different name. I have maybe 2GB of photos in the phone. And about 3-4GB of .thumbnail files.. this is rudiculous
    – Kokesh
    Sep 6, 2013 at 9:13
  • @79E09796 It only works until you take another photo or move photos around on your phone.
    – Secko
    Oct 21, 2013 at 23:01
0

In Android 6.0 (Marshmallow) the Gallery application was replaced with Google Photos. You should be able to delete the thumbnails folder as I don't think the Photos application uses it.

-1

The only way is to remove the Gallery app and install another app. QuickPic is a replacement application that that doesn't build any thumbnails and is fast and efficient.

The answer given by Andión also works.

Note that you have to disable features among various apps to prevent stacking up. In X-plore file manager, disable the "Show media files" and it wont generate thumbnails. Lastly add some .nomedia files in the image folder you don't normally reach.

-1

Give your videos and images file names that start with ., like .video. Then no thumbnails will be created in your DCIM folder.

Another solution is to disable your gallery app for you app list in your settings.

1
  • 1
    Your first suggestion would hide the image and video files completely as well – which is unlikely to be in the OPs interest. And the second one you couldn't mean seriously (at least not without suggesting an alternative the OP could use to view those media – in which case this answer already has it in a better way).
    – Izzy
    Jul 14, 2014 at 15:10
-2
  1. First, delete .thumbnails folder from DCIM folder
  2. Then in DCIM folder create file with name '.thumbnails'

You are done.

Notes: Create a file, not a folder. If you don't have file manager, then download ES file manager from Play Store for free.

You must log in to answer this question.