[IM-Lab-france]

L’écran de veille peut afficher les photos d’un album Google Photos partagé, avec actualisation périodique, en conservant les transitions existantes. L’administration permet de choisir entre les images locales et l’album Google, de saisir son lien, de régler la fréquence et de consulter un aperçu ou une erreur. Les images locales sont conservées lors du changement de source.

Confidentialité : toute personne possédant le lien partagé peut consulter les photos de l’album, sans connexion au compte Google. Un avertissement visible dans l’administration explique cette conséquence. Aucun lien personnel ni photo réelle n’est inclus dans la contribution.

Fonctionnement

• Lecture de la page de partage accessible sans connexion, sans OAuth ni clé API Google.

• Relais des photos en mémoire par le serveur, sans import sur disque, pour conserver WebGL et la politique de sécurité du navigateur.

• Contrôle des hôtes, chemins et redirections, limites de taille, durée et concurrence ; accès aux réglages réservé à l’administration.

• Actualisation automatique configurable et actualisation manuelle limitée. Les ajouts et suppressions sont pris en compte après une lecture réussie.

• En cas de panne réseau, de délai dépassé ou de réponse HTTP 408/429/5xx, conservation de la dernière liste et nouvelle tentative après environ une minute. Retour à la fréquence configurée après succès. Retrait de la liste et du cache en cas d’erreur définitive : album supprimé ou vide, partage refusé ou format non reconnu.

• Cache uniquement en mémoire, limité à 32 Mio et à cinq minutes de réutilisation. Regroupement des demandes simultanées d’une même photo ; huit téléchargements distincts simultanés au maximum. Invalidation lors d’un changement de source, de lien ou d’adresse de photo, ou après suppression.

• Une photo indisponible, notamment en cas de réponse 404 lors d’une saturation, est sautée au profit de la suivante. Les aperçus administrateur illisibles ou absents affichent un visuel explicatif et sont retentés après vérification de l’album.

• Migration SQLite additive, tests et documentation. Aucune nouvelle dépendance.

Le contrat actuel des modules ne permet pas de remplacer le diaporama plein écran : le choix de source est donc intégré à l’écran de veille du cœur.

Limites et évolution envisagée

Cette intégration est expérimentale et non officielle : une modification de la page Google peut la casser. Seule la page initiale est lue, avec un maximum de 500 entrées ; les grands albums peuvent être incomplets. Les vidéos ne sont pas lues. Le cache ne garantit pas l’affichage de tout l’album hors connexion : seules les images encore en cache peuvent être servies pendant une panne.

La feuille de route décrit une future intégration officielle avec Google Photos Ambient API, pour autoriser le compte et choisir les albums sans lien partagé. Elle nécessite d’abord l’admission de Cornelius au programme partenaire Google Photos, puis la vérification OAuth et la revue de l’intégration avant lancement. Cet accès dépend de Google et n’est pas acquis : conditions officielles. Ambient n’est pas implémenté dans cette PR.

Vérifications

Corrections de revue vérifiées le 3 novembre 2026 :

• Formatage, compilation TypeScript et build Vite locaux réussis.

• Après fusion de la branche main actuelle : 69 tests ciblés réussis, couvrant Google Photos, l’écran de veille, le fournisseur mémoire personnalisé, le stockage, la configuration, le réseau et la découverte. Deux nouveaux tests vérifient la migration depuis la version officielle et depuis l’ancienne version expérimentale Google Photos, sans perte des réglages.

• 10 parcours Chromium réussis : administration Google Photos, diaporama et réveil ; trois réponses 404 successives au démarrage et pendant le diaporama, avec et sans WebGL ; aperçus manquants, galerie indisponible et récupération après actualisation, sur ordinateur et mobile.

• Essai réel sur une installation Linux : 300 entrées détectées et une photo JPEG récupérée. Coupure temporaire de l’accès à Google Photos, erreur signalée avec liste conservée, poursuite de l’affichage sur le miroir et reprise après rétablissement confirmées visuellement par l’utilisateur. Interface corrigée servie en HTTPS et build client Linux vérifiés.

Lors de la préparation initiale, 111 tests Python avaient réussi et la suite TypeScript sous Windows comptait 695/696 réussites. L’échec restant concernait le nettoyage d’un dossier SQLite encore ouvert (EPERM) dans tests/profiles-api.test.ts, fichier non modifié par cette contribution. Ces suites complètes n’ont pas été relancées pour les corrections de revue.

Les tests automatiques utilisent des données synthétiques. Aucun lien personnel ni photo réelle n’est inclus dans la contribution.

Cette PR ne contient aucune modification de firmware ou d’infrastructure.

[lfpoulain]

Hello, et merci pour cette PR ! 🙌

C'est vraiment soigné : les adresses Google sont bien verrouillées, rien n'est écrit sur disque, la doc et les tests sont là. Merci aussi pour l'avertissement sur le partage par lien, c'est top.

Deux petites choses avant qu'on merge :

• Coupure réseau : si Google ne répond pas une fois, la liste des photos est vidée jusqu'au prochain rafraîchissement, donc 30 min sans diaporama par défaut. Est-ce qu'on pourrait garder les photos en cas d'erreur passagère (réseau, 5xx), et ne les retirer que si l'album a vraiment disparu (404, album vide) ? Ou réessayer un peu plus tôt ?
• Pas de cache : chaque photo affichée refait un aller-retour vers Google, et au-delà de 8 téléchargements en même temps le serveur répond 404. Tu peux vérifier que le diaporama passe bien à la photo suivante dans ce cas ?

Tout petit détail, pas bloquant : l'empreinte de chaque photo est recalculée à chaque appel, mais avec 500 photos max ça ne change rien.

Dès que c'est corrigé, on merge ! 🚀

[IM-Lab-france]

Merci pour tes retours ! Les deux points sont corrigés :

• Coupure réseau : la dernière liste est conservée sur panne réseau, délai dépassé ou réponse HTTP 408/429/5xx. Une nouvelle tentative automatique intervient après environ une minute, puis le rythme configuré reprend après succès. Un album supprimé ou vide, un partage refusé ou un format non reconnu retire toujours la liste et le cache.
• Cache et concurrence : ajout d’un cache uniquement en mémoire de 32 Mio, avec réutilisation pendant cinq minutes au maximum. Les demandes simultanées d’une même photo partagent un téléchargement ; la limite de huit téléchargements distincts est conservée. Aucun enregistrement de photo sur disque.
• Passage à la photo suivante : j’ai trouvé et corrigé un arrêt prématuré des essais lorsque plusieurs photos échouaient successivement. Le comportement est vérifié dans Chromium avec trois réponses 404 successives, au démarrage et pendant le diaporama, avec et sans WebGL.
• Administration : le texte distingue désormais les erreurs passagères des erreurs définitives. Les aperçus indisponibles affichent un visuel explicatif et sont retentés après une vérification de l’album.

Validation : formatage et build réussis, 31 tests ciblés et 10 parcours Chromium réussis. Un essai réel sur une installation Linux avec coupure de l’accès à Google Photos a confirmé la conservation de la liste, la poursuite de l’affichage sur le miroir et la reprise après rétablissement. La documentation et la description de la PR sont actualisées.

Le cache reste volontairement borné et ne garantit pas l’affichage de tout l’album hors connexion. Le petit point non bloquant sur le recalcul des empreintes reste inchangé.

[IM-Lab-france]

Les conflits avec main sont résolus : changelog, imports de l’API web et migrations SQLite. Les ajouts Home Assistant et fournisseur mémoire personnalisé sont conservés.

La migration officielle reste à son index publié. La nouvelle migration, rejouable, assure la présence des deux tables afin de prendre aussi en charge les installations de l’ancienne version expérimentale Google Photos. Deux tests vérifient la conservation des réglages pour ces deux chemins de mise à niveau.

Validation après fusion : compilation TypeScript/Vite réussie, 69 tests ciblés et 10 parcours Chromium réussis.

[lfpoulain]

Merci pour cette PR, le travail est soigné. La validation d'URL est solide (liste d'hôtes fermée, vérifiée à chaque redirection, HTTPS seul, pas de port ni d'identifiants), les limites de taille et de temps sont bien posées, et la couverture de tests est sérieuse : tsc et les 33 tests ciblés passent contre main.

Procédure

Comme pour #22, la PR vise main. Pourriez-vous la rebaser sur beta et changer la base de la PR ? Conflits mécaniques sur CHANGELOG.md et server/storage.ts (la migration fusionnée avec customProviderMigration repasse en fin de liste).

À corriger

1. Un 404 transitoire retire la photo de la rotation (web/components/Screensaver.tsx, boucle load, catch). Quand le relais renvoie 404 (saturation à 8 téléchargements, ou erreur temporaire côté Google), la photo est retirée de la liste locale. Elle ne revient que quand la révision de l'album change, ou après rechargement du miroir. Les photos disparaissent une à une, jusqu'à ce que images.length < 2 arrête le diaporama. Le cas des 404 successifs est testé, pas la récupération.
2. Pas de repli quand Google est indisponible : après un redémarrage hors ligne ou un changement de format de la page, la source reste google-photos avec 0 photo, sans retour aux images locales (la doc l'assume). Une page modifiée peut faire disparaître l'écran de veille pour tous les utilisateurs de cette source. Un repli automatique, au moins temporaire, serait prudent.
3. Rien dans le journal de diagnostic : GooglePhotosAlbum n'utilise aucun logs.write. Un échec n'apparaît que dans l'administration, jamais dans l'export du journal que CONTRIBUTING demande de joindre aux tickets. C'est surtout utile pour déboguer un format qui change.
4. Bouton « Actualiser maintenant » : pendant 60 s après une vérification, refresh() retourne sans rien faire, mais l'interface affiche « Vérification de l'album terminée ».

Questions que nous devons trancher côté mainteneurs

Ne bloquez pas votre travail dessus.

• Lien d'album stocké en clair : il contient la clé de partage et sert de secret porteur. CONTRIBUTING limite le stockage des secrets saisis en administration à la table secrets.
• Conditions d'utilisation de Google : la lecture de la page de partage avec un User-Agent fixe, sans API officielle, doit être évaluée avant de présenter la fonction comme autre chose qu'« expérimentale ».
• Découpage : la PR fait +1750 lignes sur 20 fichiers. Un découpage en trois (serveur et API, interface et miroir, doc et feuille de route) faciliterait la relecture, mais ne nous paraît pas indispensable.

Détails

Le SHA-256 de chaque photo est recalculé à chaque appel de list() et image(), et il manque des tests pour la récupération après 404 et l'indisponibilité au démarrage.

[lfpoulain]

Merci, fusionnée dans beta, en fonction expérimentale. Le repli sur les images locales et les messages d'erreur sont très bien faits.