## Dealing with a picture frame that freezes.

I recently bought myself a (1920×1080 pixel) digital picture frame, that had rave reviews among other customers, but that began the habit of freezing after about 12 hours of continuous operation, with my JPEG Images on its SD Card.

This could signal that there is some sort of hardware error, including in the internal logic, or of the SD Card itself. And one of the steps which I took to troubleshoot this problem was, to try saving the ‘.jpg’ Files to different SD Cards, and once even, to save those pictures to a USB Key, since the picture frame in question accepts a USB Memory Stick. All these efforts resulted in the same behaviour. This brought me back to the problem, that there could be some sort of data-error, i.e., of the JPEG Files in question already being corrupted, as they were stored on my hard drives. I had known of this possibility, and so I already tried the following:


find . -type f -name '*.jpg' | jpeginfo -c -f - | grep -v 'OK'



Note: To run this command requires that the Debian package ‘jpeginfo’ be installed, which was not installed out-of-the-box on my computer.

This is the Linux way to find JPEG Files that Linux deems to be corrupted. But, aside from some trivial issues which this command found, and which I was easily able to correct, Linux deemed all the relevant JPEG Files to be clean.

And this is where my thinking became more difficult. I was not looking for a quick reimbursement for the picture frame, and continued to operate on the assumption that mine was working as well, as the frames that other users had given such good reviews for. And so, another type of problem came to my attention, which I had run in to previously, in a way that I could be sure of. Sometimes Linux will find media files to be ‘OK’, that non-Linux software (or embedded firmware) deems to be unacceptable. And with my collection of 253 photos, all it would take is one such photo, which, as soon as the frame selected it to be viewed, could still have caused the frame to crash.

(Updated 1/16/2020, 17h15 … )

## The Old USB Key was Most Definitely Defective.

During This Preceding Posting, I had written that today I saw the need to dispose of an older USB Key in favor of a newer one.

With the older Key, for some reason my speed had gone down to USB 1 speeds as well. But I had let it run for a few hours, to transfer a photo album from the computer I name ‘Phoenix’, to the one I name ‘Klystron’. There were roughly 6000 photos, in 200 folders.

After replacing the USB Key, of course the thought had occurred to me, that the transfer itself was suspect. So on ‘Klystron’, I ran a quick preview of the sub-folders. At random, about 1/4 of the sub-folders contained image-files, whose data revealed no images.

And so what I now did, was to repeat the procedure with my new Sony USB Key. It was able to load the images – which take up 7.8GB of storage – from ‘Phoenix’ at USB 2 speeds (20 Megabytes / Second), and save them to ‘Klystron’ at USB 3 speeds (80 Megabytes / Second). Hence, the repeat of that procedure merely required a few minutes of my time. In the process, the USB Key got warm.

Now, it would seem that there is no more corruption in the files, belonging to the sub-folders, as stored on ‘Klystron’.

Yay!

Dirk

## I appreciate Plug-and-Play USB Keys.

I am used to an older time, when the stores did sell customers USB Drives / Keys, which were formatted with NTFS, and which, if we inserted them into our Linux PCs, would not mount. Today, the USB Keys we buy, can in some cases be plug-and-play, with modern Linux computers.

But the gap that once existed here, mainly existed between what a Linux computer could mount from the command-line, and what the desktop manager / HAL daemon was willing to mount, simply because the user plugged it in.

For example, I can perfectly-well format my USB Pen Drive to the ‘ext4‘ file system, but then the desktop manager would not accept that, because to do so would imply a security violation. It would effectively give any user ‘root‘, because any ext4 content could be stored as root, with ‘setiud, and be as the user provided. And yet, with the root password, it would still be possible to mount that…

There is a word of caution I should give fellow computer users though. Whichever computer you are on – be it Windows, OSX, Linux or other – you should still assume that if you mount a file system other than one native to your O/S, it will be mounted without journaling enabled. This means, that we will need to be extra careful, not to pull the key out, without first having done an explicit Safe Disconnect / Unmount.

It is the file system journal which will ensure, that only files are lost or damaged, which we were editing, and if so, atomically altered. Without this in place, we can end up with a USB Key which will only mount again explicitly in read-only mode, which also means that we will need to reformat again, before we can write new data to it. Hence, with no journaling, if the USB Key is pulled out while active, we could lose the whole content – although that is not usually what happens.

And so it could be said that Linux kernels as early as 2.4 had some ability to mount NTFS file systems, it would have been premature to say that those would be fully compatible with the USB Key, as provided, just because the desktop managers did not mount it. Even though they could already be mounted from the command-line.

I guess that the people who configure Linux these days, have figured out, that for their desktop manager to auto-mount an NTFS volume, does not present a security risk.

There does exist a type of NTFS driver under Linux, which will do an NTFS mount, more the way Windows does NTFS. It is called ‘ntfs-3g‘. But the only real purpose of that is to allow the owners of dual-boot laptops, to mount their Windows partitions from within Linux, which remains the only easy way to exchange data between Linux and Windows sessions. ntfs-3g was not meant for USB Keys, nor for automatic service from HAL.

Speaking of which: I just needed to trash a USB Key. I was able to mount it under Linux, and then to save a folder of data to it, which seemed to join the already-present folders in ‘Dolphin‘. But after that, whenever I removed the USB Key and remounted it, all the changes I had made were just gone. It seemed as though they had been cached, and with the cache cleared, the actual mass-storage device did not remember anything. This was accompanied by some very strange error messages, whenever I tried to repair the old key with software tools.

And so at some point I had to acknowledge that either the H/W had to have become defective, or that I had done so much reformatting, that I could reformat the little thing no more. Scientifically, the second option makes less sense, because no matter how many times one reformats the key back to FAT32 finally, its configuration should go back to one that at least works, even if it can only handle up to 40GB total. Mine would not recover into this state.

And it should also have been possible to format it with ‘etx2‘ on one specific Linux computer, to store data on that partition, to remove, reinsert and then remount the key on the same computer, and to retrieve the data. This experiment had also failed, at the point where the key had been remounted but failed to show the new data.

So now I have a brand-new USB key with a capacity for 128GB, which is plug-and-play compatible with my Linux boxes, and which remembers everything I stored on it (Insert Evil Scientist Laugh Here.)

I did not even bother to open it with ‘gparted‘ first, just to satisfy my curiosity. I do not care what FS they used. I just tried plugging it in, and it worked. And my two main Linux machines are on exactly the same build.

I had bought the old USB Key, before this present computer – ‘Phoenix’ – was installed, when its hardware was host to a system I had named ‘Thunderbox’. And Thunderbox was not able, to mount that older USB Key directly.

However, that USB Key was useful to me, in migrating some of my data, around the time that I was reinstalling ‘Aphrodite’ as ‘Venus’, and ‘Thunderbox’ as ‘Phoenix’. The key was formatted with FAT32 and held its data at the time. But what I really wanted today was a full-capacity USB Key, not limited to 40GB.

I would bet, that if I had re-partitioned it with FAT32 using my Windows PC, it would have played its old game with me: Of seeming to store data for a longer time, but then just forgetting it again.

What I needed was a new USB Key, which I now have.

Dirk

(Edit 06/06/2016 : ) I just found out, that what Sony did, was just to format this new USB Key with FAT32.

A part of that which I do not understand, and which contributed to my initial confusion, was my memory to the effect that, FAT32 file systems were once not allowed to be bigger than 40GB. But this is a 128GB stick. I do not understand this.