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 … )

Continue reading Dealing with a picture frame that freezes.

I have managed to make OpenShot more stable under Linux.

In a previous blog posting, I had reported that OpenShot was dangerously unstable, and even unstable under its native Linux. I’m basing this on OpenShot 1.4.3, installed from the package manager under Debian / Jessie, with a KDE 4.14 desktop.

This Was The Posting.

It turns out that there can be ways to overcome this instability.

Firstly, I have changed the Output Mode, with which this application renders its previews, from “sdl” to “sdl_preview“.

More importantly there seems to be a detail in its practical use, which I was unaware of before. Earlier, I had imported a captured .OGG / .OGV file into its video clip resources. In itself this presents a problem, in that certain .OGV Theora files, especially ones produced by screen capture, are known to give this program problems. This can be anticipated, by the video clips in question having blank thumbnails.

On the first try, I told OpenShot to play the video clip anyway in its preview window. The progress bar went from the beginning to the end at the correct speed, but once it reached the end, the application became unresponsive and KDE had to shut it down forcibly. This was with the Output Mode still set to “sdl“.

Apparently, once OpenShot has crashed, it has saved corrupted information into the folder ‘~/.openshot‘ . Had I known this, I could have deleted that folder completely before trying out the application again. But instead I tried to use OpenShot again right away, sometimes telling it to play the .MP4 version of the same video or other clips.

That was when my desktop froze. The X-server did not crash, but no movement or mouse input could be given anywhere on the desktop. The actual mouse pointer was still moving in response to the mouse however, and it was also changing from the usual pointer, to the special pointer when hovering over the preview panel. I needed to use <Ctrl>+<Alt>+F1 in order to open a Virtual Terminal in text mode, and then to ‘kill -9‘ the actual application pinning the other virtual terminal.

My setups typically allow for multiple sessions to be logged in at once, and Virtual Terminals 1-6 are text-based, while the graphical ones start from Virtual Terminal 7. So once the offending processes were killed, I was able to <Ctrl>+<Alt>+F7 back into the graphical session, which was not corrupted.

But the way I finally broke this spell with OpenShot, was to delete the directory ‘~/.openshot‘ and its corrupted contents. After that, the application was able to play the .MP4 video clips fine, which also had thumbnails that corresponded to their content.

Also, if I decide that a user-space configuration is needed to ensure the stability of the system, I copy the contents of the configuration folder for one application, into ‘/etc/skel‘, from where a skeleton of starting files is copied, every time the home directory of a new user is set up. That way, any newly-installed user will inherit my recommended settings.

In order to do that, after I deleted the config folder once, I only launch the application briefly, and make my configuration settings, before exiting the application again immediately. At that point I feel that the config folder is in its correct state, to be copied to ‘/etc/skel‘ .

There are certain purposes, which OpenShot may be better able to suit than alternatives, simply because OpenShot has more features.

Dirk