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

So, what I decided to do next was, to use “ImageMagick” from the command-line, to convert every ‘.jpg’ File under a certain folder, to another ‘.jpg’ File with the same size as the first, but with a Quality set arbitrarily to 95%. The effect this would have is, to force re-encoding all the ‘.jpg’ Files, so that either all of them would cause the picture frame to crash, or that none of them would do so. Then, I saved the resulting, re-scanned JPEGs to one of the SD Cards, and relaunched the picture frame.

To my amazement, the picture frame never crashed again.

And so, in keeping with my habits, I will share the script with the readers, who might also be Linux users, that will re-scan arbitrary sub-directories recursively, and which seemed to do the trick for me:

 

#!/bin/bash

# JPEGs_Uniform.sh
# Make a whole folder of .jpg Files as conform as Linux will allow.
# Created January 16, 2020 by Dirk Mittler.

# Uses ImageMagick for its legacy 'convert' command (replace as required).

CONVERT='/usr/bin/convert'
VERTICAL_RES='1080'

# User-configurable parameters end here.

if ! [ -x "$CONVERT" ] ; then
    echo "ImageMagick either not installed or not found at ${CONVERT} ."
    exit 1
fi

if [ "$USER" == "root" ] ; then
    echo "Command may not be run as root!"
    exit 1
fi

if [[ "$PWD" =~ ^${HOME}/ ]] ; then
    
    MAX_W=$((VERTICAL_RES * 16 / 9))
    MAX_H=$((MAX_W * 2 / 3))
    FRAME="${MAX_W}x${MAX_H}"
    echo "Images must fit within: ${FRAME} pixels."
    COUNT='0'
    
    find . -maxdepth 2 -type f -name '*.JPG' -exec bash -c 'mv "$0" "${0%.JPG}.jpg"' {} \;
    find . -maxdepth 2 -type f -name '*.jpeg' -exec bash -c 'mv "$0" "${0%.jpeg}.jpg"' {} \;
    
    if [[ "$1" =~ ^-{1,2}[Rr] ]] ; then
        
        echo "Removing original images as ordered..."
        COUNT=$(find . -maxdepth 2 -type f -name '*.jpg' ! -name '*_bc.jpg' -exec bash -c \
        "${CONVERT}"' -quality 95% "$0" -resize '"${FRAME}"'\> -type truecolor "${0%.jpg}_bc.jpg" \
        && rm -f "$0" && echo "-"' {} \; | wc -l)
        
    else
        
        echo "Keeping original images. Use --remove flag to remove..."
        COUNT=$(find . -maxdepth 2 -type f -name '*.jpg' ! -name '*_bc.jpg' -exec bash -c \
        "${CONVERT}"' -quality 95% "$0" -resize '"${FRAME}"'\> -type truecolor "${0%.jpg}_bc.jpg" \
        && echo "-"' {} \; | wc -l)
        
    fi
    
    echo "${COUNT} Images were rescanned."
    
    exit 0
    
else
    echo "Presently not beneath home directory!"
    exit 1
fi

 

Some observations about this script:

  • With the interests of my readers in mind, I have refined my script above, so that the command must be given while the terminal is in the parent directory to run from, but to follow that command with ‘--remove‘, ‘-r‘, ‘-R‘ or the like, will actually signal that the original file is to be deleted – as long as ImageMagick reported being able to convert it.
  • The ‘find’ command in the present version will only scan one level of sub-directories deep, in search of entries, i.e. .jpg Files, to modify. This is intended as a safety feature, since, to run the command from a very high-level folder in the hierarchy of the user’s personal files, would otherwise have as consequence that a very high number of sub-directories would be scanned, which is most likely not intended.
  • When I was troubleshooting the picture frame, a set of suspect images existed within a subfolder with 6000×4000 pixel content. As a separate action, I shrank those to 1920×1280, keeping their 3:2 aspect ratio. This -frame is capable of cropping them automatically to 16:9. It was my thinking that the frame might be buffering several images at a time, so that the coincidence of having buffered maybe 4 images at 6000×4000, could have provoked each crash,? Similarly, I verified manually that all my JPEG Images were in ‘sRGB’ colour space, not Grey-Scale. But because I’d want my reader to benefit from the same analysis, I have included those steps in the version of the script shown above.

 

Enjoy,

Dirk

 

Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.