search

mrworf / photoframe

Software to pull random photos from Google Photos and show them, like a photo frame
GNU General Public License v3.0
220 stars 38 forks source link

FR: Display photos from network share #102

Open shigadeyo opened 5 years ago

shigadeyo commented 5 years ago

This is a continuation of Issue #70 that was re-purposed for loading pictures from a local USB folder.

It would be extremely useful if photoframe could display pictures from a network repository such as the following:

  1. Shared folder on NAS (e.g., QNAP)/Linux device
  2. Shared folder on Windows computer
  3. DLNA server

Reasons why this is useful:

dadr commented 5 years ago

I would also like to see this feature. However, I can see why it makes sense to work on USB folder first. I would think that USB and network share would be common filesystem operations but have different front ends for attachment. IMO, USB should be PNP, but network shares often need authentication, so need a bit more in the setup phase, like adding the json file for google photos.

dadr commented 5 years ago

I've thought and experimented a bit with this. Here's what I have so far:

You can "fake-out" the USB service to perform this function within limits. The steps I took are:

1) create a SMB share with a directory "photoframe" at the top level - just like a USB drive 2) enable SSH access to the Pi 3) add samba client to Pi ( sudo apt-get install cifs-utils ) 4) mount SMB filesystem to USB mount point: sudo mount.cifs //yourserver[.local]/yoursharename /mnt/usb1 -o user=youruser 5) you can add the password to the command line or just get prompted, or make a guest account on the server that does not require a password. 6) Goto the URL for managing photoframe and add the USB service. If it was already added, and says "Storage device "unknown" is mounted to "/mnt/usb1" - but is not showing any picture, then you may have to restart the service using "sudo service frame restart"

---- Then for each time you reboot the Pi ---- 1) login with ssh 2) mount the SMB service as described in #4 above. 2) run the command: sudo service frame restart

---- If this is good enough for you, then you can look into how to get the Pi to auto mount the samba share when it boots. All of these changes do not affect the photoframe code, so it should still update with new releases ----

dadr commented 5 years ago

If we wanted to make a SMB service, then I think that starting with the USB service would be a good choice. However, the fileshare has some characteristics that USB drives do not, and those would need to be handled. The items that have occurred to me are: 1) There needs to be a share identification and authentication when the service is added that allows you select a server and enter a user name and password. This could be quite simple, or could support "browsing" for a server. I'd say do quite simple first, as this would not be a frequent operation. 2) The mount point needs to be different from the USB service, I'd suggest /media/server_sharename or something similar that allows for multiple servers with same share names. 3) The SMB service needs to scan the directory for changes at some intervals. Unlike a USB drive, most people will probably add and remove photos from the Samba share from a different computer without remounting the share at the Pi. So the share needs to be rescanned for updates. This could be pretty simple, like getting a file count, or it could be more sophisticated, checking whether each file has been changed since the last scan.
4) Some behavior needs to be designed for the times that the share is not available. I found the cifs.mount pretty robust, but everything fails. So, it would be good to have a way to retry mounting the share when it fails, and selecting a behavior (playing from the cache | showing error | overlaying an icon on the picture that indicates no source available.) This might be useful across other services as well.

mrworf commented 4 years ago

I'm actually curious to see if it would be possible to use smbclient instead to avoid relying on a filesystem mount for this, since I've had plenty bad experiences with smb/cifs mounts. It would also allow said service to use different underlying method and possibly support things like ftp/sftp/apple share/etc.

mrworf commented 4 years ago

Anyway, this feature depends on the upcoming support for services to host simple UIs for configuration (like user/pass, etc). So it's still some ways out.