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)
As with everything *nix, it seems command and component names change with every new System release. Most of the guides you will find are based on the Raspbian Wheezy and NOT the 'latest' Raspbian Jessie - and the fact is, what 'works' with Wheezy does NOT work with Jessie. Since you must have Jessie for the Pi Zero I focus on Jessie ONLY.
NB. to check which Pi OS version you have, type "uname -a" at the command prompt. If you get something like 'Linux raspberrypi 4.4.11+ ..." that's Jessie (yeah, well, just like everything else in the *nix world you didn't think the OS would identify itself with anything as obvious as 'Jessie' did you ?)
Sharing a folder using samba
To 'push' data from the PC to the Pi across your LAN, you need to set up a 'share' on the Pi that can be 'mapped' from your Windows PC. This can be a real pain as it involves installing samba on the Pi First ensure your Pi has the most recent list of the available 'update' packages :-
sudo apt-get update
Next, get and install the samba package :-
sudo apt-get install samba samba-common
Even if you have a 'direct' connection to the Internet (i.e. the Pi is plugged into your Router LAN directly, and not via ICS) it's still possible that one or more of the 'packages' will fail to download (or for the install itself to fail), so pay attention to the status reports that appear on the Terminal command line. If the packages partially download, just type 'sudo apt-get install samba samba-common' again If you get continuous "Could not resolve 'mirrordirector.raspbian.org'" errors, see at end of this note
Setting the samba user
Samba has it's own list of valid user accounts. To add 'pi' to the list of permitted samba users :-
sudo smbpasswd -a pi
If you get 'command not found' then samba has not installed correctly, so revisit 'Installing samba' above (retype 'sudo apt-get install samba samba-common')
Setting up a folder to share
Typically, you will be setting up a new folder on the Pi to 'share' with the PC (or you can just share (all) the existing ones - see later). To set up a new folder eg 'photos' :-
sudo mkdir -m 777 /photos
The -m 777 means 'allow executable files' (scripts) to use this folder Note - when you 'share' a folder, all 'sub folders' within it are also part of the share. This means, for example, if you 'mount' a USB memory stick as a 'sub-folder' to /photos/ - say /photos/usbroot - the contents of the USB stick plugged into the Pi now become visible to the PC user
Sharing the folder
Folders to be shared must be given a 'share name' - for example 'pi-share' - that the PC user will use to 'map network drive'. To do this, edit the /etc/samba/smb.conf file. For example, to share the folder created above (sudo mkdir /my-folder-for-PC) as 'pi-share':-
sudo nano /etc/samba/smb.conf
then add at the bottom :- [pi-share] comment = My share folder path = /photos browseable = yes read only = no To share the entire Pi system, set the share-name to something obvious (like [pi-root]) and set the path=/ To check what you entered into smb.conf :-
/usr/bin/testparm
NOTE: 'testparm' just lists the 'shares' = if you change the name of a 'target' folder (eg from /my-folder-for-PC to /photos) using 'mv' ("move"), the old folder is NOT 'moved' to the new name in smb.conf (it will continue to 'point' at the old folder).
This means the 'share-name' will become 'unlinked' from Pi source folder, although 'testparm' won't complain (although your PC will throw an error when it can't find the Pi mapped drive contents, perhaps even claiming 'network unavailable')
Activating samba
To ensure a 'clean' start-up, reboot the Pi :-
sudo reboot now
After samba has started OK for the first time, if you add (or change) the 'shares' in /etc/samba/smb.conf, all you need to do is restart samba (rather than reboot the Pi). To restart samba :-
sudo samba restart
Accessing the Pi samba share from your PC
If you know the Pi's IP address, then from 'My Computer', Tools, Map Network Drive. Enter the path to the Pi share-name folder (eg //192.168.0.103/pi-share) when asked for user, enter 'pi', password 'raspberry'. If using Bonjour to find the Pi, you 'map' using 'raspberrypi.local' instead of the IP address (eg //raspberrypi.local/pi-share)
Pi Zero and "mirrordirector.raspbian.org" errors
Using a Pi Zero in RNDIS Gadget mode, when I attempted the 'apt-get' it successfully obtained the 'package lists' but then ended up with a series of "Could not resolve 'mirrordirector.raspbian.org'" errors. 'mirrordirector.raspbian.org' is a 'clever trick' by raspbian.org designed (I assume) to reduce loading on their servers by redirecting download requests to other sources, but (of course) I have no doubt this trips up all sorts of Firewalls, anti-virus and anti-'man-in-the-middle attack' prevention software on your PC. The way out of this quagmire is (apparently) to bypass the 'redirect' by going direct to the raspbian.org servers :-
sudo nano /etc/apt/sources.list
replace 'mirrordirector' in :- deb http://mirrordirector.raspbian.org/raspbian ... with 'archive' as follows :- deb http://archive.raspbian.org/raspbian ... Needless to say, this didn't actually work for me, even after I manually downloaded raspbian.org's public key and installed it onto the Pi :-
wget http://archive.raspbian.org/raspbian.public.key -O - | sudo apt-key add -
Update - the 'mirrordirector' problem is not due to the RNDIS Gadget driver.
A Raspberry Pi B+ that would 'apt-get' just fine when wired direct to my LAN, exhibited the exact same 'mirrordirector.raspbian.org' errors as did the USB Gadget connected Pi Zero when wired to my Laptop (and thence via ICS and the laptop's WiFi link to the Internet) . So (as usual) it's down to Microsoft and the way ICS works (or, in this case, doesn't work). You may have better luck using 'Bridging' (on the other hand, setting up on the B+ and moving the SDHC card to the Zero is faster)
This note last modified: 17th Sep 2016 08:10.
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 ?
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