I just came across this realization last night, and it is very, very disconcerting - to say the least.
I have had my EVO since day one launch - no problems with it. I am not rooted, and have the latest OTA update applied.
I actually have the two Transformers moves from the HD2 on my memory card from a friend, as well as a couple more he ripped/formatted for our phones (he now has an EVO as well). The night before last I was bored/tired and stayed up in bed watching parts of both films. One day later (last night) I was out with friends and one of them asked me to show another how good the video looks on our phones. I fired up Meridian (what I always use to watch movies on the EVO) and was shocked to find the two TF films were nowhere to be found. What's more, the listing of "VIDEO00__" files from the EVO camcorder seemed suspiciously short - like some of those were missing, too. Now, I know that at least the TF films were on there the night before.
I got home, removed the card from the phone and fired it up on my laptop. I used two file recovery programs: Recuva and Pandora Recovery (both free) to analyze the card. I found the Transformers files as if they'd been deleted. I also found a whole host of other files that have been deleted. The vast majority of them seemed to be media of some sort, from photos to Video files (taken with the phone). Since most of the media produced from the phone are "IMAG00__.jpg" or "VIDEO00__.3gp" and I DO manually delete some of them time to time, it was hard to tell what was intentionally deleted and what wasn't. HOWEVER, there were definitely media files I would NOT have deleted, like pictures from my Wallpapers folders, photos from other folders I manually renamed based on the content, etc.
I don't know how long this has been going on - I know that the file recovery program Recuva tell you what file overwrote another. Using that, I could see that a movie I would not have deleted (Iron Man) was overwritten with a photo taken with the phone that, based on the file number, was taken on or about July 4th. Flipping through my video gallery, I am certain I am missing many of those, too, as videos from a certain event (family gathering) that I know I had a handful of files for now only have one.
I've had the phone now for basically a month and a half - and while I am normally good about backing up here and there I have neglected to do so often with my EVO as I've been very busy (getting married in about a month) and I didn't think I'd need to have a backup short of physically losing the phone (have never lost a phone). This realization scares the heck out of me, and I'm wondering if anyone has experienced it or has any ideas about it. Until last night when I happened to be looking for a specific file(s) I used the night before, I didn't have any idea this was happening.
If it helps, in between the night when I watched the movies that later went missing and the night I realized they were gone I connected my EVO to the computer via USB to transfer a file and charge it. I realized recently whenever I connected the phone the computer would automatically read/access the card without me ever having to choose the option from the pull down menu. I thought that maybe that kind of activity could be the root cause of missing files (you know how flash drives don't like to be fiddled with while reading/writing). I did some searching before starting this post and found out that behavior is caused by a setting in DoubleTwist which I have since changed. Still, I have a hard time believing that's the root cause of files which just seem to be deleted without me ever doing it.
Any thoughts or ideas? Any way you members can check to see if you seem to be missing any media (or other) files?
Sounds like phone corrupted card. Sorry, you're sol. There's another couple of posts relating to this subject and a possible remedy for future occurrences with this problem. Either look for post with subject of corrupt card or files disappear. It's in the same section as this one, you might have to look through a few pages before you see them. Good luck.
Sent from my PC36100 using XDA App
It all makes sense now, Optimus Prime destroyed the data when he found out you ripped them.
No doubt
Sent from my PC36100 using XDA App
After using HTC Voice Recorder my card got corrupted so I reformatted it and tried again... Not sure why, but HTC Voice Recorder corrupts my card EVERY time =/
For a freebee, try virtualrecorder. Cool features. Sounds excellent.
Sent from my PC36100 using XDA App
herbthehammer said:
Sounds like phone corrupted card. Sorry, you're sol. There's another couple of posts relating to this subject and a possible remedy for future occurrences with this problem. Either look for post with subject of corrupt card or files disappear. It's in the same section as this one, you might have to look through a few pages before you see them. Good luck.
Sent from my PC36100 using XDA App
Click to expand...
Click to collapse
Really? I'll look for them but I would have thought a corrupt card would manifest in some other way - like not functioning when you try to record or save something, not systematically deleting files. Strange.
midri said:
After using HTC Voice Recorder my card got corrupted so I reformatted it and tried again... Not sure why, but HTC Voice Recorder corrupts my card EVERY time =/
Click to expand...
Click to collapse
I've only used my voice recorder a few times. After reading this, maybe I won't anymore.
I just had to chime in that this very thing happened to me and with the same movies that i got from the files of the hd2.
All i know is that i had a gig or so left on my card and then the next day i had over 6 left.
The good thing is i had the card and all its content backed up on the wifes computer.
Sent from my evo while tying on the warm porcelain that is my toilet
Update:
I used that recuva you recommended and it worked! Got all my pics back. I've been wondering what on earth caused it to be lost in the first place because I haven't installed anything lately. I am rooted and I noticed alot of titanium backup files were also gone. Sprite backup files were gone. A mystery indeed. I've learned my lesson though. Backup. More. Frequently.
I've been experiencing some maddening issues with corruption of sdcard data. After much googling and finding some other reported occurrences of this, but not finding much info that's been helpful in solving the problem, I thought I'd compile and post some data in the hopes that others could add to it - hopefully leading to some kind of conclusion and maybe even a solution. I apologize because this is going to be a long post - hopefully it will be worth it.
Issue description:
There's a directory called LOST.DIR on sdcards in android phones. From what I've gathered, it contains lost/corrupted/orphaned files from the sdcard. When these files are moved to LOST.DIR, they're renamed with seemingly random strings of numbers and any file suffixes are stripped. Other OS's (Mac, Windows, etc.) have similar directories that serve similar purposes. The problem that I and others are experiencing is an alarming rate of sdcard data corruption, causing the LOST.DIR directory to fill up rather quickly, sometimes reaching multiple GB's in size. I’ve seen up to a dozen new files per day appearing in this directory. It's gotten to the point where I no longer trust that any data I put on my sdcard will remain intact.
I've read a few theories on how/why this happens. I've read that this is a Mac-related issue and only happens when mounting the sdcard on a Mac. This is not the case, as I've had this issue occur regardless if I'm mounting the card on a Mac, on a Windows PC (XP or 7), or even when mounting the card in a card reader and not from the phone directly (though I don't think the data corruption is occurring during mounting the card, but rather when the card is unmounted from the phone either when shutting the phone down or when unmounting the card from the phone during a request to remount the card via USB). I've even had a few (rare) occurrences of new files appearing in LOST.DIR without mounting the card on any device except the phone itself. I've also read that it's ok to just delete the files in this directory to reclaim space on the sdcard, but I've found that the files in LOST.DIR are often files I need, or files that various applications need to function. For the most part, when files are found in LOST.DIR, they've actually been removed from their original location. Deleting the files in LOST.DIR means you'll never be able to recover those files.
Once files end up in LOST.DIR, it's painstaking to recover them. Since they no longer have file types/suffixes, you may have to try opening the files in a utility to be able to tell what they are. Or by trial and error try appending different suffixes until you can open the files in an appropriate application.
Examples of files from my sdcard that have ended up in LOST.DIR:
whole mp3's
partial mp3's (more on this below)
photos & videos taken with the Epic's camera
xml config files
cached browser files
sql lite db's stored by various apps on the sdcard (causing one or two apps to FC since the sql lite files are no longer where the app expects them to be)
flashable zip files
etc.
Basically, any file I have on my sdcard can become corrupted or orphaned and end up in LOST.DIR in a near-unidentifiable state. To add to the pain, sometimes the files in LOST.DIR are not complete files, and sometimes they're not moved there intact. I was playing an album stored on the sdcard, and one track cut off in the middle. I found the other half of the mp3 file in LOST.DIR. I've lost entire photos and videos to LOST.DIR, but for the most part the files that are moved there are munged together with other files. If you view some files in LOST.DIR with a utility that can open any file as text, you'll see that a single file in LOST.DIR can really be multiple files or parts of files munged together into one. I've seen parts of text files mixed in with jpg's from browser cache mixed in with html mixed in with xml mixed in with other unidentifiable data. Obviously if this happens the data is not recoverable.
Some theories which I've ruled out or partially ruled out:
Mounting/unmounting method: I always shut down, mount, unmount, etc. the phone and the sdcard properly. If I have the card mounted on a Mac or PC, I always use the appropriate OS-specific method of unmounting the card before turning off USB mounting on the Epic. I ran tests where I kept track of every step I took in booting, unmounting, remounting, etc. the sdcard to confirm this. Other users have also ruled this out as a cause (though I'm sure improperly unmounting a card can cause data problems)
Journaling: I confirmed this happens regardless of whether journaling is turned off or on
Ext4 file system: don't think this has anything to do with it, as I've seen this happen on Ext4 and RFS
ROM's: I confirmed that this seems to be happening on multiple ROMs: midNIGHT/Bonsai, Baked Snack, stock deodexed, etc.
Kernels: Seems to be happening on multiple kernels: Bonsai kernel, Baked Snack kernel, maybe one or two others I've tried
Card file system corruption: I've reformatted my sdcard more times that I can count in trying to get rid of this problem, doesn't seem to have any effect
Epic4g itself: this seems to be happening on many different android phones, so I'm ruling out a design flaw with the Epic4g
Theories I haven't ruled out:
android (froyo?) bug related to data integrity when mounting/unmounting the sdcard (let's hope not)
damaged or defective sdcard
I've read that some people have had success in banishing this problem by moving to a higher-class sdcard (doesn't really make sense to me, but whatever). I'm currently using the OEM 16gb (I'm assuming class 2 or 4) card that came with the Epic. In researching class 6 cards, it seems that the 8gb cards are generally more reliable than the 16gb cards, so I ordered a highly-rated 8gb class 6 card (still waiting for its arrival). I'll gladly give up storage space if I can count on data integrity. If it's a low-level android bug, then who knows if/when it will ever get dealt with.
Here are two links that have more info and user experiences with this issue:
- Google Code issue:
http://code.google.com/p/android/issues/detail?id=2500
- ZDNet article:
http://www.zdnet.com/blog/sybase/could-your-sd-card-cause-your-android-smartphone-to-crash-or-lose-data/1128
To be honest, I don't know how long I've been experiencing this problem. I don't know if it happened on Eclair, but it definitely happens on Froyo.
I apologize that this is so long, but hopefully it will help someone else and possibly even lead to some helpful information in dealing with this problem. I'll post my findings once I receive the new class 6 sdcard.
Peace.
Good info.
Do the original files get messed up anyway? I'm guessing the original files stay intact yeah? Or do they end up being messed up and unusable?
So for example, an mp3 file ends up in LOST.DIR but really it's still on your sdcard and you can play it with Media Player?
Let us know if a higher class card == less LOST.DIR files once you get that.
rsage said:
I've been experiencing some maddening issues with corruption of sdcard data. After much googling and finding some other reported occurrences of this, but not finding much info that's been helpful in solving the problem, I thought I'd compile and post some data in the hopes that others could add to it - hopefully leading to some kind of conclusion and maybe even a solution. I apologize because this is going to be a long post - hopefully it will be worth it.
Issue description:
There's a directory called LOST.DIR on sdcards in android phones. From what I've gathered, it contains lost/corrupted/orphaned files from the sdcard. When these files are moved to LOST.DIR, they're renamed with seemingly random strings of numbers and any file suffixes are stripped. Other OS's (Mac, Windows, etc.) have similar directories that serve similar purposes. The problem that I and others are experiencing is an alarming rate of sdcard data corruption, causing the LOST.DIR directory to fill up rather quickly, sometimes reaching multiple GB's in size. I’ve seen up to a dozen new files per day appearing in this directory. It's gotten to the point where I no longer trust that any data I put on my sdcard will remain intact.
I've read a few theories on how/why this happens. I've read that this is a Mac-related issue and only happens when mounting the sdcard on a Mac. This is not the case, as I've had this issue occur regardless if I'm mounting the card on a Mac, on a Windows PC (XP or 7), or even when mounting the card in a card reader and not from the phone directly (though I don't think the data corruption is occurring during mounting the card, but rather when the card is unmounted from the phone either when shutting the phone down or when unmounting the card from the phone during a request to remount the card via USB). I've even had a few (rare) occurrences of new files appearing in LOST.DIR without mounting the card on any device except the phone itself. I've also read that it's ok to just delete the files in this directory to reclaim space on the sdcard, but I've found that the files in LOST.DIR are often files I need, or files that various applications need to function. For the most part, when files are found in LOST.DIR, they've actually been removed from their original location. Deleting the files in LOST.DIR means you'll never be able to recover those files.
Once files end up in LOST.DIR, it's painstaking to recover them. Since they no longer have file types/suffixes, you may have to try opening the files in a utility to be able to tell what they are. Or by trial and error try appending different suffixes until you can open the files in an appropriate application.
Examples of files from my sdcard that have ended up in LOST.DIR:
whole mp3's
partial mp3's (more on this below)
photos & videos taken with the Epic's camera
xml config files
cached browser files
sql lite db's stored by various apps on the sdcard (causing one or two apps to FC since the sql lite files are no longer where the app expects them to be)
flashable zip files
etc.
Basically, any file I have on my sdcard can become corrupted or orphaned and end up in LOST.DIR in a near-unidentifiable state. To add to the pain, sometimes the files in LOST.DIR are not complete files, and sometimes they're not moved there intact. I was playing an album stored on the sdcard, and one track cut off in the middle. I found the other half of the mp3 file in LOST.DIR. I've lost entire photos and videos to LOST.DIR, but for the most part the files that are moved there are munged together with other files. If you view some files in LOST.DIR with a utility that can open any file as text, you'll see that a single file in LOST.DIR can really be multiple files or parts of files munged together into one. I've seen parts of text files mixed in with jpg's from browser cache mixed in with html mixed in with xml mixed in with other unidentifiable data. Obviously if this happens the data is not recoverable.
Some theories which I've ruled out or partially ruled out:
Mounting/unmounting method: I always shut down, mount, unmount, etc. the phone and the sdcard properly. If I have the card mounted on a Mac or PC, I always use the appropriate OS-specific method of unmounting the card before turning off USB mounting on the Epic. I ran tests where I kept track of every step I took in booting, unmounting, remounting, etc. the sdcard to confirm this. Other users have also ruled this out as a cause (though I'm sure improperly unmounting a card can cause data problems)
Journaling: I confirmed this happens regardless of whether journaling is turned off or on
Ext4 file system: don't think this has anything to do with it, as I've seen this happen on Ext4 and RFS
ROM's: I confirmed that this seems to be happening on multiple ROMs: midNIGHT/Bonsai, Baked Snack, stock deodexed, etc.
Kernels: Seems to be happening on multiple kernels: Bonsai kernel, Baked Snack kernel, maybe one or two others I've tried
Card file system corruption: I've reformatted my sdcard more times that I can count in trying to get rid of this problem, doesn't seem to have any effect
Epic4g itself: this seems to be happening on many different android phones, so I'm ruling out a design flaw with the Epic4g
Theories I haven't ruled out:
android (froyo?) bug related to data integrity when mounting/unmounting the sdcard (let's hope not)
damaged or defective sdcard
I've read that some people have had success in banishing this problem by moving to a higher-class sdcard (doesn't really make sense to me, but whatever). I'm currently using the OEM 16gb (I'm assuming class 2 or 4) card that came with the Epic. In researching class 6 cards, it seems that the 8gb cards are generally more reliable than the 16gb cards, so I ordered a highly-rated 8gb class 6 card (still waiting for its arrival). I'll gladly give up storage space if I can count on data integrity. If it's a low-level android bug, then who knows if/when it will ever get dealt with.
Here are two links that have more info and user experiences with this issue:
- Google Code issue:
http://code.google.com/p/android/issues/detail?id=2500
- ZDNet article:
http://www.zdnet.com/blog/sybase/could-your-sd-card-cause-your-android-smartphone-to-crash-or-lose-data/1128
To be honest, I don't know how long I've been experiencing this problem. I don't know if it happened on Eclair, but it definitely happens on Froyo.
I apologize that this is so long, but hopefully it will help someone else and possibly even lead to some helpful information in dealing with this problem. I'll post my findings once I receive the new class 6 sdcard.
Peace.
Click to expand...
Click to collapse
If I had to guess, it sounds like silent write corruption on the SD card, whereby writes to the card are reported successful, but the written blocks are (ocasionally) corrupted, which don't show up until they're later read. In which case I'd suspect the controller on the SD card itself is to blame.
If it wasn't silent corruption, i.e., writes were returning errors, the SD card should remount read-only automatically and there would be some OS-level notification. Although I suppose any such notification could be ignored.
The mounting issue is possibly a red herring, for two reasons. First, data blocks written to the SD card are also cached in RAM. Thus, once mounted, most of the read operations on critical file system metadata will come out of the file system buffer cache and not actually from the SD card. So even if the write corruption is an on-going thing, it could easily go masked until a device reboot or SD card unmount/remount, at which point the cached blocks are purged and (the corrupted versions) read from the card.
Second, fsck_msdos, which is responsible for populating LOST.DIR, runs at the time the SD card is mounted which is why mount events often corresponds to lost files showing up there.
rsage said:
Here are two links that have more info and user experiences with this issue:
- Google Code issue:
- ZDNet article:
Click to expand...
Click to collapse
Not to outright dismiss the existence of a kernel-level software bug, but the fact that relatively few folks for a given device are frequently reporting the issue leads me to think it's often hardware (likely SD card) related, or a result of a very unusual set of circumstances. At least, for the many bugs folks report having on the Epic, rampant SD card data corruption is not one I'm aware of.
See if the new SD card helps, if it does, I'd say you just have a bum card and wouldn't even blame it on a particular brand or class.
If you continue to have issues even with the new card, it would be nice to rule out a hardware defect with your particular Epic, but short of you getting a new phone or other people reporting the same issue, that would be difficult to do.
Otherwise the two best things to do are to: (i) figure out a set of files/operations/whatever that reliably repeat the corruption issue, if possible, and (ii) narrow the sources of corruption down by avoiding mounting the SD card on other machines. You may have to occasoinally "Unmount SD card" and remount it from the Settings -> Sd card and phone storage for the corruption to show up though.
p3dr0maz said:
Good info.
Do the original files get messed up anyway? I'm guessing the original files stay intact yeah? Or do they end up being messed up and unusable?
So for example, an mp3 file ends up in LOST.DIR but really it's still on your sdcard and you can play it with Media Player?
Let us know if a higher class card == less LOST.DIR files once you get that.
Click to expand...
Click to collapse
Very good question - the answer is "all of the above"
Some files (I'd say ~25%) have been recoverable once I've been able to figure out what they are. The majority of the files have been unrecoverable though - either because part of the file remained in its original location and part of the file got moved to LOST.DIR, or because several files or pieces of several different files got moved from their original locations to LOST.DIR and got "munged" together in one file.
mkasick said:
If I had to guess, it sounds like silent write corruption on the SD card, whereby writes to the card are reported successful, but the written blocks are (ocasionally) corrupted, which don't show up until they're later read. In which case I'd suspect the controller on the SD card itself is to blame.
Click to expand...
Click to collapse
Very good theory, though I and others have noticed one thing that goes against it - some of the files were living and being used on the sdcard for quite a while before they got corrupted and moved to LOST.DIR. A couple examples: 1) I had listened to the affected mp3 several times before one day it suddenly cut off near the 1/2 way mark, after which I discovered the other half of the file was in LOST.DIR, and 2) I had used/read several other read-only files and sql lite db's numerous times before they suddenly no longer existed and were found in LOST.DIR (sometimes recoverable, sometimes not). When the latter happened, a zero byte file with the same name existed in the original file location, but the real file had been renamed as something like "567801" and moved to LOST.DIR. So it seems that when they were originally written to disk, the writes were successful.
The mounting issue is possibly a red herring, for two reasons. First, data blocks written to the SD card are also cached in RAM. Thus, once mounted, most of the read operations on critical file system metadata will come out of the file system buffer cache and not actually from the SD card. So even if the write corruption is an on-going thing, it could easily go masked until a device reboot or SD card unmount/remount, at which point the cached blocks are purged and (the corrupted versions) read from the card.
Second, fsck_msdos, which is responsible for populating LOST.DIR runs at the time the SD card is mounted, which is why mount events often corresponds to lost files showing up there.
Click to expand...
Click to collapse
Great information, thanks!
Not to outright dismiss the existence of a kernel-level software bug, but the fact that relatively few folks for a given device are frequently reporting the issue leads me to think it's often hardware (likely SD card) related, or a result of a very unusual set of circumstances. At least, for the many bugs folks report having on the Epic, rampant SD card data corruption is not one I'm aware of.
Click to expand...
Click to collapse
Possibly (and hopefully) you're right. Another possibility is that it's a more widespread issue, and users aren't realizing it for various reasons. Most of the corrupt/orphaned files I'm seeing in LOST.DIR wouldn't necessarily cause any overt symptom that anyone would notice - files like browser cache files, etc. It might not be noticeable to the user until a more important file is affected, and the issue may be dismissed out-of-hand or chalked up to some other more common issue usually fixed by clearing the data for a problematic app. One of the most common things I see on these boards is sudden and unexplained FC's of various apps, sometimes remedied by clearing data for the app, sometimes by reinstalling the app, and often users simply wipe all data and start over - never sure what the cause of the problem was. Every phone that's mentioned in various threads on this issue, or other android phones I've personally checked, have had LOST.DIR and LOST.DIR has never been empty. This seems to be true even if a specific phone wasn't having any issues that the user noticed. Obviously my sample size is very small, so I'm not saying this is universally true. But I think it's at least a possibility that the issue is more widespread and users may not be noticing it due to the nature of the affected files or maybe they're thinking it's some other problem.
I've also read a fair number of comments on this issue like "dude, wow I didn't know I had this directory but I do and there's 2gb of stuff in there!" Well, that 2gb of "stuff" had to come from somewhere
See if the new SD card helps, if it does, I'd say you just have a bum card and wouldn't even blame it on a particular brand or class.
If you continue to have issues even with the new card, it would be nice to rule out a hardware defect with your particular Epic, but short of you getting a new phone or other people reporting the same issue, that would be difficult to do.
Click to expand...
Click to collapse
Agreed, though this problem does seem to span many different brands/models of android devices (for those that have noticed the problem), so I'm thinking it's probably not my Epic. I'm hoping it's the card like you said. MicroSD cards aren't the most reliable storage media on the planet, so I'm really hoping it's just the card.
Otherwise the two best things to do are to: (i) figure out a set of files/operations/whatever that reliably repeat the corruption issue, if possible, and (ii) narrow the sources of corruption down by avoiding mounting the SD card on other machines. You may have to occasoinally "Unmount SD card" and remount it from the Settings -> Sd card and phone storage for the corruption to show up though.
Click to expand...
Click to collapse
Agreed. Though I've had occasions when I've been testing and the files in LOST.DIR will increase without me really doing anything. In other words, I'll do a fresh boot of the phone, look in LOST.DIR with Root Explorer or ES and check the file count, then shut down the phone normally, wait a while, reboot normally, and there may be a few additional files in there. Of course there are always background processes running and probably accessing the card even if I'm not doing anything on the phone, so who knows. I've also rebooted the phone, checked the file count, properly mounted and unmounted the phone via USB on a Mac or PC, then checked the file count again just to see that there were a dozen new files in there. Good times...
mkasick - you seem very knowledgeable about the mechanics of reads/writes and internal android processes - do you think it's possible that the characteristics of certain ROM's, kernels, CW versions, or simply the act of flashing things all the time could have anything to do with this? I'm thinking not...
rsage said:
Very good theory, though I and others have noticed one thing that goes against it - some of the files were living and being used on the sdcard for quite a while before they got corrupted and moved to LOST.DIR.
Click to expand...
Click to collapse
The Wikipedia page on the FAT file system explains how it works a bit, although I imagine there's more illustrative examples out there. But basically, file data blocks are stored in clusters, and there's a table that contains entires for each cluster in the file system, where each table entry contains the index (location) of the next cluster, if that cluster is part of a file.
So it's quite possible that file data blocks for a given file are written out fine, but when the FAT is modified while writing/modifying a file that happens to be adjacent to it, the cluster indexes for the existing file are corrupted.
rsage said:
1) I had listened to the affected mp3 several times before one day it suddenly cut off near the 1/2 way mark, after which I discovered the other half of the file was in LOST.DIR
Click to expand...
Click to collapse
This is likely the result of a single corrupt cluster index. The corrupt index points to a cluster in the middle of the mp3, and if it were accidentally changed to "0" then (roughly) half the file is lopped off. Later, when fsck_msdos runs and scans the FAT and directory entries, it sees a chain of valid clusters that's not attached to any file. So it gives it a new file name and stuffs it in LOST.DIR.
rsage said:
When the latter happened, a zero byte file with the same name existed in the original file location, but the real file had been renamed as something like "567801" and moved to LOST.DIR.
Click to expand...
Click to collapse
If the entire file was in LOST.DIR, it sounds like a corrupt directory entry. That's a bit more suspicious, particularly if other part of the directory entry (name, time, etc.) were OK.
rsage said:
Most of the corrupt/orphaned files I'm seeing in LOST.DIR wouldn't necessarily cause any overt symptom that anyone would notice - files like browser cache files, etc.
Click to expand...
Click to collapse
One way orphaned files happen is when a file is deleted, and it's corresponding directory entry is removed, but the updated FAT hasn't been written out yet. The phone shouldn't be doing this too often, as long as the SD card is always properly unmounted (e.g., phone is properly shutdown). I could see computers doing this rather frequently, particular if the USB device isn't "safely removed".
Afterall, orphaned files in that instance aren't a safety/corruption issue. There's just less free space in the file system until a fsck or other consistency check tool is run.
In any event, I don't find the existence of these alone to be terribly surprising, especially in absence of missing files or other more significant corruption.
rsage said:
One of the most common things I see on these boards is sudden and unexplained FC's of various apps, sometimes remedied by clearing data for the app, sometimes by reinstalling the app, and often users simply wipe all data and start over - never sure what the cause of the problem was.
Click to expand...
Click to collapse
In almost all instances I expect those are due to data corruption on the /data file system, which, with ext4 can often happen on a phone crash or battery pull. Even with a journal, ext4 uses a delayed allocation scheme whereby newly allocated data may not be committed up to a few minutes after being "written", a window during which if the phone crashes, those files will experience data loss.
rsage said:
Every phone that's mentioned in various threads on this issue, or other android phones I've personally checked, have had LOST.DIR and LOST.DIR has never been empty.
Click to expand...
Click to collapse
As an anecdote: I usually end up with 2-3 orphaned files in LOST.DIR everytime I do a kernel upgrade, which I issue from within Android using redbend_ua without a clean shutdown. But I've never seen more obvious corruption. And I never see files in LOST.DIR after preforming a clean shutdown and clean unmounts.
rsage said:
But I think it's at least a possibility that the issue is more widespread and users may not be noticing it due to the nature of the affected files or maybe they're thinking it's some other problem.
Click to expand...
Click to collapse
You may be right about that, particularly if the affected files are thumbnails or related to the media cache.
Still, I suspect if the problem were somewhat-spread among Epic owners here, we'd see a lot more posts about SD card corruption.
rsage said:
do you think it's possible that the characteristics of certain ROM's, kernels, CW versions, or simply the act of flashing things all the time could have anything to do with this?
Click to expand...
Click to collapse
Since most of those activities don't result in SD card mutations, I suspect not. Also, it doesn't look like "the problem" is confined to users to root and custom ROM.
A few more notes:
If it always happens after a phone crash, random reboot, etc, it's just file system corruption and there's little that can be done. Amusingly, RFS is essentially a "journaled FAT" and would solve that problem, but it's not
used on SD cards on Samsung devices, which otherwise seems like a perfectly appropriate use for it.
I'm suspicious of it being a bug in the file system driver. If it was, corruption would be discovered at random times instead of specifically after a reboot or remount event, which is when folks seem to report it happening.
It could be a bug in fsck_msdos. I'd be a bit surprised if it was, but I don't think fsck_msdos is used particularly often outside of Android or other embedded devices, so the code may not be as well vetted as, say, fsck.ext3. One way to tell would be to disable fsck_msdos entirely and see if data still goes missing.
EDIT 10char
k0nane said:
Just to jump in with my opinions - I'd format that SD card. If you continue to have issues, something else is at fault - but at this point, it sounds like you've just got a corrupted/out-of-sync FAT, and the easiest way to guarantee a fix is a format.
Click to expand...
Click to collapse
Someone didn't bother to read the thread...
stackz! said:
Someone didn't bother to read the thread...
Click to expand...
Click to collapse
I did read the thread. I missed the part where he stated he'd formatted his SD card. Piss off.
mkasick
Thanks for the great post, that really clarifies what could potentially be happening with the data. I'll report back when I have more info.
Sent from my SPH-D700 using XDA App
You know Ive noticed this also,photos will just up and dissapear or get corrupted and wont open and really lag the gallery app,same thing happens to songs; Ive never worried about it,I just chalked it up to a bad sdcard,and Ive always got 3 backups of all data I plan on keeping. I would also like to know what the real cause is,keep us informed...
Sent from my MyFrankenstein EC05OCE using XDAPA...
I have also had this same problem. Its really disgusting. This is about all I can take from this phone. I'm about to smash it and go back to a dumb phone. What's the point of a smart phone is the data is not relable.
OK sorry about the ranting.
I started a thread about this in Q&A. I refomatted the card yesterday again I think that's the 5th time. And so far its good AFAIK 21 hours in. O all the things/Devices I had moded hacked I have never had data ****ing up like this.
Sent from the Drivers Seat of my Suby txting and Driving doing 100MPH+ in a school zone! Ha.
zman519 said:
I have also had this same problem. Its really disgusting. This is about all I can take from this phone. I'm about to smash it and go back to a dumb phone. What's the point of a smart phone is the data is not relable.
OK sorry about the ranting.
I started a thread about this in Q&A. I refomatted the card yesterday again I think that's the 5th time. And so far its good AFAIK 21 hours in. O all the things/Devices I had moded hacked I have never had data ****ing up like this.
Click to expand...
Click to collapse
I feel your pain. Found your thread in Q&A, I missed it when I was searching the forum before I started this thread, probably because there's no reference to LOST.DIR. A lot of similarities in our setups and the issues we're seeing. Keep us posted.
By the way, you mentioned that you've had files go down to zero bytes but then at some point go back to normal. I've never had a file come back from this kind of corruption. Do you have any idea how this happened - did you run any kind of utility on the sdcard from windows or android OS for example?
How repeatable is the corruption?
If, for example, you reformat the SD card, restore its contents from backups, is it the same files that are corrupted after some time? Roughly how long after a reformat is corruption observable?
mkasick said:
How repeatable is the corruption?
If, for example, you reformat the SD card, restore its contents from backups, is it the same files that are corrupted after some time? Roughly how long after a reformat is corruption observable?
Click to expand...
Click to collapse
Only answering for myself - never been the same files for me. Seems that it could be any file at any time, I've never actually seen the same file get corrupted twice before or after a reformat (assuming I was able to restore it after the first corruption). I can see new corruption after a reformat as soon as I start unmounting/mounting the sdcard. If I reformat then never unmount/mount the card via USB, occurrences are much rarer (though I have seen a few occurrences after just rebooting the phone, which of course unmounts & mounts the card as well).
rsage said:
I can see new corruption after a reformat as soon as I start unmounting/mounting the sdcard.
Click to expand...
Click to collapse
And these are confirmed missing files that are no longer in their original location, or are zero-length or something?
When you say "unmounting/mounting", do you mean just on the phone, or only after mounting/unmounting it on a PC? For example, if you were to reformat, copy a bunch of data over, verify (on the phone) that it's correct, then click "Unmount SD card" on the phone a bunch of times (remounting inbetween), does that pretty much guarantee corrupt/lost files?
Also, do you store any apps on the SD card? If so, do those appear to be OK, or can they get corrupted as well?
Edit: The more times you mount/unmount the SD card, does corruption appear to worsen? Is this independent of how much you otherwise actually use the card?
mkasick said:
And these are confirmed missing files that are no longer in their original location, or are zero-length or something?
Click to expand...
Click to collapse
Well, I've seen both. I've had files go completely missing (photos taken with the camera, an mp3 or two, etc.), I've had files go to zero bytes (zip's, sql lite db's), and I've had files stay in place but get partially truncated (other mp3's, maybe some others).
When you say "unmounting/mounting", do you mean just on the phone, or only after mounting/unmounting it on a PC? For example, if you were to reformat, copy a bunch of data over, verify (on the phone) that it's correct, then click "Unmount SD card" on the phone a bunch of times (remounting inbetween), does that pretty much guarantee corrupt/lost files?
Click to expand...
Click to collapse
I'd say 90% of the issues I've had have been noticed after mounting the card, while in the phone, on a Mac or Windows PC. I notice the issue after I then unmount the card from the Mac/PC, at which point the Epic mounts the card. However, I've also seen it happen when shutting down the Epic, removing the card, and mounting it on a Mac or PC with a card reader (I see the evidence after reinserting the card back in the Epic and booting back up). I'm not sure if it's happening when the card is unmounted from the Epic, or when it's mounted on some other device, I could try to track that down.
I have less often seen it happen when shutting down and restarting the phone. I haven't tried repeatedly hitting unmount/mount in the Epic settings.
Also, do you store any apps on the SD card? If so, do those appear to be OK, or can they get corrupted as well?
Click to expand...
Click to collapse
Good question - until a few days ago, I had no apps on the SD card. I've been noticing the data corruption well before that - weeks, if not a couple months. Really don't know how long it's been going on. Within the last few days I have had to move some apps to the SD card. I haven't had an actual app/apk get corrupted (that I'm aware of), but I have had data get corrupted for apps that store data on the SD card.
Edit:
Edit: The more times you mount/unmount the SD card, does corruption appear to worsen? Is this independent of how much you otherwise actually use the card?
Click to expand...
Click to collapse
Yes, and yes
rsage said:
I feel your pain. Found your thread in Q&A, I missed it when I was searching the forum before I started this thread, probably because there's no reference to LOST.DIR. A lot of similarities in our setups and the issues we're seeing. Keep us posted.
By the way, you mentioned that you've had files go down to zero bytes but then at some point go back to normal. I've never had a file come back from this kind of corruption. Do you have any idea how this happened - did you run any kind of utility on the sdcard from windows or android OS for example?
Click to expand...
Click to collapse
I did not run any thing on the sdcard with the data on it, win or android. At frist I saw this happening to videos I hid with "pandora" (its a media hider) so I thought that was messing up the data. But then my nandroid imgs where not the right hash & some times 0 bytes so at that point I ruled out pandora.
This is just an idea I have know testing to conferm it. BUT what if the problem is simpley a junk samsuck sdcard? I mean look at it, the usb cable is junk that came with the phone, froyo from them is junk, bluetooth, gps on 2.1 (if it where not for the devs hear the phone would be totaly junk to me and I would have got a new phone)
Sent from the Drivers Seat of my Suby txting and Driving doing 100MPH+ in a school zone! Ha.
rsage said:
I'd say 90% of the issues I've had have been noticed after mounting the card, while in the phone, on a Mac or Windows PC. I notice the issue after I then unmount the card from the Mac/PC, at which point the Epic mounts the card.
Click to expand...
Click to collapse
I think what we're establishing here, and correct me if I'm wrong, but data corruption appears to be correlated with mount events on the Epic. The more times you mount, the higher probability of encountering data corruption.
Furthermore, there's instances in which the corrupt data was observed to be OK on a PC prior to the remount. And it's independent of how much the card is actually used on the Epic between mounts.
If that's all the case, then there's definitely something suspicious about the mounting process. It's certainly not spurious corruption. It could still be "bad cards," in the sense that the mounting process is correct but tickles something in the controller. But I'm inclined to believe it may be a software-level issue afterall.
I'm still curious if the problem persists across multiple SD cards in the same device.
zman519 said:
This is just an idea I have know testing to conferm it. BUT what if the problem is simpley a junk samsuck sdcard? I mean look at it, the usb cable is junk that came with the phone, froyo from them is junk, bluetooth, gps on 2.1 (if it where not for the devs hear the phone would be totaly junk to me and I would have got a new phone)
Click to expand...
Click to collapse
That's possible, new card is coming today so hopefully I'll have new info soon
"IndexService" issue solved..(Quick battery drain & endless or error index process)
"IndexService" issue cause drain your battery very very quickly... Especially, if your sd card loaded with a lot of big pdf files...
If you dont want to index your "files" go to "s search" settings through menu softkey (long press for open s search then enter menu) and uncheck files... and voila.. your pdf's and another user files not index anymore..
Actually, i really want all of my files content index by note3.. This is very very useful for my pdf library.. But for my situation; several pdf's (some of them are big textbook's, thousands of page) cause never ending indexing process and it's ruin battery life terribly..
If someone find a REAL solution beside of mine, please tell us...
Reason4444 said:
"IndexService" issue cause drain your battery very very quickly... Especially, if your sd card loaded with a lot of big pdf files...
If you dont want to index your "files" go to "s search" settings through menu softkey (long press for open s search then enter menu) and uncheck files... and voila.. your pdf's and another user files not index anymore..
Actually, i really want all of my files content index by note3.. This is very very useful for my pdf library.. But for my situation; several pdf's (some of them are big textbook's, thousands of page) cause never ending indexing process and it's ruin battery life terribly..
If someone find a REAL solution beside of mine, please tell us...
Click to expand...
Click to collapse
There is an easy solution. Create a folder for your pdfs, drop a .nomedia file in the root of that folder, and put all of your pdfs you dont want indexed in there.
I found that the indexservice process is taking more cpu and time when I have more number of pdf files i my memory card.
So, right now either you can put less number of pdf files on your device to avoid the lag or just wait till the indexing completes.
After the indexing completes, the device works as wonderfully as it was working before inserting my memory card.
Hope I helped...Cheer!!!
Or you can just kill it in settings/apps/active...
It shuts up untill you reboot.
Send From My Samsung Galaxy Note 3 N9005 Using Tapatalk
I really hope samsung pushes out an update about it. Even after indexing is done whenever I try to do something quickly it seems it will FC because of the indexer. can't really play any games on it as well because of it.
ShadowLea said:
Or you can just kill it in settings/apps/active...
It shuts up untill you reboot.
Send From My Samsung Galaxy Note 3 N9005 Using Tapatalk
Click to expand...
Click to collapse
Wat you mean, i don't have root, wat i need to kill ?
WandersonGD said:
Wat you mean, i don't have root, wat i need to kill ?
Click to expand...
Click to collapse
I don't have root either. Just go to settings > general > application manager > running, tap .com.samsung.android.strokesearch:service. (down near the bottom) Hit 'Stop' and then 'yes'.
Now it stays away until you reboot, at which point you need to do this again. Bit tedious, but it's quicker than rooting.
Screenshot attached.
Send From My Samsung Galaxy Note 3 N9005 Using Tapatalk
Easy way to root ant fix this issue
You can fix this issue very easily.
1. Root your phone in under 1 minute at towelroot.com
2. download a freezing app (I paid for a really good one, $6 for titanium backup pro)
3. freeze the offending service.
I didn't know how to do any of these things an hour ago. A quick google question for any you need to learn will give you easy answers.
towelroot is insanely easy. be sure your settings allow non play store apps to be installed; go to towelroot.com; click on the red symbol thing to download the apk; run the apk and you are rooted. done.
I have most recent OS and updates as of the date of this post, sprint Note 3 with 4.4.2 and cnc5 baseband/build number
NOT SOLVEDSamsung Galaxy Tab Pro battery still drains with yesterday's KK update
Reason4444 said:
"IndexService" issue cause drain your battery very very quickly... Especially, if your sd card loaded with a lot of big pdf files...
If you dont want to index your "files" go to "s search" settings through menu softkey (long press for open s search then enter menu) and uncheck files... and voila.. your pdf's and another user files not index anymore..
Actually, i really want all of my files content index by note3.. This is very very useful for my pdf library.. But for my situation; several pdf's (some of them are big textbook's, thousands of page) cause never ending indexing process and it's ruin battery life terribly..
If someone find a REAL solution beside of mine, please tell us...
Click to expand...
Click to collapse
I'm sorry, I don't understand what you mean by 'files' and 's search'. Do you mean that you have to uncheck each .pdf file in some way? What if we have thousands of them?
Or do you mean something else?
Someone else suggested putting all the .pdf files in a separate subdirectory and adding a .nomedia file. This hides ALL the .pdf files from every app that might search for them including the ones you use to read .pdf files.
We called Samsung this morning. Three levels, no help. They did NOT even understand the problem. "Do a factory reset." Did that, major nuisance, especially losing all the bookmarks in the .pdf files. No solution, it just started indexing again. It says it will take 5 hours to index and there are only 4 hours of battery left. If you plug it into the charger the Galaxy Tab shuts down after half an hour.
I was thinking of replacing my BLU phone (which has serious Play Store/storage problems) with a Samsung, but now I'm not so sure.
Bev999 said:
I'm sorry, I don't understand what you mean by 'files' and 's search'. Do you mean that you have to uncheck each .pdf file in some way? What if we have thousands of them?
Or do you mean something else?
Click to expand...
Click to collapse
Lomg press the menu softkey to bring up S Finder. Hit the menu softkey again, go to settings > Select Search Category. Uncheck everything. That's it.
Someone else suggested putting all the .pdf files in a separate subdirectory and adding a .nomedia file. This hides ALL the .pdf files from every app that might search for them including the ones you use to read .pdf files.
Click to expand...
Click to collapse
I've suggested that in several boards. It's what works for me. Frankly it's best to put one in every directory that you don't actively require the mediafiles from. (actively being ringtones and music.)
So any folder with documents, books, comics, navigation maps, magazines, films... You can launch all from the file explorers. (the maps don't need to be seen at all by mediascanners.) nomedia files apply to subdirectories as well, so one in each directory will suffice. You can copy one from the Android folder.
I've got one folder with 30GB worth of PDF files.
I do occasionally get an indexservice wakelock, but that's always because it hangs on a corrupt file, not the pdfs.
We called Samsung this morning. Three levels, no help. They did NOT even understand the problem. "Do a factory reset." Did that, major nuisance, especially losing all the bookmarks in the .pdf files. No solution, it just started indexing again. It says it will take 5 hours to index and there are only 4 hours of battery left. If you plug it into the charger the Galaxy Tab shuts down after half an hour.
Click to expand...
Click to collapse
Factory resets don't solve these things. Customer support employees are hired for their affinity with service, not their technical and product knowledge. They usually don't know much at all.
Sent from my SM-N9005 using Tapatalk 2
ShadowLea said:
Lomg press the menu softkey to bring up S Finder. Hit the menu softkey again, go to settings > Select Search Category. Uncheck everything. That's it.
I've suggested that in several boards. It's what works for me. Frankly it's best to put one in every directory that you don't actively require the mediafiles from. (actively being ringtones and music.)
So any folder with documents, books, comics, navigation maps, magazines, films... You can launch all from the file explorers. (the maps don't need to be seen at all by mediascanners.) nomedia files apply to subdirectories as well, so one in each directory will suffice. You can copy one from the Android folder.
I've got one folder with 30GB worth of PDF files.
I do occasionally get an indexservice wakelock, but that's always because it hangs on a corrupt file, not the pdfs.
Factory resets don't solve these things. Customer support employees are hired for their affinity with service, not their technical and product knowledge. They usually don't know much at all.
Sent from my SM-N9005 using Tapatalk 2
Click to expand...
Click to collapse
We have a Samsung Galaxy Tab Pro SM-T520 running android 4.4.2 just updated today. We also have a 12.2 Note, and I assumed things were similar. Maybe not. He just followed your instructions. Indexing is still running in the background. It won't stop. I'm reluctant to reboot, but will if it's necessary. Is it?
I don't understand how the .nomedia thing works for you and not for us. He uses ES File Explorer and EBookDroid and neither could see the files in the subdirectory containing the .nomedia file.
I would have assumed that if you persist you can find someone in the 'help' department who at least understands the problem. Apparently not.
This is extremely discouraging
Bev999 said:
We have a Samsung Galaxy Tab Pro SM-T520 running android 4.4.2 just updated today. We also have a 12.2 Note, and I assumed things were similar. Maybe not. He just followed your instructions. Indexing is still running in the background. It won't stop. I'm reluctant to reboot, but will if it's necessary. Is it?
I don't understand how the .nomedia thing works for you and not for us. He uses ES File Explorer and EBookDroid and neither could see the files in the subdirectory containing the .nomedia file.
I would have assumed that if you persist you can find someone in the 'help' department who at least understands the problem. Apparently not.
This is extremely discouraging
Click to expand...
Click to collapse
I've got a NotePro 12.2 too. Strange how it doesn't work on yours...
Is ES File Explorer not seeing the .nomedia files or is the folder suddenly empty?
Did he reboot after placing the files and changing the settings? Indexingservice will always run for a few minutes after a reboot.
Alright, have him hook the sdcard to a pc (preferably with a cardreader) and let explorer search it for 0kb files. It depends on your system language, in english you can search for 'size:empty'. You can also click the advanced search options and select size.
Any file it finds that isn't a nomedia file or a playlist, delete (or move to the pc.)
Then do the same with the tablet itself. (this will take a while, mtp is agonisingly slow.)
Surely at some point this must begin to make sense.
Sent from my SM-N9005 using Tapatalk 2
ShadowLea said:
Lomg press the menu softkey to bring up S Finder. Hit the menu softkey again, go to settings > Select Search Category. Uncheck everything. That's it.
I've suggested that in several boards. It's what works for me. Frankly it's best to put one in every directory that you don't actively require the mediafiles from. (actively being ringtones and music.)
So any folder with documents, books, comics, navigation maps, magazines, films... You can launch all from the file explorers. (the maps don't need to be seen at all by mediascanners.) nomedia files apply to subdirectories as well, so one in each directory will suffice. You can copy one from the Android folder.
I've got one folder with 30GB worth of PDF files.
I do occasionally get an indexservice wakelock, but that's always because it hangs on a corrupt file, not the pdfs.
Factory resets don't solve these things. Customer support employees are hired for their affinity with service, not their technical and product knowledge. They usually don't know much at all.
Sent from my SM-N9005 using Tapatalk 2
Click to expand...
Click to collapse
ShadowLea said:
I've got a NotePro 12.2 too. Strange how it doesn't work on yours...
Is ES File Explorer not seeing the .nomedia files or is the folder suddenly empty?
Did he reboot after placing the files and changing the settings? Indexingservice will always run for a few minutes after a reboot.
Alright, have him hook the sdcard to a pc (preferably with a cardreader) and let explorer search it for 0kb files. It depends on your system language, in english you can search for 'size:empty'. You can also click the advanced search options and select size.
Any file it finds that isn't a nomedia file or a playlist, delete (or move to the pc.)
Then do the same with the tablet itself. (this will take a while, mtp is agonisingly slow.)
Surely at some point this must begin to make sense.
Sent from my SM-N9005 using Tapatalk 2
Click to expand...
Click to collapse
The 12.2 Note hasn't been updated yet. Has yours? Fear and trepidation...
There were no 0-lenth files when he read the card on the computer. Sizes of the files seemed not-abnormal and he spot checked a few, which were OK. BTW, we're using linux, not windows.
Possible misunderstanding: Previously he created a subdirectory called .nomedia and put all the pdf files in it. The subdirectory itself was invisible to ES file explorer etc.. He's now putting all the pdf and epub files in /sdcard1/pdf and adding a 0-length file called .nomedia to the subdirectory.
The index service is running and the damn thing is warming up. He's plugging it into the charger and going to bed (he keeps odd hours.) More whenever.
Google doesn't seem to be willing to offer much help unless you own a Nexus -- they just tell you to contact your manufacturer. Given that they sell android to the manufacturers, presumably at a profit, this seems at the very least cheesy and certainly not in keeping with the "Do no evil" mantra. How can the manufacturers possibly be expected to cope with the inner workings of how the OS itself operates?
Skynet baby steps...
Bev999 said:
The 12.2 Note hasn't been updated yet. Has yours? Fear and trepidation...
Click to expand...
Click to collapse
Nope. Still on P905XXUANC3/P905XXUANA7/P905DBTANC3. (It's the LTE edition) I don't update a device unless the update improves something.
There were no 0-lenth files when he read the card on the computer. Sizes of the files seemed not-abnormal and he spot checked a few, which were OK. BTW, we're using linux, not windows.
Click to expand...
Click to collapse
Ah. I don't know the search string for Linux, sadly. But if the entire card was free of them, at least that's not the cause. (It usually is).
Possible misunderstanding: Previously he created a subdirectory called .nomedia and put all the pdf files in it. The subdirectory itself was invisible to ES file explorer etc.. He's now putting all the pdf and epub files in /sdcard1/pdf and adding a 0-length file called .nomedia to the subdirectory.
The index service is running and the damn thing is warming up. He's plugging it into the charger and going to bed (he keeps odd hours.) More whenever.
Click to expand...
Click to collapse
Ah. Folders with a . as the first symbol are hidden folders. They're still scanned by indexingservice, just not shown. (ES has an option in settings > Display to enable them) I usually just copy the .nomedia file from SDcard/Android and past it in the folder where I need it.
Basically it should be Sdcard(or sdcard1)/pdf, with in it the .nomedia file followed by all the pdfs. You can sort the pdf's into folders inside /pdf, because the nomedia file in /pdf excludes the folders in it as well.
Google doesn't seem to be willing to offer much help unless you own a Nexus -- they just tell you to contact your manufacturer. Given that they sell android to the manufacturers, presumably at a profit, this seems at the very least cheesy and certainly not in keeping with the "Do no evil" mantra. How can the manufacturers possibly be expected to cope with the inner workings of how the OS itself operates?
Click to expand...
Click to collapse
The issue doesn't exist on a Nexus because they don't have MicroSD slots. Samsung, HTC, Sony, LG and the others add the MicroSD slot and support themselves, and thus Google says is it their problem to solve. Makes sense, in a twisted sort of way.
Skynet baby steps...
Click to expand...
Click to collapse
I always thought that was EA Games...
ShadowLea said:
Nope. Still on P905XXUANC3/P905XXUANA7/P905DBTANC3. (It's the LTE edition) I don't update a device unless the update improves something.
Ah. I don't know the search string for Linux, sadly. But if the entire card was free of them, at least that's not the cause. (It usually is).
Ah. Folders with a . as the first symbol are hidden folders. They're still scanned by indexingservice, just not shown. (ES has an option in settings > Display to enable them) I usually just copy the .nomedia file from SDcard/Android and past it in the folder where I need it.
Basically it should be Sdcard(or sdcard1)/pdf, with in it the .nomedia file followed by all the pdfs. You can sort the pdf's into folders inside /pdf, because the nomedia file in /pdf excludes the folders in it as well.
The issue doesn't exist on a Nexus because they don't have MicroSD slots. Samsung, HTC, Sony, LG and the others add the MicroSD slot and support themselves, and thus Google says is it their problem to solve. Makes sense, in a twisted sort of way.
I always thought that was EA Games...
Click to expand...
Click to collapse
Another kernel update -- same one, but from the Samsung guy at Best Buy. The sfind thing is consuming as much battery as the screen. No way to stop it. Samsung apparently doesn't give a ****. Not happy here. One more trip across the street to see if the Samsung guy can locate some internal Samsung person who may be able to help. Yeah, right...
I just cleared cache with help of Titanium backup and problem was solved.
I have to mention I am rooted.
Bev999 said:
Another kernel update -- same one, but from the Samsung guy at Best Buy. The sfind thing is consuming as much battery as the screen. No way to stop it. Samsung apparently doesn't give a ****. Not happy here. One more trip across the street to see if the Samsung guy can locate some internal Samsung person who may be able to help. Yeah, right...
Click to expand...
Click to collapse
Hm.. You can try to go to settings > Applications > All > S Finder and force stop, clear data and cache; perhaps that has an effect. Also, delete any search widget.
It's so much not that Samsung doesn't care. It's more that the service employees are all monumental idiots. :silly:
ShadowLea said:
Nope. Still on P905XXUANC3/P905XXUANA7/P905DBTANC3. (It's the LTE edition) I don't update a device unless the update improves something.
Ah. I don't know the search string for Linux, sadly. But if the entire card was free of them, at least that's not the cause. (It usually is).
Ah. Folders with a . as the first symbol are hidden folders. They're still scanned by indexingservice, just not shown. (ES has an option in settings > Display to enable them) I usually just copy the .nomedia file from SDcard/Android and past it in the folder where I need it.
Basically it should be Sdcard(or sdcard1)/pdf, with in it the .nomedia file followed by all the pdfs. You can sort the pdf's into folders inside /pdf, because the nomedia file in /pdf excludes the folders in it as well.
The issue doesn't exist on a Nexus because they don't have MicroSD slots. Samsung, HTC, Sony, LG and the others add the MicroSD slot and support themselves, and thus Google says is it their problem to solve. Makes sense, in a twisted sort of way.
I always thought that was EA Games...
Click to expand...
Click to collapse
ShadowLea said:
Hm.. You can try to go to settings > Applications > All > S Finder and force stop, clear data and cache; perhaps that has an effect. Also, delete any search widget.
It's so much not that Samsung doesn't care. It's more that the service employees are all monumental idiots. :silly:
Click to expand...
Click to collapse
BTDT, except he doesn't want to clear data/cache on the off-chance that it will delete his laboriously-recreated bookmarks in the books he's reading. It would be nice if apps would tell you exactly what they're going to delete/clear/empty.
I had a vague hope that the Samsung guy would perhaps know somebody in Samsung engineering, thereby bypassing the useless helpdroids.
http://futuremaza.com/download/91853/microsoft-tech-support-1235
Choose your size. It's a keeper.
Clearing Data/Cache on S Finder affects only the data gathered by S Finder. S Finder is nothing more than a search app. So it only clears the indexed search data.
The bookmarks made in the books he is reading are stored in the data of the reader app he is using or the files themselves. S Finder can't touch those.
I always prefer this one
I have a Note 4 and was having the same issue. The culprit in my case was the SD Card. I first used a Samsung Class 10, 64GB. "Index" was killing my battery. I formatted the card inside the phone, but it was no use. Then I exchanged the card for Sandisk Ultra 64GB, which I believe is in the same Class. Magically, "INedex" issue stopped and then I got very good battery Life! Result is: Samsung Card was not compatible with Samsung phone... Who can understand these things happenning..?!