RIFEC: Receive Images From Eye-Fi Cards ======================================= rifec.pl is a standalone program that receives images from Eye-Fi cards and stores them to disk. It works great with my Pro X2 cards running firmware 5.0018 (all the other 5.x and 4.x versions I have tried worked fine as well). Feedback from people who have tested other cards and versions is welcome. I have only tested it on Linux, but making it run on other Unix variants should be trivial. It is written in Perl 5, uses some CPAN modules, and is GPL. See the file INSTALL.txt for more information on installation and dependencies. It works on Synology NAS devices as well. It installs as an SPK software package in the DSM Package Center, so it will restart automatically on reboot etc. Look in the synology/ subdirectory in the "synology2" branch for more information: https://github.com/kristofg/rifec/tree/synology2/synology This is third-party software; it is not developed nor supported by Eye-Fi. Because of this, there will be limitations in what it can do compared to the official Eye-Fi software. Please see the file TROUBLESHOOTING.txt if you have problems. What can it do? =============== The primary use case is to have the images saved directly to the disk of a Linux computer on the same WLAN as the camera and card. * It supports multiple cards. The destination directory can be configured per card or as a shared setting. * It supports date-based destination directories, based on the clock on the receiving computer at the time of transfer. * It supports different destination directories for different file types coming from the same card, so you can store jpeg files in one directory, raw files in another, and videos in a third. What can it NOT do? =================== See also the "Todo" and "Ideas" sections further down. The main reason for not supporting these things are lack of time and need. If someone has time and need, patches are welcome! * The geotagging feature is currently not supported. * Running programs (hooks) to manipulate the images after they are saved is currently not supported. * Date-based destination directories based on the image (EXIF) date is currently not supported (note that date-based destination directories based on the time of transfer works fine.) Resources and other implementations =================================== The hardware: http://www.eye.fi/ This is not the first implementation of such a server. Some of the others are: * https://github.com/tachang/EyeFiServer (Python) * https://launchpad.net/eyefi (Python; seems to be the most actively maintained Python variant) * https://github.com/kenkeiter/ryfi (Ruby) * https://github.com/hacker/iii (C++) * http://randomtechmakings.blogspot.com/2009/01/i-bought-eye-fi-sd-card-few-weeks-ago.html (Perl) * http://code.google.com/p/eyefiserver/ (Python - based on https://github.com/tachang/EyeFiServer) The Eye-Fi forum thread at http://forums.eye.fi/viewtopic.php?f=4&t=270 contains some very useful information for everyone interested in running or making their own server. Todo ==== * Tests. It's amazing how fast a small program becomes big enough to allow bugs to hide in the corners where people rarely go. * Limit the number of forked threads, to make it just a little less DoS'able Things I'm still wondering about ================================ * What is the filesignature field in the SOAP envelope of the file upload? Something we can check? * What does the 'flags' field in the GetPhotoStatus request mean? Ideas ===== * More control over destination directories: - Based on file type (jpegs /go/here, raw files /go/there, etc.) - Based on EXIF data, so if you have multiple cameras and multiple cards the images from camera A would end up in the same place regardless of which card you put in it. (Would be more interesting if I had multiple Eye-Fi cards.) The biggest problem with these features is the configuration part: How to make this configurable in a robust, easy to understand, and easy to debug way? * Hooks for running custom scripts on successful upload. Would probably solve the previous problem as well, but has pretty much the same problems, too.