Here's what I sent the B&N forum moderator tonight:
Quote:
I don't know if you have seen my posts in the "[N1E]: 1.7 Update" thread, but here's some summary information I think you requested of someone else:
N1E (Wifi+3G) sideload-updated to 1.7:
Internal memory has just two small eBooks (no other documents) totalling 13MB.
SanDisk 16GB class 4 microSD card, containing about 45,000 PDF files in about 9,000 directories, occupying 7.7GB.
At this point in what I describe next, my documents in the SC card's "root" directory are visible in "My Documents", along with the "User Guide" and "Tour" (which of course are on the internal memory). The 45,000 document in subfolders are not visible (and I don't want them to be), because I have a ".nomedia" file at the head of the subdirectory tree with those documents.
After connecting the N1E to my PC, and then "ejecting" both USB drives without making any file changes:
* It took 4.5 minutes for the internal memory card to be mounted, after the usual scan.
* It took 8.5 minutes for the SDcard to be mounted and available, after the usual scan.
Before each scan is complete, the "Settings" page report each memory card to have 76MB available out of 242MB. After the scan is complete on each memory card, the reported sizes are correct, and my documents in the SC card's "root" directory are still visible in "My Documents".
Rebooting (holding the power button for five seconds) takes just under two minutes to reboot, and the documents on the internal memory are immediately visible. However, the "Settings" page shows the bogus size values for the SD card, until 9.5 minutes have elapsed after reboot, at which point the reported sizes are correct. At this point attempting to view "My Documents" gives the "Checking for New Items -- This will only take a moment" pop-up, which sits there for an hour.
During that one hour, I checked with adb, and no CPU process was consuming any CPU time. I canceled the "Checking for New Items" and checked settings, and the reported sizes are still correct, but my documents on the SD card are no longer visible. A "Check for new content" simply gives the "Checking for New Items -- This will only take a moment" pop-up.
Doing a hard-reset (this time holding the power button for twenty seconds) takes just under two minutes to reboot, and the documents on the internal memory are immediately visible, just as before. However, the "Settings" page shows the bogus size values for the SD card, until 9.5 minutes have elapsed after reboot, at which point the reported sizes are correct, but my documents on the SD card are still not visible. At this point attempting to view "My Documents" gives another "Checking for New Items -- This will only take a moment" pop-up, which I immediately canceled this time.
I'm going to try to go back to 1.5 -- I've spent enough time testing what B&N should have done before releasing 1.6 and 1.7.
By the way, the 45,000 PDF files in 9,000 folders on a 16GB SD card WORKS PERFECTLY WELL ON THE NOOK COLOR.
|
UPDATE: It appears that rebooting causes the problem, and a USB mount/umount to a PC SOMETIMES cures the problem. In other words, the SD card mounting code in the reboot sequence is missing some of the code that is in the USB dismount sequence.
Even if that were fixed,
nine minutes to remount a 16GB SD card is
unacceptable. The program taking all the time is "/system/bin/dosfsck" (file system check of a FAT partition). Why on earth does that have to be done on every mount??? Answer: In a normal Linux system, no one does that; filesystem checks are performed on a low percentage of mounts. I have 16GB SD cards with identical file content in the NookColors, and they don't have this problem.
So, I went back to v1.3, tested, upgraded to v1.5, tested, and then upgraded (again) to v1.7.
All of those versions (all tested stock, not rooted) have the long delay when mounting or remounting an SD card with the number of files I have. However, v1.3 doesn't seem to have the problem of "missing" documents after a reboot, but v1.5 and v1.7 do. I didn't do exhaustive testing with v1.3, so it's possible this problem has been there from the beginning.
So, there appears to be
no regression from v1.5 to v1.7 in this respect.