The software
As usual, what you need depends on what you want to do !
Many 'NOOBS' users will go straight for the GUI (startx) .. however instead of 'photo-frame', that means we have a computer with a 'screen saver' to program. For me, the problem of a GUI is it's complexity - my experience with a PC based Photoframe convinced me that there would always be 'something' that prevented the display running 'as it should' (and tracking down the 'something' can be next to impossible)
So I started by running (testing) everything from the command line interface (CLI), after which the commands were 'transferred' to a simple Bash shell script. As usual, of course, nothing was ever as simple as it should be (for one, to allow the Bash shell script to be 'launched' after a power-up sequence, it must be 'executable' (chmod 775 or +x), and second, if you want to keep things 'simple', the script should be in the same folder as the images you want to display).
After looking into various command line display utilities (see at end, below) I eventually discovered that the simplest (fbi) was the only one that could be 'convinced' to do the job
Using samba (and finding folders)
One 'feature' for *nix systems is that each 'logged in user' has their own 'home' directory (just like in Windows you default to your own desktop).
This is fine when multiple users are doing multiple different things, but a REAL PAIN when you are trying to get the scripts you setup in your 'home' to launch at power-on (when 'home' = system) and then find photos in some other (hopefully 'fixed' folder) The 'secret' is to make ALL new folders fixed 'off the root' (for example "mkdir /photos/" and NOT "mkdir photos/") and place the scripts and photos in them, and not in your 'home# directory
Needless to say, everything is a lot easier (testing, modification, loading photos, backup etc) if the 'root' of your photoframe directory 'structure' is 'visible' from your PC
This means installing 'samba', which allows a Pi directory (and everything in it) to be seen as a 'mapped network drive' on a PC
(+) Installing samba - (the Pi as a Network Share on your PC)
Using a 4Gb SDHC card
The 'easy' way to 'back up' a Pi is to 'image' the contents of the SDHC card to a file on your PC using Win32 disk Imager - and then 'write' that out to a new card that's 'double the size'
To 'restore' a back-up to the same sized card usually means 'shrinking' the Pi partition sizes and making a new backup - it's possible but a right pain - for details, read the Note below :-
(-) How do I change the Pi System partition size ?
Changing the Pi system partition
The 'standard' Pi Wheezy (v3.18) is a 0.9Gb zip download that expands to a .img of about 3.2Gb. Jessie (v4.1) is a 1.4Gb .zip download that expands to a 3.8Gb .img. Jessie Lite (v4.1) is a 375Mb .zip that expands into a 1.4Gb .img (both boot straight into the GUI). NOOBS 1.5 standard is a 1.0Gb zip that expands to folder of approx Gb, whilst NOOBS Lite zip (and folder) is less than 30Mb. NOOBS Standard includes the Jessie system, whilst Lite contains no system images. On first power-up you choose a system and the Pi then downloads what it needs from the web (although that's usually slower than using a PC). NOOBS 1.5 also consists of 5 partitions, so it's a right royal pain to change anything - avoid it like the plague. If you have to use it, DO NOT 'expand partition' (or you can forget about moving the drive image to another 'same sized' SD card). For most 'stand-alone' projects, I would recommend using NOOBS Lite (30Mb) to select one of the minimal system images, although in many cases Jessie Lite is likley all you need (so download it once and 'burn' it multiple times). When you 'burn' a .img, that sets the actual partition size, irrespective of the nominal SD card size. So, after plugging you SD card into the Pi, on first boot you will need to 'expand the drive' to make use of the free space = if you don't, you won't have enough room to load all the software you need, let alone anywhere to put your project files (images for display, camera recordings etc.). NOOBS diffrs in that you format the SD card to exFAT (using SDFormatterv4.zip SD card formatter) on your PC, then 'drag and drop' the NOOBS folder to the SD card. Note for the Pi Zero, you need the Jessie 4.1 (or later) or NOOBS 1.5 (or later). Neither NOOBS 1.4 nor Wheezy work on the Pi Zero. Of course the Pi Zero has no Ethernet connection, so, if you use NOOBS it must be the 'full' version (not Lite) and when presented with the 'system choice' on first boot, the only 'option' that's going to work is Raspbian Jessie (GUI). This is because Raspbian Jessie is included (as a 'zipped' package) in the NOOBS image, whilst the other 'system choice' options require the downloading of the selected system images from the Internet On first launch, a newly copied 'Wheezy' will offer to 'use all available space' - DO NOT ALLOW IT TO DO SO - if you do, chances are you will never be able to back-up and restore to the same sized card again ! Fortunately, the Jessie (GUI) system root partition is 3.6Gb, so you already have a decent amount of free space (and are already making use of 'most' of a 4Gb SD card), so there is less need to change the partition size. The Jessie image boots straight to the (single user) GUI and assumes you have a HDMI monitor connected (even if it can't detect one). If you want the (multi-user) CLI, you need to edit the system control settings (sudo systemctl, set-default multi-user.target)
How changing the partition size works
To change the system partition size, you actually 'delete' the existing partition(s) tables and 'recreate' them 'in RAM' before 'committing' the changes (and rebooting). Needless to say, get it wrong and you loose the whole system ... The Jessie (and final version of Wheezy ?) distribution image has the usual 'boot' (/dev/mmcblk0p1) and extended (system) partition (/dev/mmcblk0p2) but may also include a 'swap file' partition (typically /dev/mmcblk0p5, but may be /dev/mmcblk0p3), which is used for 'virtual memory' (in much the same way as Windows). The 'swap' partition is typically contained within the 'extended' (system) partition (but ends at the same place as the end of the extended partition) WARNING - the start of the replacement system partition tables MUST reference the same physical 'block number' as the original partition tables (his is because the actual data won't be moved). Of course the start of the 'swap partition' (which would have started after the end of the original system partition) will have to move Launch fdisk and use the 'p' command to view the existing partition numbers and sizes :-
sudo fdisk /dev/mmcblk0
p
Note that the 'start', 'end' and 'blocks' count values are in 'sectors' of 512 bytes each (so, for example, a '4 GB' SD card = about 4,000,000,000 bytes or about 7,612,500 sectors (actually, up to 50MB or about 100,000 sectors less).
Below assumes system is '2' (mmcblk0p2).
If the swap partition ('3' ot '5') is 'contained' within the extended/system partition, just Delete partition 2 (this also removes the swap partition). If not, Delete the swap partition first and then the system.
Command (m for help): d
Partition number (1,2,5, default 5): 2
Partition 2 is deleted
Recreate partition 2 as a 'primary' partition. WARNING = the recreated partition MUST START at the exact same black number as the original WARNING = DO NOT accept the 'default' end count .. leave about 50Mb (100,000 sectors) 'free space' per '4Gb' card size (i.e. 50Mb for 4Gb, 100Mb for 8Gb, 200Mb for a 16GB card) if you want expect to ever 'copy' the SD card using a 'cloning' process (such as dd) to the 'same sized' card Type 'n' to create a new partition, 'e' for an Extended partition, then enter the SAME START value as the original partition (it should be the same as the default i.e. first sector of the now 'empty space'). For the 'end' value (of a 4Gb card), enter the SD card size MINUS 100,000
Command (m for help): n
Partition type:
p primary (1 primary, 0 extended, 3 free)
e extended
Select (default p): e
Partition number (2-4, default 2): 2
First sector (186368-61863935, default 186368):
Using default value 186368
Last sector, +sectors or +size{K,M,G} (186368-61863935, default 61863935):
Using default value 61863935
Partition 2 of type Extended and of size 29.4 GiB is set
Use the "w" command to write the new partition table and then exit fdisk (q command) and reboot (sudo shutdown -r now)
Command (m for help): w
Command (m for help): q
sudo shutdown -r now
After rebooting, you must update the system file directory so it 'sees' the new end of partition. To do this, we use the "resize2fs" command :-
sudo resize2fs /dev/mmcblk0p2
To check the new size, you can use the "df -h" command
sudo df -h
This note last modified: 17th Sep 2016 08:09.
Since I'm going to use a cheap Class 4 8Gb card for the final Photoframe Project, starting with a 4Gb card avoids all that partition size issues
After you copy the 4Gb image to an 8Gb SDHC, boot the 8Gb and run the init_resize.sh script :- sudo init_resize.sh (this will 'auto-resize' the 4Gb partitions to the new 8Gb card)
Using fbi
The 'Frame Buffer Interface' program (fbi) has one major shortcoming = it can't be run as a background task (and can't even be 'launched' from a background running script).
When fbi is launched it 'grabs focus' i.e. runs in the foreground, preventing a script from executing any other instructions, until it has finished displaying all the images you specify. For a photoframe, the obvious approach is to tell fbi to display photos 'for ever', in which case fbi will 'lock up' your command terminal window preventing that 'terminal session' being used for anything else. The other problem is (of course) that fbi only shows the images that were present when it is launched (so you can't update a 'running' slideshow) If, on the other hand, you tell fbi to display images 'one at a time' (so you can update), there will be a very visible 'gap' between images. When fbi is run 'one image at a time', after showing the 'one image' it switches the display back to the CLI terminal window before allowing you to launch it again to show the next image. Worse, fbi appears to have some sort of 'memory leak', since, after showing only a few dozen images 'one at a time' (on Wheezy) it filled up all the RAM and crashed the Pi ! Of course you can tell it to 'run for-ever' and then 'kill' fbi (and re-launch it) in order to update the photos - however whilst that may 'fix' the RAM leak, the display still reverts to the 'terminal session' (boot status text), plus, after a 'kill', an on screen 'Oops: terminated' complaint, all of which is very noticeable :-)
In the end I gave up and just designed the system so fbi could be launched last and run in 'loop for ever' mode. This meant 'cheating' fbi in order to 'update' the display
The trick is to let fbi 'loop for ever' showing a 'fixed' sequence of a few photos and then 'swap them out' by 'overwriting' them with new ones. This (the swap out) can be done by using a second script running 'in the background'. It turns out that this only works if you start fbi with AT LEAST 3 photos (with 2, fbi just pre-loads them both into RAM - despite the use of the '-cachemem 0' option - and thus never picks up the new file contents, however with 3 (or more) fbi will actually fetch the 'next' photo from the (SDHC card) each time). The really clever bit is to use 'alias' links, so you can give fbi 3 'fixed' file names that all 'point' to the same 'real' image file. A script running in the background can then update the photoframe image by changing the single 'real' image file that all the 'alias links' are 'pointing at' (instead of having to work out 'which one' to change next) This has the advantage that there are no 'gaps' between images, and, so long as the 'fbi 'cycle time' is short (3 seconds is about the minimum) 'updates' will appear quickly (in 1/3rd the cycle time)
The final trick is to avoid wearing out the SDHC card directory by holding all the 'alias' files in a ram-disk (tmpfs).
Downloading the scripts
To download the fbi script, right click and 'save link as' go-fbi.sh script (Note 1).
Further details can be found below :-
To download the 'companion' background script, right click and 'save link as' go-photo.sh (Note 1).
Further details can be found here :-
Note 1. If your don't 'Right click' to save the .sh scripts, you will get 'File not found'
Auto-running the scripts
So the Photoframe starts up automatically at power-on, just add your scripts to rc.local, the list of the 'things to be done' at power-on
cd .. cd .. cd etc sudo nano rc.local If you placed the scripts in the /photos/ folder, add the following directly above the 'exit 0' line :- bash /photos/go-photo.sh & bash /photos/go-fbi.sh
Don't forget the '&' after go-photo.sh, so it runs in the background :-)
Alternatives to fbi
Before I managed to get fbi working the way I wanted, I tried a number of other utilities (with even less success) :-
(+) Other display utilities
Next I add a GPIO sensed 'button' to control the Photoframe 'display of the next photo