Brad's idea: keep several saved picks, such as Wedding, Christmas and Grandkids, and choose which one the frame shows.
A playlist can't be a remembered session
Two limits rule that out. A Picker session expires: one created 2026-09-23 carried expireTime 2026-09-30, about seven days. And a picked item's baseUrl lasts 60 minutes (Picker docs: "Base URLs remain active for 60 minutes"). Once the session is gone the app can't re-list its items, so there's no way to get fresh URLs. Whatever makes a playlist last has to be something other than the session.
Two designs
(a) Keep the photos locally. When a pick finishes, download each photo at panel size into the cache, in one folder per playlist, and never evict those files. It needs no new scopes and nothing changes in Google Photos, and it works offline afterwards. The cost is storage. On a desktop that's nothing. On a board, a 320x480 JPEG is roughly 30–60 KB, so 50 photos come to 2–3 MB per playlist, which most boards can only hold on an SD card. A playlist also stays on the device that picked it. A second frame, or a reflash, starts empty.
(b) Copy the picks into an app-created album per playlist. After a pick, download each item and upload it with the Library API into an album the app created ("PyDevices: Wedding"). The app can read what it created indefinitely, so at play time it lists the album and gets fresh baseUrls whenever it needs them. I checked the scopes against Google's docs on 2026-09-23 (authorization, March 2025 changes):
https://www.googleapis.com/auth/photoslibrary.appendonly: "upload bytes, create media items, create albums".https://www.googleapis.com/auth/photoslibrary.readonly.appcreateddata: "Read access to media items and albums created by the developer."photoslibrary.readonly, photoslibrary.sharing and photoslibrary have returned 403 PERMISSION_DENIED since March 31, 2025. The app can never read the originals, only its own copies.
This has three costs. It adds two scopes, so tools/gphotos_auth.py needs a re-run and a new consent screen. Every photo in a playlist is duplicated in your library and counts against storage. And building a playlist moves full-size bytes down and back up, which you'd do on the PC, or live with being slow on a board. What you get back is a playlist that works on any board with no SD card, survives a reflash, and is shared by every frame on the account.
UI shape (either design)
- A playlists page listing the saved picks, with a count each and New playlist.
- Pick into a playlist. It's today's connect page, reached from a playlist: New playlist asks for a name (or offers a few presets on a board with no keyboard), then scan, pick, Done.
- A per-playlist list and slideshow, which is today's list and view pages scoped to one playlist, plus Add photos (a new pick, appended) and Delete playlist.
- The frame remembers the last playlist it played and starts on it.
Recommendation
(b). A frame is a board, and (a) only works on a board with an SD card and gets lost on a reflash. The duplication in (b) is visible and easy to explain: the album shows up in Google Photos under its own name, and you can delete it there. Start the build with the playlist page and (a) on desktop only, since that works without the new scopes, and put (b)'s upload behind it as the storage layer.
Not scheduled. Filed from Brad's first real run, 2026-09-23.
Brad's idea: keep several saved picks, such as Wedding, Christmas and Grandkids, and choose which one the frame shows.
A playlist can't be a remembered session
Two limits rule that out. A Picker session expires: one created 2026-09-23 carried
expireTime2026-09-30, about seven days. And a picked item'sbaseUrllasts 60 minutes (Picker docs: "Base URLs remain active for 60 minutes"). Once the session is gone the app can't re-list its items, so there's no way to get fresh URLs. Whatever makes a playlist last has to be something other than the session.Two designs
(a) Keep the photos locally. When a pick finishes, download each photo at panel size into the cache, in one folder per playlist, and never evict those files. It needs no new scopes and nothing changes in Google Photos, and it works offline afterwards. The cost is storage. On a desktop that's nothing. On a board, a 320x480 JPEG is roughly 30–60 KB, so 50 photos come to 2–3 MB per playlist, which most boards can only hold on an SD card. A playlist also stays on the device that picked it. A second frame, or a reflash, starts empty.
(b) Copy the picks into an app-created album per playlist. After a pick, download each item and upload it with the Library API into an album the app created ("PyDevices: Wedding"). The app can read what it created indefinitely, so at play time it lists the album and gets fresh
baseUrls whenever it needs them. I checked the scopes against Google's docs on 2026-09-23 (authorization, March 2025 changes):https://www.googleapis.com/auth/photoslibrary.appendonly: "upload bytes, create media items, create albums".https://www.googleapis.com/auth/photoslibrary.readonly.appcreateddata: "Read access to media items and albums created by the developer."photoslibrary.readonly,photoslibrary.sharingandphotoslibraryhave returned403 PERMISSION_DENIEDsince March 31, 2025. The app can never read the originals, only its own copies.This has three costs. It adds two scopes, so
tools/gphotos_auth.pyneeds a re-run and a new consent screen. Every photo in a playlist is duplicated in your library and counts against storage. And building a playlist moves full-size bytes down and back up, which you'd do on the PC, or live with being slow on a board. What you get back is a playlist that works on any board with no SD card, survives a reflash, and is shared by every frame on the account.UI shape (either design)
Recommendation
(b). A frame is a board, and (a) only works on a board with an SD card and gets lost on a reflash. The duplication in (b) is visible and easy to explain: the album shows up in Google Photos under its own name, and you can delete it there. Start the build with the playlist page and (a) on desktop only, since that works without the new scopes, and put (b)'s upload behind it as the storage layer.
Not scheduled. Filed from Brad's first real run, 2026-09-23.