Although any Pi can be used, one of my goals was to achieve the lowest possible cost. This makes the Pi Zero the ideal choice (or the A+, if you can't get a Zero)

Mk2 PhotoFrame setup

I recommend staring with a 4Gb SDHC card and 'building' your system, Once it's working, plug the card back into your PC and make a 'disk image' using Win32Imager. You can then 'burn' that same image to as many 8Gb cards as you like

You might as well use Win32 Disk Imager (which reads every block) because the Pi system system always auto-resizes to the last block on first power-on.
If you do stop the Pi auto-resizing (and modify the resize command to 95% of the space instead of 100%), you will need to use something otehr than Win32 Disk Inager to make the back-up (see my Backing up your Pi page

Use Jessie, not Stretch

After wasting hours with Stretch trying to get 'fbi' to 'launch' at power-on, I eventually gave up and went back to Jessie.

In addition to refusing to 'launch' fbi at power on, Stretch refused to 'recognise' my USB Ethernet 'dongle' during power-up (I had to wait for it to finish the power-ip sequence and then plug it in).
No only did this waste huge amounts of time, but it meant I couldn't power the Pi via PoE (except by adding a time delay between Pi power on and 'dongle' power-on)

Start by downloading '2016-05-27-raspbian-jessie-lite.img' as a ZIP from the Pi Foundation website (it's not on 'public display' = you have to Google to find the download page). I used 7zip to unpack the 300Mb ZIP file and then 'burnt' the resulting 1.3Gb unpacked image to a 4Gb SDHC card using Win32 Disk Imager (Win32DiskImager-0.9.5-install.exe, from SourceForge).

WARNING - Win32 Disk Imager is quite capable of wiping a USB 'back-up' drive == so NEVER EVER write SD card images if your back-up drive is plugged in !
I use Windows XP and Win32 Disk Imager (a 32bit application) works just fine for me. If you are using (64 bit) Windows 7, just make sure to both install and run Win32 Disk Imager as Administrator. If you are using any other (64 bit) Windows, success may prove elusive (and back-up drives wiped) :-)

Before booting the Pi

On your PC, you should be able to 'open' the FAT32 partition of the SD card (in Jessie this was 63Mb, Stretch reduces it to 42Mb, however that should still be plenty for both all the scripts and a good number of (pre-sized) photos)

1) Start by adding a file named ssh (the Pi won't let you 'log in' across the network if this file is missing)

2) Prevent auto-resize (optional)

Both Jessie and Raspbian Stretch Lite make things difficult for those of us wishing the back-up and restore by auto-resizing on first power on. However if you are starting with a 4Gb SDHC, you can let it resize (you will have to restore to an 8Gb card)

The silly trick of expanding to use every last block can be prevented by modifying the SD card on your PC before moving it to the Pi. On your PC, you should be able to 'see' the FAT32 (/boot/) partition, so 'open' the card and edit the cmdline.txt file found in the root FAT32 partition to remove the " init=/usr/lib/raspi-config/init_resize.sh" text
This will prtevent the auto-resize, which gives you a chance to modify /usr/lib/raspi-config/init_resize.sh (so it only uses 95% of the space).

Rather than muck-around with init_resize.sh, I just start with a 4Gb SD card and let Raspbian resize. After I have the PhotoFrame running, I take a 'back up' (image) the card and 'restore' to an 8Gb card later.

3) Prevent Display auto-blanking

The Pi will 'auto-blank' the display after 15 mins. To prevent this, modify the /boot/cmdline.txt file (/boot/ is the FAT32 partition)

In the single line of text, add the command :-
consoleblank=0(note: commands in /boot/cmdline.txt are seperated by spacesNB. The 'official' way, in Jessie, to stop the Pi blanking the CLI screen, was to modfiy /etc/kbd/config by adding :-
BLANK_TIME=0
BLANK_DPMS=off
POWERDOWN_TIME=0
However, in Stretch, the file /etc/kbd/config no longer exists :-)

Once again, let me stress - when you get it working, DON'T CHANGE ANYTHING. That means NO UPDATES and especially NOT USING A NEW OPERATING SYSTEM !

When the Pi first released, I have spent many hours of painful experimentation getting things to work reliably in Wheezy.
When Jesse was released, my 'learning curve' went back to zero - things that used to work, no longer worked. However I slogged on and eventually learned to love Jessie.
I then made the mistake of switching to Stretch and discovered a whole new level of pain = not just the loss of 20Mb of FAT32 space but (see below) Stretch also fails to work with my PoE (Power-over-Ethernet) Pi Zero !
Lucky I had backups of my working Jessie systems - so I was able to dump Stretch and start with a known working system.
In short - whatever System 'image' you start with, make sure to hold multiple back-ups !

4) Set the display resolution

The HDMI-VGA converter will stop the Pi from 'detecting' your display, so Raspbian Jessie / Stretch defaults to 'half HDMI mode'. It's not a bad idea to set your actual display size now (so you can just forget about it)

Edit config.txt to set the display resolution. For 4:3 1600x1200 at 60Hz (the best the Dell 2001 can support) :-

hdmi_group=2
hdmi_mode=51

For 1280x1024, 60Hz, it's hdmi_mode=35

5) Load pre-sized photos into the SDHC card

On a Jessie system, you have about 62Mb of free space in the FAT32 partition (on the Pi, this is '/boot/). I recommend creating a sub-folder for the thuimbs (eg 'photos')
A typical 1280x1024 .jpg thumbnail photo will be about 350kb, so you can store about 180 photos (1600x1200 thumbs will be a little larger, perhaps only room for 150)
On stretch, you have about 41Mb free, so room for only 100 - 120 thmbs)

In order to avoid 'mixing up' the thumbnails with full-sized jpg's, I suggest changing the file 'type' from .jpg to .thumb (or similar)

Stretch and Pi Zero PoE

The Pi Zero has no directly connected Ethernet, however at power on, it should detect the display USB hub and find the Ethernet 'dongle'. When it 'spots' the Ethernet it will launch a DHCP Client. If all goes well, it wil get it's TCP/IP settings from your Router. If not, then it will generate a random' address in the 169.254.x.x range. Near the end of the boot sequence you will see whatever IP address the Pi has decided upon.

IN THEORY you can set a 'static' IP in the cmdline.txt file found in the root FAT32 partition. HOWEVER this will ALWAYS be over-written when the DHCP Client is run (and the Pi runs DHCP Client everytime it 'sees' an Ethernet cable being plugged in) :-)
Unfortunatly, to make things even worse, Raspbian Stretch seems to run DHCP before the USB 'dongle' is fully powered-up. As a result, it will always fail to find an IP at power-up == you have to reboot the Pi to get a Router issued IP address == which then means you can't use PoE ...

After booting the Pi

On your PC, use 'PuTTY' to open a 'ssh' Command Terminal window. This allows you to access the Pi after the main graphic display (HDMI socket) 'locks up' (which is does when 'fbi', the photo display app. is run)

Log in as user pi, password raspberry

The 'pi' user has so few permissions that almost every command you type has to be 'prefixed' with 'sudo'. To fix this, type :-
sudo su

1) Many on-line guides will suggest you start by 'updating' the just installed system. DON'T DO IT. If you make the mistake of 'updating', later, when you have to start again, the list of 'updates' will have changed ... so each time around you will GET NEWER UPDATES and thus never be able to 'reproduce' the exact same system

Instead, get the absolute minimium you need. In this case, it's the photo display app. fbi and the app. to create thumbnails, imagemagick.

Using fbi

'fbi' can't be run in the background and will 'lock up' the graphics display when it is run. Start by testing if the .thumb's can be 'seen' and if you have set the correct display resolution etc.

Assuming you have placed the (pre-sized) photos into a subfolder ('photos') on the FAT32 partition, you can manually check if all is working by logging in, switching to 'su' and typing :-
fbi -T 1 -noverbose -nocomments -readahead -blend 2 -t 3 -u /boot/photos/*.thumbAt this point the graphics display locks up and your photos shpuld display OK. If not, you might hgave to pull the power-plug to get the display back :-)
NB. '-T 1' means 'use Graphics Display 1'. If you don't specify, then fbi will 'abort' with 'display error' when it tries to show the image on the text-only SSH command terminal :-)

Once fbi tests OK, you can 'auto-launch' fbi on each boot-up. To do this, you create a script to run fbi and then add the script to the end of rc.local (just above the 'exit 0'). Remember, fbi will 'lock up' when it's run, so if you added it to the end of rc.local, the boot process would never complete :-)

Controlling the 'photo advance' timing

To control the photo-advance, we add a push-button which is 'sensed' by the scripts. When the button is held down, photo-advance is paused. To ensure a 'clean' transition, we have to 'cheat' fbi using file 'alias'

Note. To avoid the 62Mb (41Mb) limit, instead of placing photos in /boot/ (the FAT32 partition), I create a new /photos/ folder in the (expanded) Linux partition. I then 'share' this folder with my PC (using SAMBA) and use it to hold the .sh scripts. This makes it easy to keep copies of the all the files

The scripts

In keeping with the 'get it going then improve it' approach, I started by just running fbi with whatever was found in some folder (/photos) on the SDHC card.

To make it easier to develop scripts, I always install SAMBA. This not only makes it easier to see what's happening in the Pi /photos folder during debugging, but also lets me edit the scripts directly on my PC using Notepad++ (rather than the much more restrictive 'nano').
Finally, once I got a script going, it was simple task to backup a copy of the working version to my PC

I based my new scripts on my old Photoframe script that started with a dir listing, then stepped through the list one file at a time setting each to display in turn and checking in case the 'pause' button was pressed before moving on

I created 3 scripts, 'set-photo' to choose the next photo from the /photos folder, 'get-photos' to fetch and resize new photos from USB to /photos and 'go-photoframe' to pull it all together.

Place all 3 scripts in the /photos folder and make them executable :
sudo chmod +x /photos/go-photoframe.sh
sudo chmod +x /photos/set-photo.sh
sudo chmod +x /photos/get-photos.sh
Add the go-photoframe.sh to the file /etc/rc.local so it launches on boot-up :-
sudo nano /etc/rc.localadd at the end :-/photos/go-photoframe.sh
Then reboot and the PhotoFrame will start running :-
sudo reboot

You can download all 3 scripts mentioned above (as a zip), right click and 'Save Link As' from link: mk2-photoframe.zip = and that's it !

For detail on how each individual script 'works', continue to read below :-

How the scripts work

This script looks for new photos on the USB stick or your Media server/NAS and, if any are found, copies a thumbnail version to /photos. It's only needed if you want to update the /photos contents = the PhotoFrame will run just fine without it.
For more details, click to expand the note below :-

How the get-photos script works

This script finds new photos, resizes them and saves them to the /photos folder.
The script is 'optional' i.e. you only need to use it if you want the Pi itself (rather than a Samba attched PC) to update the /photos folder. This means it doesn't do anything 'vital' for the operation of the photoframe
It's main function is to generate thumbnail photos to the exact display size (if you let fbi do your resizing, you are asking for trouble).
First, fbi often gets landscape photo's 'wrong', 'croping' them into a 'square' aspect ratio, although (oddly) 'portrait' photo's are always scaled correctly.
More to the point, fbi will be rescaling each of the 3 'different' images 'on the fly', at 1 per second, which not only wastes power but also takes longer than the 1s 'allowed' for each to be displayed
Finally, saving a copy of the 'full resolution' photo is pointless = it's 15-20x more efficient to save only the exact correct size (1200x1400 jpg's are about 3 a Mb, whilst 16Mpixel camera jpegs are about 5-6Mb each)
The get-photo script uses ImageMagick 'convert' to generate (and save) a (correctly) pre-scaled thumbnial of each new photo to fit the display.
Note. ImageMagick is installed (if needed) by the go-photoframe script before this script is launched

Actual operation

Version 1 only checks USB sticks (and not mapped Media server folders) and over-writes any file of the same name.
Operation is as follows :-
1) Wait for a USB stick to be inserted
2) Turn on the Loading LED (pull some GPIO pin Lo)
3) Copy/resize all .jpg's in the 'root' to /photos/
4) Turn off the Loading LED (release GPIO pin)
5) Wait until the USB stick is removed
6) Loop back to top
Unused GPIO pins that could be used for the LED are : BCM17 (pin11), 27 (pin13) or 22 (pin15). Gnd can be found on pin9 and 3v3 on pin17.
To activate the LED, the GPIO line will 'pull Lo', so we need 3v3 (pin17) to power the LED and thus BCM22 (pin15) is the 'nearest choice'.

Note.
The LED is 'on' when photos are being copied from the stick (so user doesn't remove USB stick)
The same LED is used as a 'feedback' (key click) indicator for the iR remote control.
After creating any new script, don't forget to make it 'executable' :-)
sudo chmod +x get-photo.sh
This note last modified: 17th Nov 2017 17:29.

This script chooses the next photo and copies it from the SDHC /photos folder to one of the two bufferX.jpg files on the RAM disk (tmpfs). It then 'switches' the alias (after the copy) to ensure a 'clean' transition from the current photo to the next.
For more details, click to expand the note below :-

This script launches the other two in the background, sets up the 'alias' files and ends by launching the fbi utility (which then 'locks up' the command terminal whilst fbi is running).
For more details, click to expand the note below :-