New Module to download photos from Apple iCloud

[sdetweil]

@msimon360 imagesphotos should refresh its list of images every 60 seconds by default
I use it linked to a file share on my nas
Because there are so many pics no idea when the new pic will appear, add random on to that and it’s worse for predictably

[msimon360]

@sdetweil I was testing on an album with only 4 photos and set to sequential. What I found, with help of Claude, was Before the Dec 2023 fetch rewrite, every completed request did:

if (retry) {
  self.scheduleUpdate(self.loaded ? -1 : self.config.retryDelay);
}

After the rewrite it became:

if (!photosResponse.ok) {
  if (retry) self.scheduleUpdate(...);
}

So the directory list only refreshed on HTTP failure, not every getInterval. I have an updated MMM-ImagesPhotos.js with a fix but I don’t know the best way to send it. Would you like a diff, patch, GitHub branch, other?

[sdetweil]

@msimon360 ImagePhotos isn’t mine, I have a fork…

so, generally how you do this , for any change to any repo on github

on github, find the source module repo
make a fork (copy on YOUR github)
checkout your fork
make a new branch
make the changes
commit to local branch
push to your github fork
github will see this and offer to create a PULL request to the original source , and the author can execute that PULL , from yours to theirs (merge is the operation)

once its merged, then you can delete your branch
and then sync the source to your fork (if you still want the fork)
git pull on your fork to get the update,
OR
delete your local copy of the fork, and redownload the original repo again
and maybe delete your fork on github, if you think you will never need it again

as for the bug

retry is a bad choice of variable, if its not in a failure path!.. lol…

[msimon360]

@sdetweil Thanks for the detailed instructions. I am using your fork and I made the pull request. The only files changed are MMM-ImagesPhotos.js and I put my GitHub link in the README.md.

[sdetweil]

@msimon360 merged… also merged support for apple HEIC images…

git pull
to get the latest
or sync your fork, then git pull

[msimon360]

@sdetweil I gave it a try and no photos displayed. I went back to my repo. The explanation I got from AI was this;
Why photos disappeared
non-fullscreen (bottom_center) crashes in getDomnotFS because EXIF is appended to this.wrapper (fullscreen-only) instead of the local wrapper. With default showExifDate: true, getDom throws → blank module.

[sdetweil]

@msimon360 ok. Set the showexif: false

Will review

[sdetweil]

I fixed the crash, git pull

[msimon360]

@sdetweil It still failed to show photos. I merged the latest sdetweil/MMM-ImagesPhotos master into my fork and pushed it to https://github.com/msimon360/MMM-ImagesPhotos (6bb682d). The changes below are working on my Raspberry Pi, where MMM-iCloudPhotos drops files into uploads and the module is not fullscreen.

MMM-ImagesPhotos.js

getPhotos() requests /MMM-ImagesPhotos/photos/?t= with cache: “no-store”, so the browser does not reuse an old photo list.
After a successful fetch it always calls scheduleUpdate(), so getInterval keeps rereading the folder. Previously the next read was scheduled only when the response failed, so new uploads never appeared.
A failed fetch retries after retryDelay.
notificationReceived() reloads the list when it receives MMM_IMAGESPHOTOS_REFRESH. That is what MMM-iCloudPhotos sends after a sync.
scheduleUpdate() clears any pending refresh timer before setting the next one.
In the non-fullscreen layout, the EXIF date is appended to the local wrapper. this.wrapper exists only for fullscreen, so the old this.wrapper.appendChild(exifDate) threw when the module was in a normal region such as bottom_center.
Both the normal and fullscreen city lookups check photoImage.lat before reading .length, so a photo with no GPS data does not crash.
The default for showExifDate stays false, from upstream.

node_helper.js

extraRoutes() registers the photo routes once per module id.
The photo-list response sets Cache-Control: no-store.
getPhotosImages() reads EXIF per file inside its own try/catch. A file with no EXIF, or a parse error, is still added to the list with empty date and coordinates.
The list is always sent, including when the EXIF loop fails. Upstream’s outer try did not see errors inside the async EXIF loop, so the response could never be sent and the slideshow never started.

README.md

Notes that a failed EXIF read no longer blocks the slideshow, that the folder is refreshed on getInterval, and that other modules can send MMM_IMAGESPHOTOS_REFRESH.
package.json

Version is 0.3.0.
Repository URL is https://github.com/msimon360/MMM-ImagesPhotos.
Mark

[sdetweil]

@msimon360 thanks… I merged your code…