260828-Tofs à compresse sur SASNEXTE
Compression des photos du NAS SASNEXTE — étude de faisabilité
Procédure en service depuis le 2026-08-28, première bascule réelle le 2026-09-28. SuiteMême demoteur que la procédure Photos-Caesium du PC (page 284), appliquéemais cetteavec foisune auvalidation stockhumaine photoavant dutout NAS.écrasement. Copie de référence : Jux-scripts/Photos-Caesium/doc_bookstack_285.md.
En bref
Les photos du NAS sont déjà à leur place dans /volume1/photo : C'eston faisable,ne dépose rien. La procédure les prend là où elles sont, les compresse dans un dossier d'attente, et len'écrase NASl'original estque lece bonque endroitvous pouravez le fairevalidé — pas le PC à travers le VPN..
photos_reprise dans Synology Photos
Comment refuser
caesiumclt v1.4.0 musl, natif sur DSM
Gain Une réserve bloquante avant tout déploiement : la majorité de ces photos n'a pas de copie hors du NAS. Voir « Points de vigilance ».
1. Rétablissement de l'accès SSH
Le NAS était joignable en SMB par le tunnel WireGuard (page 245) mais pas en SSH.
Cause réelle : le service SSH était désactivé et le port 22 fermé par les règles de sécurité DSM posées par Julien. Leur neutralisation a tout débloqué immédiatement.
Ce qui m'a égaré, et qu'il faut noter pour ne pas s'y reprendre : le port 22 répondait par une bannière SSH-2.0-OpenSSH_8.2, annonçait publickey,password et évaluait les identifiants avant de les rejeter par « Permission denied ». J'en ai conclu à tort que le service tournait et que le problème venait de l'autorisation — j'ai successivement soupçonné le groupe administrators, puis la vérification en deux étapes. Les deux hypothèses étaient fausses. Une bannière SSH qui répond ne prouve pas que l'accès soit ouvert sur ce NAS.
Diagnostics utiles conservés au passage :
smbclient -L //10.0.0.2 -NNT_STATUS_LOGON_FAILUREsmbclient //10.0.0.2/NEXTE -U sas_nextessh -o PreferredAuthentications=nonepublickey,passwordEncodage du mot de passe : le § final ne survit pas au passage par Git Bash vers plink. Le contourner en construisant le mot de passe côté cible en octets explicites :
printf 'xAPIJU5108\xc2\xa7' > /tmp/pw
sshpass -f /tmp/pw ssh -o NumberOfPasswordPrompts=1 sas_nexte@10.0.0.2
-o NumberOfPasswordPrompts=1 est important : sans lui, un échec compte pour trois tentatives auprès du blocage automatique de DSM.
Le compte
uid=1026(SAS_NEXTE) gid=100(users) groups=100(users),101(administrators),1023(http)
Le compte Unix s'appelle SAS_NEXTE en majuscules, alors qu'on s'y connecte en sas_nexte. DSM est insensible à la casse à l'ouverture de session, mais le dossier personnel et le propriétaire des fichiers portent la forme majuscule. C'est à surveiller dans tout script.
Authentification par clé — non aboutie
Une paire ed25519 a été généréeDébit sur le PC (D:\SSH\nas_sasnexte, hors de l'arbre Syncthing, empreinte SHA256:4yK8Mxz5e9jmxSdIh6PT/Murip0pIpoFlA0MzDanB98) et la clé publique déposée par SMB dans \\10.0.0.2\home\.ssh\authorized_keys. Le fichier est bien arrivé, intact, 105 octets — mais l'authentification reste refusée.
Cause probable : le StrictModes d'OpenSSH, qui rejette un ~/.ssh ou un dossier personnel accessibles en écriture au groupe ou à tous, ce que Synology crée par défaut. Non résolu à ce jour ; on travaille au mot de passe en attendant. Correctif à tenter, en root :
H=$(getent passwd sas_nexte | cut -d: -f6)
chown -R SAS_NEXTE "$H/.ssh"; chmod 700 "$H/.ssh"; chmod 600 "$H/.ssh/authorized_keys"
Deux pièges DSM à connaître
scpdest open: No such file or directoryscpssh nas 'cat > /chemin/cible' < fichier_local
/tmpnoexectmpfs … rw,nosuid,nodev,noexec/volume1noexec2. La machine
/volume1/homes/SAS_NEXTE/bin/caesiumcltx86_64-unknown-linux-muslLe binaire musl est statique et sans aucune dépendance : il s'exécute nativement sur DSM sans rien installer, sans Docker, sans Entware.
3. Le stock réel de /volume1/photo
Mesuré en excluant les dossiers techniques. Total du dossier : 79 Go (du), dont 78,8 Go retrouvés fichier par fichier — les deux mesures concordent.
@eaDirAttention au recensement naïf : un find … -iname '*.jpg' sans exclure @eaDir compte 71 802 fichiers au lieu de 16 422, parce qu'il ramasse les vignettes générées par Synology. Un échantillon constitué ainsi fausse gravement la taille moyenne — c'est l'erreur commise en première approche ici.
La corbeille s'est vidée pendant l'étude, à 07:19 : /volume1/photo est passé de 91 Go à 79 Go. Cela explique deux écarts de mesure qui semblaient d'abord contradictoires.
4. Banc d'essai
Méthode : 300 JPEG prélevés dans tout l'arbre (un fichier sur 200, pour ne pas biaiser vers un dossier ou une époque), copiés dans un dossier de travail, compressés vers un autre. Aucun original n'a été modifié. Dossier de test supprimé après mesure.
caesiumclt -q 80 -e --keep-dates --min-savings 1% --threads 0 --json -o SORTIE ENTREE
ÀLetitrerefus ne demande aucune action. Une photo absente du dossier decomparaison,validation au moment de la bascule voit son original conservé, sans rien à cocher ni saisir. L'inaction est lemêmecomportementprofilsûr:q80surunlelotRyzenabandonné5en2600Xroute,duunePCsession(12interrompue,threads)undonne11,4 Mo/soubli —soitrienunnefacteurse7,4,perdcohérentparavecnégligence,l'écartseulementdeparcœursdécisionetexplicite.d'IPC.
5.La Vérificationprocédure, desen métadonnéesquatre commandes
1. Voir les lots disponibles
python3 /volume1/homes/SAS_NEXTE/scripts/traiter_lot_nas.py --lister
C'étaitAffiche lachaque questionsous-dossier décisiveavec :son compressernombre 16 000de photos deà familletraiter neet doitson pas coûter une date ni une position.
EXIF, dates, dimensions — 6 photos tiréespoids, du stock
plus Bloc EXIF identiqueensuite à l'octet près, date de prise de vue inchangée, dimensions inchangées, date du fichier préservée par --.keep-dateslot
GPS2. Compresser un lot — surles desoriginaux ne sont pas touchés
python3 /volume1/homes/SAS_NEXTE/scripts/traiter_lot_nas.py --lot "2026/2026-Automne"
--lot accepte un préfixe d'album ou de chemin : 2022 prend toute l'année, 2026/2026-Automne un seul sous-album. Le préfixe suffit, inutile de taper les accents. Les photos quicompressées arrivent dans /volume1/homes/SAS_NEXTE/Photos/photos_reprise, en portentreproduisant réellementl'arborescence.
3. Valider dans Synology Photos
LesOuvrez sixphotos_reprise dans l'application, en plein écran, et supprimez les photos ci-dessus,dont prisesla entrequalité 2006ne convient pas. Ce qui reste vaut validation.
4. Basculer
python3 /volume1/homes/SAS_NEXTE/scripts/basculer_lot_nas.py --lot "2026/2026-Automne"
sudo python3 /volume1/homes/SAS_NEXTE/scripts/basculer_lot_nas.py --lot "2026/2026-Automne" --go
La première ligne est une simulation : elle annonce combien de photos seront remplacées et 2013combien parsont desrefusées. appareilsLa photo,seconde neécrase contenaient aucune coordonnée. Un second test a donc cherché des fichiers réellement géolocalisés :
PhotoLab445379.jpg2013 Marseille/Gaetan.jpg2013 Marseille/20130915_122108_Tunnel du Vieux-Port.jpg2013 Marseille/20130915_114356_Tunnel du Vieux-Port.jpgCoordonnées préservées au chiffre près. Les positions correspondent bien au Vieux-Portpour de Marseille et à la région de La Ciotat.vrai.
⚠
Tout cela dépend de l'optionLe-esudo, quin'estPASpasle comportement par défaut de Caesium.décoratif.SansLeselle,photosl'EXIF entier est supprimé — dates et GPS avec. Ne jamais la retirer des options communes. Ne pas utiliser--strip-iccnon plus, qui l'annule pour les profils colorimétriques.
6. NAS ou PCappartiennent à travers le VPN ?
Le tunnel WireGuard est en étoile : chaque octet entre le PC et le NAS fait PC → VPS OVH → NAS, deux sauts WAN, sans liaison directe. Débit mesuré en lecture : 4,01 Mo/s (32 Mbit/s).
Le PC est plus rapide en temps de mur, mais il monopolise le lien du site de Toulon pendant quatre heures et impose de laisser la machine allumée. Le NAS travaille la nuit, ne coûte rien et personne ne l'attend. C'est le bon choix pour le rattrapage du stock ; le PC resterait pertinent pour un lot ponctuel de quelques gigaoctets.
7. Points de vigilance
1. La sauvegarde — point bloquant. Le script sync_kdrive_complete.shadmin:users du NAS ne synchronise que /volume1/photo/2026 vers kDrive, et en rclone sync --delete-during, c'est-à-dire un miroir. LesLancée 37,6 Go de JPEG couvrant 1967 à 2025 n'ont donc aucune copie hors du NAS par cette voie, et une compression sur place propagerait les versions compressées en écrasant le miroir pour 2026. Vérifier ce qui existe par ailleurs (Hyper Backup, ActiveBackupforBusiness) avant toute réécriture de masse.
2. La compression sur place est irréversible. Le profil q80 est un ré-encodage : on ne revient pas en arrière. Deux parades, à combiner : écrire d'abord dans une arborescence parallèle et ne basculer qu'après contrôle (37,6 Go de plus sur 1,4 To libres, c'est indolore), et commencer par un seul dossier pour juger la qualité à l'œil.
3. Ne jamais toucher aux @eaDir. 15,36 Go de vignettes et d'index Synology. Les compresser casserait Synology Photos, qui les régénérerait aussitôt.
4. --keep-dates protège l'indexation. En préservant la date de modification, on évite de déclencher une réindexation complète de Synology Photos sur 16 000 fichiers — ce qui occuperait le NAS bien plus longtemps que la compression elle-même.
5. HEIC et vidéos restent hors de portée. 691 HEIC et 21 Go de vidéos ne sont pas concernés. Pour les vidéos, le levier serait un ré-encodage H.265, un tout autre chantier, très au-delà des capacités d'un J4025.
8. Reste à faire
/volume1/photochmod~/.sshcompress_photos.py@eaDir#recycle/volume1/homes/SAS_NEXTE/logs/9. Immich et la chronologie — la question decisive (2026-08-28)
Crainte soulevee par Julien : « Immich ne lit que la date de modification du fichier pour composer l'historique. Avec cette compression, tout mon historique photo va devenir illisible. »
Elle est fondee pour une partie du stock. Verifie sur la bibliotheque reelle (18 156 elements, Immich v2.7.5, /home/debian/photo monte en lecture seule sur /mnt/media/photo — bibliotheque externe) :
fileModifiedAtlocalDateTimeIMG_20260718_181515.jpgDateTimeOriginalIMG_20260705.jpgAutrement dit : quand la photo porte une vraie date de prise de vue, Immich s'en sert et se moque du fichier. Quand elle n'en a pas — images WhatsApp, captures d'ecran, scans — Immich se rabat sur la date de modification du fichier. Ces photos-la sont exactement celles que la crainte visait.
Ce qui a ete change en consequence
--keep-dates de Caesium preserve bien le mtime (verifie). Mais faire reposer l'historique photo d'une famille sur une option d'un outil tiers etait trop fragile. Le script ne dependant plus de cette option :
st_mtimest_atimest_uidst_gidos.utimeos.chownos.chmodCe n'est plus une promesse mais une assertion verifiee fichier par fichier, aussi bien en remplacement sur place qu'en arborescence parallele.
Preuve
Dossier temoin /volume1/photo/1968-1994 - photos famille dont Noumea/1990, 26 photos, mode parallele :
26 fichiers compares, 0 ecart(s)
originaux inchanges (taille et date) : oui
VERDICT : aucune date ni aucun proprietaire alteres
⚠ La tache DSM doit imperativement tourner en ROOT
Le controle ci-dessus a immediatement servi. Lance en tant quesous SAS_NEXTE, lela meme test signale 26 ecarts de proprietaire :bascule les photosréattribuerait appartiennent a admin:users, l'appel os.chown echoue faute de privileges,toutes et les fichiers produits basculent sur SAS_NEXTE. Sur 16 422 fichiers, cela casserait l'accesaccès SMB et Synology Photos.
Relance en root (sudo), la meme verification donne 0 ecart.
A retenir : dans le planificateur de taches de DSM, choisir l'utilisateur root, jamais SAS_NEXTE.
Etat de la chronologie avant intervention
Sur 18 156 elements indexes, 2 seulement sont dates de l'an 4501 (4501-01-01) — des scans totalement depourvus de metadonnees, pour lesquels Immich n'a trouve aucune date exploitable. C'est preexistant, marginal, et sans rapport avec la compression.
Acces Immich depuis Claude
Il n'y a pas de MCP Immich dans cette session : mcp_immich.py fait partie des serveurs perdus avec le profil Windows eliob et jamais reecrits (voir la liste « reste a ecrire » dans CLAUDE.md). L'API REST suffit :
d = json.dumps({'email': 'bertrand.dadone@gmail.com', 'password': '...'}).encode()
r = urllib.request.Request('https://immich.juxjux.ovh/api/auth/login', data=d,
headers={'Content-Type': 'application/json'})
jeton = json.loads(urllib.request.urlopen(r).read())['accessToken']
Endpoints utiles : POST /api/search/metadata (avec withExif: true pour obtenir dateTimeOriginal), GET /api/timeline/buckets?size=MONTH (comptage par mois — le seul moyen fiable d'obtenir des totaux, total dans la recherche ne renvoyant que le compte de la page), GET /api/assets/statistics.
Les deux photos datees de l'an 4501 — corrigees le 2026-08-28
Symptome decrit par Julien : « j'ai beau reformater, cette date ridicule revient ».
Cause : les deux fichiers proviennent d'un scanner de film Nikon LS-5000 (SF-Nikon / LS-5000), dont le logiciel a inscrit 4501:01:01 comme date de prise de vue dans le fichier lui-meme. La bibliotheque etant externe, Immich relit le fichier a chaque analyse et ecrase toute correction faite dans l'interface. Corriger dans Immich ne pouvait pas tenir — il fallait traiter la source.
Le PNG cachait la date a deux endroits, ce qui explique qu'une correction partielle aurait echoue :
BOITE09_0061.jpgDateTimeOriginal4501:01:01 00:00:00BOITE09_0068.pngzTXtBOITE09_0068.pngiTXtexif:DateTimeOriginal="4501-01-01T00:00:00+01:00"Methode — script Jux-scripts/Photos-Caesium/corriger_date_exif.py, stdlib seule :
45011979zTXtiTXtos.replaceCorrige aux deux emplacements : sur le montage kDrive du VPS (/home/debian/photo, ce que lit Immich) et sur le NAS pour le JPEG (/volume1/photo/...), le PNG n'existant que cote kDrive. Sauvegardes dans /home/debian/backup_4501/ et /volume1/homes/SAS_NEXTE/backup_4501/.
Relecture par Immich : le mtime ayant ete volontairement preserve, l'analyse de bibliotheque ne detecte aucun changement. Il faut donc forcer la relecture :
POST /api/assets/jobs {"assetIds": [...], "name": "refresh-metadata"}
Resultat : les deux photos sont datees du 1er janvier 1979, et plus aucun element de la bibliotheque n'est date apres 2100.
10. Le script de production
Jux-scripts/Photos-Caesium/compress_photos_nas.py — stdlib seule, deploye sur le NAS dans /volume1/homes/SAS_NEXTE/scripts/.
python3 compress_photos_nas.py [--source CHEMIN] [--parallele CHEMIN]
[--profil q80|q90|sans-perte] [--minutes N]
[--simulation] [--reprendre]
Choixrefuse de conception :
caesiumclt-Rgeteuid-R@eaDir.jpg.jpegFF D8~/.photos_caesium_etat.json--reprendre--minutes/volume1/homes/SAS_NEXTE/logs/photos_caesium_AAAAMMJJ.logMesure sur les vieux scans familiaux (466 fichiers, 22 dossiers) : -28,6 % seulement, a 0,82 Mo/s. Bien loin des -59,5 % du tirage aleatoire — ces scans anciens sont de petits fichiers deja compresses, et le surcout par fichier domine. Le gain reel sera donc tres inegal selon les albums : fort sur les photos recentes de telephone, faible sur les numerisations anciennes.
PROCÉDURE
La RETENUE — reprise du stock photo en quatre étapes
Définie par Julien le 2026-08-28. Elle remplace la recommandation directe des sections 6 à 8règle : on n'attaque plus le stock au fil de l'eau, on inventorie, on statue, on valide, puis on écrase.
Le principe
Onne compresse pas une photoqui n'en a pas besoin.
Règle opérationnelle : tout fichier de moins de 2 Mo
est écarté.
Aucun bénéfice à recompresser une numérisation ancienne de 700 Ko pour lui gagner 80 Ko, au prix de la réécriture d'un fichier irremplaçable.
Justification chiffrée du seuil
| Seuil | Fichiers à traiter | Poids couvert | Gain estimé | Durée |
|---|---|---|---|---|
| 1 Mo | 12 253 (74,6 %) | 95,6 % | 21,6 Go | 6,6 h |
| 2 Mo | 9 077 (55,3 %) | 82,4 % | 18,6 Go | 5,7 h |
| 3 Mo | 4 839 (29,5 %) | 55,4 % | 12,5 Go | 3,8 h |
À 2 Mo on écarte 45 % des fichiers pour seulement 18 % du poids. Descendre à 1 Mo ajouterait 3 Go de gain contre 3 176 fichiers supplémentaires ; monter à 3 Mo sacrifierait 6 Go pour n'économiser que deux heures. Le seuil de 2 Mo est le point d'équilibre.
Effet secondaire heureux, vérifié à l'inventaireheureux : les albums de numérisations anciennes sortent d'eux-mêmes du périmètre. 1967 à 2000 - photos famille Bertrand (536 images, 2,62 Go) et 2005 - naissance Elio (869 images) ont zéro fichier à traiter. La règle protège le patrimoine le plus fragile sans qu'on ait eu à le désigner.
ÉtapeCe qui est garanti
EXIF, GPS, dimensions
Vérifié sur les fichiers du NAS puis, après la bascule du 2026-09-28, sur les photos réellement écrasées : bloc EXIF identique à l'octet près, IFD GPS présent et coordonnées au chiffre près, dimensions inchangées, jeu complet d'étiquettes (72 sur un Xiaomi 15T Pro, 54 et 45 sur des photos plus anciennes).
Cela dépend entièrement de l'option -e, qui n'est pas le défaut de Caesium — voir l'incident du 14 juillet en page 284, qui a coûté le GPS de 275 photos.
La date de modification, et pourquoi elle compte
Immich construit sa chronologie à partir du DateTimeOriginal EXIF quand il existe, et du mtime du fichier quand il n'existe pas — cas des images WhatsApp, des captures d'écran et des scans. 1 853 photos, soit 10,5 % du stock, sont dans ce cas (colonne origine_date de la base).
Les deux scripts ne se reposent donc pas sur --keep-dates : ils relèvent mtime, atime, uid, gid et permissions avant traitement, les réimposent par os.utime / os.chown / os.chmod, puis relisent le fichier et lèvent une exception si le mtime a bougé d'une seconde. Assertion vérifiée fichier par fichier.
Preuve : 26 photos témoins, dates identiques à la seconde, propriétaire restauré, originaux intacts. Le contrôle intégré a d'ailleurs détecté 26 écarts lors d'un essai en non-privilégié, contre 0 en root — c'est lui qui a établi l'obligation du sudo.
Ce que la procédure apporte face à une compression au fil de l'eau
Où en est le chantier
Inventaire du 2026-09-28 : 17 715 images, 41,41 Go, dont 9 014 à retraiter (30,80 Go) et 8 701 écartées (10,61 Go). 417 vidéos (21,22 Go) sont mises de côté pour un chantier ultérieur.
Lots basculés
2022 (4 albums)
359
1 501 Mo
518 Mo
983 Mo
2026/2026-Automne
22 (+1 refusée)
94,05 Mo
46,44 Mo
47,6 Mo
Total
381
1 031 Mo
Reste à faire
a_traiter — le gros du gisement
1,75 Go de doublons à arbitrer à la main (252 photos renommées + 1 La base est actualisée chaque nuit
Une photo ajoutée après le dernier inventaire est invisible de traiter_lot_nas.py, qui travaille à partir de la base. C'est exactement ce qui s'est produit le 2026-08-28)09-28
Scriptavec l'album 2026-Automne à Noel, créé après l'inventaire du 28 août : il a fallu reconstruire la base avant de pouvoir le traiter.
D'où une tâche nocturne, posée le 2026-09-28.
Jux-/volume1/homes/SAS_NEXTE/scripts/Photos-Caesium/inventaire_photos_nas.pyinventaire_nuit.shSAS_NEXTE
python3bash /volume1/homes/SAS_NEXTE/scripts/inventaire_photos_nas.pyinventaire_nuit.sh[--seuil-mo
/volume1/homes/SAS_NEXTE/logs/inventaire_nuit.log, rotation à 2 Mo
DuréeUtilisateur SAS_NEXTE, surtout pas root : l'inventaire ne fait que lire /volume1/photo, et en root les fichiers produits appartiendraient à root — un lancement manuel ultérieur échouerait alors à les écraser.
Trois protections, parce que personne ne regarde tourner une tâche de nuit
kill -0) et non sur ps, dont la sortie est tronquée sur DSM.
La base n'est plus supprimée avant reconstruction. Elle est bâtie dans photos.sqlite.tmp puis remplacée à la fin par os.replace, après sauvegarde rotative sur 7 jours (photos_j1.sqlite à photos_j7.sqlite). Vérifié : un plantage en cours de route laisse la base et le suivi de validation intacts, sans .tmp résiduel.
⚠⚠ Refus d'écrire sur source vide. Zéro image trouvée = refus et code 2. Un soir où /volume1/photo ne serait pas monté, un inventaire vide écraserait sinon la base — et avec elle le suivi des lots en cours de validation. Même principe que le refus de source vide de sync_kdrive_complete.sh.
Le canari du matin la surveille
Entrée inventaire dans la section nas de Etat-Infra/config.json (max_heures: 30, attendu BILAN NUIT: OK). La sonde est greffée sur la session SSH que la vérification NAS ouvre déjà — aucune connexion supplémentaire. Elle alerte si le journal est absent, vieux de plus de 30 h, ou si le dernier bilan est en échec ; muette le reste du temps.
L'inventaire conserve le suivi des lots lors d'une reconstruction. Statuts, lots, tailles obtenues et dates de traitement sont reportés depuis la base précédente pour toute photo dont le chemin n'a pas changé. Sans cela, le passage nocturne effacerait chaque nuit l'avancement des lots en validation.
Annexe — la base et les statuts
Sorties dans /volume1/homes/SAS_NEXTE/inventaire/, accessibles en SMB sous \\10.0.0.2\home\inventaire\ :
photos.csv photos.sqlite videos.csv, resume.txt.
Colonnes de la table photos
: album, chemin, nom, format, octets, mo, date_prise_vue, origine_date, date_modif, largeur, hauteur, appareil, gps_lat, gps_lon, a_traiter, motif_ecart, empreinte, doublon_de, quasi_doublon, statut, lot, octets_apres, date_traitement.
origine_dateestLes lachemins colonnesont ajoutéerelatifs à la suite de l'analyse Immich/volume1/photo (section2022-hiver 9)à : elle vaut exifPaques/IMG….jpg quand la photo porte un DateTimeOriginalmtimequandest Immichle doitpremier se rabattre sur la datesegment du fichier. Ces dernières sont les seules dont la place dans la chronologie dépend de la préservation du mtime. 2 123 photos, soit 11,9 % du stock, sont dans ce cas.
Détection des doublons
Deux mécanismes, tous deux en stdlib :
DateTimeOriginalRésultat de l'inventaire
mtime
Les 1 334 doublons exacts sont un gain gratuit: 1,93 Go libérables par simple suppression, sans toucher à un seul pixel. À traiter en premier, c'est sans risque et instantané.
Étape 2 — Statuer sur la base
Julien et Cécile examinent l'inventaire et arrêtent la liste définitive. La colonne a_traiter porte la proposition automatique issue du seuil ; elle se corrige à la main.
Requêtes utiles sur photos.sqlite :
-- ce qui sera traité, par album
SELECT album, count(*) AS n, round(sum(mo)/1024, 2) AS go
FROM photos WHERE a_traiter = 1 GROUP BY album ORDER BY go DESC;
-- les doublons exacts, à supprimer avant toute compression
SELECT chemin, doublon_de, mo FROM photos WHERE doublon_de <> '' ORDER BY mo DESC;
--toutes les photos dont la chronologie Immich dépend du mtime
SELECT album, count(*) FROM photos WHERE origine_date = 'mtime' GROUP BY album;
-- exclure un album entier du traitement
UPDATE photos SET a_traiter = 0, motif_ecart = 'exclu manuellement' WHERE album = '...';
Étape 3 — Traitement dans un dossier de validation
Destination retenue : /volume1/homes/SAS_NEXTE/Photos/photos_reprise.
C'est l'espace photo personnel de SAS_NEXTE, indexé nativement par Synology Photos : la validation se fait donc dans l'application, en plein écran, et non en parcourant un partage SMB. C'est ce qui a fait écarter le dossier /volume1/julien16021972 envisagé d'abord — lequel n'existait pas et aurait demandé la création d'un dossier partagé.
Les originaux ne sont pas touchés à cette étape. Le traitement s'appuie sur compress_photos_nas.py en mode --parallele, qui reproduit l'arborescence des albums et préserve date, propriétaire et permissions (vérifié, section 9).
Points de vigilance :
@eaDir/home/debian/photo/volume1/photoÉtape 4 — Écrasement et mise à jour de la base
Julien et Cécile parcourent photos_reprisephoto/2026/<sous-album>/dans Synology Photos et suppriment les photos dont la qualité ne convient pas. Ce qui reste vaut validation.
Le refus estportent donc une suppression, et il ne demande aucune autre action. C'est ce qui rend la procédure sûre : une photo absente du dossier de validation au moment du rebasculement voit simplement son original conservé tel quel. L'inaction est le comportement par défaut, et c'est toujours le comportement sûr.
photos_reprise/volume1/photo
⚠ Toute l'étape 4 doit tourner en ROOT.Les photos appartiennent àadmin:users; exécutée sousSAS_NEXTE, l'opération les réattribuerait toutes et casserait l'accès SMB et Synology Photos. Vérifié en conditions réelles (section 9).
Travail par lots
Les 9 077 photos ne sont pas traitées d'un bloc. On avance par lots — un album ou une année à la fois (2006, 2007, 2012 - Eté…) — pour trois raisons :
Cadence naturelle : déposer un lot, le laisser à la validation, basculer, passer au suivant. Rien n'oblige à enchaîner — la procédure est faite pour s'interrompre.
Ce que le suivi par lots impose à la base
Travailler progressivement veut dire que la base doit savoir où en est chaque photo, sinon on perd le fil entre deux sessions. Colonnes de suivi à tenir dans photos.sqlite :
statuta_traiteren_validationvaliderefusebasculeecartelot2012 - Etéoctets_apresdate_traitementLe passage en_validation → valide ou refuse se déduit automatiquement : est validée toute photo encore présente dans photos_reprise au moment de la bascule, est refusée toute photo absente. Aucune saisie manuelle n'est nécessaire — le tri se fait dans Synology Photos, la base le constate.
C'est aussi ce qui rend l'ensemble reprenable : on peut relire à tout moment quels lots sont basculés, lesquels attendent, et quel gain cumulé a été obtenu.
Ce que la procédure apporte, par rapport à une compression au fil de l'eau
Nettoyage des doublons — fait le 2026-08-28
Script : Jux-scripts/Photos-Caesium/nettoyer_doublons_nas.py. Premier gain du chantier, obtenu sans compresser un seul pixel.
Ce que l'inventaire avait trouvé
945 groupes de fichiers identiques à l'octet près, soit 1 334 fichiers en trop, 1,93 Go. Il aurait été tentant de tout supprimer. C'eût été une faute, et l'analyse préalable l'a montré.
Pourquoi les doublons inter-albums ne se suppriment pas
La combinaison la plus lourde était 1930-2016 - Photos BERTRAND MER + 2016-best photos pour 70 ans — 516 fichiers. Ce n'est pas un accident : c'est une sélection faite pour les 70 ans, qui puise dans l'archive familiale. Supprimer les doublons aurait vidé l'album de son contenu. Même schéma pour 2016 - 70 ans Maman + 2016- photos Maman Papa2026 (48 fichiers) et plusieurs autres lignes touchant « best photos ».
Un doublon réparti entre deux albums n'est pas forcément une erreur — c'est souvent une intention.Ne jamais dédoublonner sur le seul critère de l'empreinte.
Le critère de conservation : la relation de préfixe
Un suffixe de copie est toujours ajouté au nom d'origine. Donc : si l'un des noms d'un groupe est un préfixe strict de tous les autres, c'est l'original. Ce critère est structurel, sans heuristique, et couvre tous les cas rencontrés :
GARDE IMG_0952.JPG
ecarte IMG_0952_NASMAISON_Oct-01-180016-2024_conflict_current.JPG
ecarte IMG_0952_NASMAISON_Oct-01-180254-2024_conflict_current.JPG
ecarte IMG_0952_..._conflict_current_..._conflict_current.JPG (x7 au total)
Les conflits Syncthing sont le principal pourvoyeur, avec des cascades — chaque résolution ratée ajoutant son suffixe au précédent. Un fichier existait en sept exemplaires.
Deux pièges rencontrés, à ne pas refaire
1. _\d+$ est un mauvais marqueur de copie. Cette règle, qui paraît évidente, prend les numéros d'appareil photo pour des suffixes : IMG_0322, 20190830_221854, Cess_IMG_20240506_120512 sont tous signalés à tort. Elle ne donnait le bon résultat que par accident, via le départage sur la longueur du nom. Supprimée au profit du critère de préfixe. Le garde-fou intégré au script (« fichiers conservés portant encore un marqueur de copie ») est ce qui l'a révélée — un contrôle qui accuse son propre auteur mérite d'être écrit.
2. Le suffixe Windows français est « - Copie », avec des espaces autour du tiret. Une expression du type [-_](copie|copy)$ ne l'attrape pas. Motif correct : \s*[-_]\s*(copie|copy)(\s*\(?\d+\)?)?\s*$.
Le mode prudent
Restaient 264 groupes où le même cliché existe sous deux noms sans lien :
20150808_185538.jpg ←→ Croatie_août_2015_142.jpg
Le contenu est identique ; choisir le nom qui survit est une décision humaine, pas technique — quelqu'un a pris la peine de renommer ces photos. Décision de Julien : « la règle la plus prudente, tant pis s'il reste des doublons. » Le script s'abstient donc par défaut sur tout groupe sans relation de préfixe ; --inclure-ambigus force le contraire, et est déconseillé.
Résultat
/volume1/homes/SAS_NEXTE/doublons_ecartesrm -rfmotif_ecarta_traiterSeconde passe : les fichiers de conflit Google Drive (2026-08-28)
Parmi les doublons laissés en attente, Julien a tranché un cas : « on peut traiter comme doublon tous ceux qui portent la mention (conflit) ». C'est fondé — un fichier nommé Copie de P1060905 (conflit du 19-03-2018 à 00h18).jpg est un artefact logiciel, jamais un fichier déposé volontairement. Il ne peut donc pas relever d'une sélection, contrairement aux doublons inter-albums.
Ces 24 fichiers avaient échappé aux deux passes précédentes pour une raison structurelle : le nom encadre l'original au lieu de le suffixer — Copie de devant, (conflit du …) derrière. Le critère de préfixe, qui suppose un suffixe ajouté, ne pouvait pas les voir. D'où une passe dédiée, --conflits, indépendante des règles d'album.
Garde-fou indispensable, et il a servi : un fichier de conflit n'est écarté que s'il subsiste dans son groupe au moins un exemplaire qui n'en est pas un. Six fichiers se trouvaient dans des groupes où tous les exemplaires étaient des copies de conflit :
Copie de 20140424_114612 (conflit du 19-03-2018 à 00h12).jpg (deux fois, dossiers différents)
Les supprimer aurait fait disparaître la photo. Ils sont restés en place.
Résultat de la passe : 24 fichiers écartés, 6 laissés intacts, zéro erreur.
Bilan cumulé du nettoyage
_1 - Copie--conflitsContrôle après chaque passe : 75 originaux toujours en place, 75 copies en quarantaine, 0 manquant. Aucune photo perdue.
Ce qui reste en attente d'un arbitrage
Ces 1,75 Go ne se récupèrent qu'en tranchant album par album, à la main. La commande de départ :
SELECT chemin, doublon_de, mo FROM photos WHERE doublon_de <> '' ORDER BY mo DESC;
Les fichiers « (conflit) » sont les ORIGINAUX — découverte du 2026-08-28
À retenir avant toute suppression de fichiers de conflit. Sur ce stock, un fichier nommé Copie de X (conflit du 19-03-2018 à …).jpg est la meilleure version de la photo, et le fichier au nom propre qui porte le même nom de base est une recompression dégradée. C'est l'inversepourquoi de ce que le nom suggère. Vérifié sur 12 paires : dans 10 cas sur 12, la version « conflit » l'emporte nettement.
La mesure
Comparaison objective par la table de quantification JPEG (segment DQT) : plus la somme de ses valeurs est basse, moins l'image a été dégradée à l'encodage. À dimensions rigoureusement identiques :
2014-mur effondré/20141129_1101192014-mur effondré/20141129_1012322016-Crete/12134705image00272016-Crete/16133120image00452016-Parc Vert Coteau/20160130_231252Trois indices concordants : la table de quantification (292 contre 700–1000), la taille (deux à trois fois plus lourd) et le bloc EXIF (14 à 20 ko contre 5 à 9 ko). Un événement de mars 2018 a réécrit ces photos en qualité réduite et relégué les originaux sous un nom de conflit.
Exceptions : 2016-Crete/14132257image0026, où les deux versions se valent (DQT 711 contre 736), et 2024/2024-Via Reggio/IMG20240503174633…_conflict_current.jpg, qui n'a pas de jumeau — simple renommage.
Le garde-fou qui a évité le pire
La consigne initiale était : « on peut traiter comme doublon tous ceux qui portent la mention (conflit) ». Appliquée à la lettre, elle aurait détruit la meilleure version de dix photos. Ce qui les a sauvées est le garde-fou « n'écarter un conflit que s'il subsiste un exemplaire propre dans le groupe » — et il les a écartées du traitement pour une raison qui n'était même pas la bonne : ces paires n'étaient pas des doublons exacts, leurs octets diffèrent, donc elles n'ont jamais été appariées.
Leçon générale : un garde-fou conservateur protège aussi contre les erreurs qu'on n'avait pas prévues.
Décision en attente
Pour les dix paires : supprimer la version dégradée et rendre son nom d'origine à la version de conflit. Gain double — la qualité et un nom propre. C'est l'inverse de la consigne du matin, donc rien n'est fait sans arbitrage. Reporté par Julien.
Outils prêts, aucun n'a été exécuté en écriture :
renommer_conflits.pyCopie de …(conflit du …)comparer_versions.pyReconstruction de l'inventaire après tri manuel
Julien a trié à la main, surtout sur 2014. Base reconstruite le 2026-08-28 à 09:30, en 5 min 21 s.
Sur les 160 images en moins, 75 sont les mises en quarantaine automatiques — 85 relèvent du tri manuel, dont 79 doublons.
Restructuration notable : l'album 2014 (256 images, 0,50 Go) a été dissous, son contenu réparti dans les sous-albums de l'année (2014-Hiver Printemps 46 → 149, 2014- été 119 → 166, 2014 - Automne Noel 22 → 53). Et le doublon d'arborescence 2014/Avril 2014/2014-Barcelone a été vidé au profit de 2014-Barcelone — ce qui a résolu du même coup les trois photos de conflit orphelines signalées plus haut.
L'inventaire précédent est conservé dans /volume1/homes/SAS_NEXTE/inventaire/ sous photos_precedent.sqlite et resume_precedent.txt. Toujours en faire une copie avant de relancer inventaire_photos_nas.py : c'est le seul moyen de mesurer l'effet d'un tri manuel.
La chaîne d'outils, terminée le 2026-08-28
Cinq scripts dans Jux-scripts/Photos-Caesium/, stdlib seule, déployés sur le NAS dans /volume1/homes/SAS_NEXTE/scripts/. Ils correspondent un pour un aux étapes de la procédure.
inventaire_photos_nas.pynettoyer_doublons_nas.pytraiter_lot_nas.pybasculer_lot_nas.pycomparer_versions.pyLe cycle d'un lot
# voir les lots disponibles et leur poids
python3 traiter_lot_nas.py --lot X --lister
# etape 3 : compresser vers le dossier de validation (originaux non touches)
python3 traiter_lot_nas.py --lot 2022 --minutes 300
# -> Julien et Cecile ouvrent photos_reprise dans Synology Photos
# -> ils SUPPRIMENT les photos qui ne conviennent pas
# etape 4 : simulation, puis ecrasement
python3 basculer_lot_nas.py --lot 2022
sudo python3 basculer_lot_nas.py --lot 2022 --go
--lot estaccepte aussi un préfixe d'album : 2022 prend 2022 - été Flandres NL Paris, 2022-hiver à Paques, 2022-automne a Noel et 2022-Noel. Un nom d'album complet fonctionne aussi bien, pour un lot plus fin.chemin.
Les statuts
| Statut | Signification |
|---|---|
a_traiter |
retenue par le seuil, pas encore compressée |
ecarte |
sous le seuil, ou format non pris en charge |
en_validation |
compressée, en attente du jugement dans Synology Photos |
bascule |
validée et écrasée — octets porte la nouvelle taille |
refuse |
supprimée du dossier de validation : original conservé |
sans_gain |
la compression n'apportait rien, original conservé |
Requêtes Leutiles refus:
-- demandece aucunequi action.sera Unetraité, photopar absentealbum
SELECT album, count(*) AS n, round(sum(mo)/1024, 2) AS go
FROM photos WHERE a_traiter = 1 GROUP BY album ORDER BY go DESC;
-- où en sont les lots
SELECT lot, statut, count(*) FROM photos
WHERE lot IS NOT NULL AND lot != '' GROUP BY lot, statut;
-- les photos dont la chronologie Immich dépend du mtime
SELECT album, count(*) FROM photos WHERE origine_date = 'mtime' GROUP BY album;
-- exclure un album entier du traitement
UPDATE photos SET a_traiter = 0, motif_ecart = 'exclu manuellement' WHERE album = '...';
La chaîne d'outils
Six scripts dans Jux-scripts/Photos-Caesium/, stdlib seule, déployés sur le NAS dans /volume1/homes/SAS_NEXTE/scripts/.
inventaire_photos_nas.py
1
recense tout, détecte les doublons, propose la sélection
inventaire_nuit.sh
1
lanceur nocturne : verrou, journal, bilan pour le canari
nettoyer_doublons_nas.py
1 bis
écarte les doublons certains, en quarantaine
traiter_lot_nas.py
3
compresse un lot vers le dossier de validation
basculer_lot_nas.py
4
écrase les originaux validés, constate les refus
comparer_versions.py
—
compare la qualité de Garde-fous intégrés
traiter_lot_nas.py appelle caesiumclt sans -R, dossier par dossier @eaDir ne peut être FF D8, taille inférieure) avant --minutes, reprise en relançant la même commande.
Annexe — les correctifs du 2026-09-28
La chaîne n'avait jamais été jouée jusqu'à la bascule. Six défauts, tous découverts en conditions réelles, tous dormant depuis le 28 août.
⚠⚠ basculer_lot_nas.pyos.replace()Errno 18, Invalid cross-device link — refuse359 échecs d'un coup. Chaque partage DSM est un sous-volume Btrfs distinct : /volume1/homes et /volume1/photo sont deux devices pour le noyau, malgré le /volume1 commun. remplacer() copie désormais vers un tampon .nouveau créé à côté de s'exécuter sans rootl'original (geteuid)même sous-volume), avecy pose permissions, propriétaire et dates, puis os.replace — atomique. Le fichier de validation n'est supprimé qu'après succès et vérification du mtime. Aucun dégât : le try/except a tenu, les 359 originaux et la base sont restés intacts.
⚠ Le bilan annonçait un messagesuccès expliciteaprès un échec total : « 983,47 Mo récupérés » s'affichait sous « 0 original remplacé, 359 échecs », parce qu'il additionnait le gain théorique du lot. Un bilan qui ment ainsi est pire qu'une absence de bilan. Le gain est désormais compté photo par photo au moment du succès, et tout échec déclenche une ligne disant explicitement que les originaux sont inchangés.
⚠ --lot ne savait viser qu'une année entière : les photoscinq appartiennentsous-albums de 2026 étaient fondus dans un lot 2026 de 115 photos. Le filtre porte maintenant sur l'album ou le chemin, et --lister groupe sur les deux premiers segments. Rétrocompatible.
⚠ --lister exigeait --lot, alors qu'il sert précisément à découvrir quoi passer à admin:users--lot
⚠ Les messages de fin donnaient des commandes inutilisables — python3 basculer_lot_nas.py … sans chemin, sans sudo, sans --go, d'où un « No such file » depuis le répertoire personnel. Chemins absolus et trois étapes numérotées désormais.
⚠ purger_vides() ne supprimait jamais rien : Synology dépose un @eaDir de vignettes dans chaque dossier, compté comme du contenu par os.listdir(). photos_reprise gardait donc l'apparence de lots encore en attente de validation. @eaDir et Thumbs.db sont maintenant ignorés, puis emportés avec le dossier.
Annexe — les doublons
L'inventaire a trouvé 1 334 doublons exacts (1,93 Go) et 1 278 quasi-doublons. Méthode : SHA-256 intégral mais calculé uniquement entre fichiers de taille identique — 2 360 candidats sur 17 835, ce qui évite de hacher 41 Go. Les quasi-doublons sont repérés par DateTimeOriginal + dimensions identiques.
Sur les 1 334, seuls 75 ont été écartés (190 Mo, en quarantaine dans /volume1/homes/SAS_NEXTE/doublons_ecartes, jamais effacés directement).
⚠ Un doublon inter-albums n'est pas une erreur, c'est souvent une intention
1930-2016 - Photos BERTRAND MER et 2016-best photos pour 70 ans partagent 516 fichiers identiques : c'est une sélection faite pour un anniversaire. Les supprimer aurait vidé l'album. Ne jamais dédoublonner sur la seule empreinte — 1 018 fichiers laissés intacts pour cette raison.
Le critère de conservation : la relation de préfixe
Un suffixe de copie est toujours ajouté au nom d'origine. Si un nom du groupe est préfixe strict de tous les autres, c'est l'original. Structurel, sans heuristique. Couvre _1, - Copie, et les cascades de conflits Syncthing (un fichier laisséexistait en 7 exemplaires).
Deux pièges à ne pas refaire :
SAS_NEXTE_\d+$IMG_0322, 20190830_221854). Il ne donnait le bon résultat que par accident. Retiré.
« qui- porteCopie la» DateTimeOriginal[-_](copie|copy)$\s*[-_]\s*(copie|copy)(\s*\(?\d+\)?)?\s*$.
Mode L'inventaireprudent conservepar défaut (décision de Julien : « la règle la plus prudente, tant pis s'il reste des doublons ») : un groupe sans relation de préfixe n'est pas traité. 264 groupes de photos renommées (20150808_185538.jpg ↔ Croatie_août_2015_142.jpg, 0,60 Go) laissés en l'état — choisir le suivinom qui survit est une décision humaine.
Seconde passe --conflits : 24 fichiers de plus. Le nommage Google Drive français Copie de P1060905 (conflit du 19-03-2018 à 00h18).jpg encadre l'original au lieu de le suffixer, donc le critère de préfixe ne pouvait pas le voir. Garde-fou : on n'écarte un conflit que s'il subsiste un exemplaire propre dans le groupe — 6 fichiers laissés en place car tous les exemplaires de leur groupe étaient des lotscopies lorsde d'conflit.
Annexe — ⚠⚠ les fichiers « (conflit) » sont les ORIGINAUX
Contre-intuitif, et vérifié : sur ce stock, un Copie de X (conflit du …).jpg est la meilleure version, et le fichier au nom propre portant le même radical est une reconstruction.recompression dégradée.
Mesuré sur 12 paires par la table de quantification JPEG (DQT — somme basse = moins dégradé) : 10 cas sur 12 donnent la version conflit gagnante, avec un DQT de 292 contre 700 à 1 000, une taille 2 à 3 fois supérieure et un bloc EXIF trois fois plus riche, à dimensions rigoureusement identiques. Un événement de mars 2018 a réécrit ces photos en qualité réduite.
La consigne « supprimer tout ce qui porte (conflit) » aurait détruit la meilleure version de 10 photos. Ce qui les a sauvées : le garde-fou « n'écarter un conflit que s'il subsiste un exemplaire propre dans le groupe » — et il les a écartées pour une raison qui n'était pas la bonne (leurs octets diffèrent, elles n'étaient donc pas des doublons exacts). Un garde-fou conservateur protège aussi contre les erreurs qu'on n'avait pas prévues.
Décision en attente : remplacer les versions dégradées par les versions de conflit et leur rendre leur nom. Outils prêts, jamais exécutés en écriture : comparer_versions.py (comparaison DQT) et renommer_conflits.py (retire l'encadrement, ne renomme que si le nom cible est libre).
Annexe — pièges SSH et DSM
Une bannière SSH qui répond ne prouve pas que l'accès soit ouvert. Le port 22 renvoyait SSH-2.0-OpenSSH_8.2, annonçait publickey,password et évaluait les identifiants avant de les rejeter — ce qui a conduit à soupçonner à tort le groupe administrators, puis la vérification en deux étapes. Les deux hypothèses étaient fausses : le service était désactivé et le port fermé par les règles DSM.
Le compte Unix est SAS_NEXTE en majuscules (uid 1026), alors qu'on s'y connecte en sas_nexte. DSM est insensible à la casse à l'ouverture de session, mais le dossier personnel et le propriétaire des fichiers portent la forme majuscule.
Le § du mot de passe ne survit pas à Git Bash → plink. Le construire côté cible en octets explicites :
printf 'xAPIJU5108\xc2\xa7' > /tmp/pw
sshpass -f /tmp/pw ssh -o NumberOfPasswordPrompts=1 sas_nexte@10.0.0.2
-o NumberOfPasswordPrompts=1 est important : sans lui, un échec compte pour trois tentatives auprès du blocage automatique de DSM.
Autres pièges :
scp échoue (dest open: No such file or directory) — DSM n'expose pas de sous-système SFTP. Transférer par un tube : ssh nas 'cat > cible' < source.
/tmp est monté noexec : un binaire y est marqué exécutable mais refuse de démarrer. Les /volume1.
ps w tronque sa sortie sur DSM : un grep dessus a répondu 0 alors que le processus tournait, ce qui a conduit à lancer une seconde copie sur la même destination. Tester la vivacité par ps -eo pid,sid,args, ou par PID.
nohup ne suffit pas à détacher un script lancé par SSH : utiliser setsid script.sh < /dev/null > /dev/null 2>&1 &.
Authentification par clé non aboutie : clé publique déposée dans ~/.ssh/authorized_keys (intacte, vérifiée), toujours refusée — probablement StrictModes, qui rejette un dossier personnel accessible en écriture au groupe, ce que Synology crée par défaut. Clé privée en D:\SSH\nas_sasnexte, hors arbre Syncthing.
Annexe — Immich, ce qu'il faut savoir d'ici
Immich lit /home/debian/photo sur le VPS — le miroir kDrive de /volume1/photo — et datesignore les dossiers personnels : le dossier de validation ne l'affecte donc pas. Bibliothèque externe 89bfcdc1-1604-47a1-90a3-975d2f6c4639, chemin /mnt/media/photo. Relecture après traitement sont: reportésresynchronisation depuispuis POST /api/libraries/{id}/scan.
Il n'existe pas de MCP Immich dans ces sessions (perdu avec le profil eliob). Passer par l'API : POST /api/auth/login → JWT, puis POST /api/search/metadata (withExif: true, accepte isOffline, originalFileName, takenAfter/takenBefore, pagine par nextPage) et GET /api/assets/statistics.
⚠ GET /api/timeline/buckets?size=MONTH est le seul moyen fiable d'obtenir des totaux : le champ total de la baserecherche précédentene pourrenvoie touteque photole compte de la page courante.
Bibliothèque au 2026-08-28 : 18 156 éléments, dont 2 datés de l'an 4501 — des scans du Nikon LS-5000 dont le cheminfichier n'aportait pasune changé.date Sansaberrante, cela,corrigés undepuis simpleà tri1979. manuelRécit suivi d'un inventaire_photos_nas.py effacerait l'avancement de tous les lots déjà traités.
Premier lot lancécomplet : 2022
page 164.
Annexe — la machine et le stock
2022 - été Flandres NL Paris2022-hiver/volume1/homes/SAS_NEXTE/bin/caesiumcltx86_64-unknown-linux-musl
Le binaire musl est statique et sans aucune dépendance : il s'exécute nativement sur DSM, sans Docker ni Entware.
Composition de /volume1/photo au relevé initial :
2022-automne@eaDir2022-NoelChoisi⚠ commeAttention galopau d'essairecensement naïf : un find … -iname '*.jpg' sans exclure @eaDir compte 71 802 fichiers au lieu de 16 422, parce qu'il ramasse les vignettes. Un échantillon constitué ainsi fausse gravement la taille moyenne.
Annexe — pourquoi le NAS et pas le PC
Le PC est sept fois plus rapide (11,4 Mo/s contre 1,55 sur le J4025), mais le tunnel WireGuard est en étoile via le VPS et plafonne à 4,01 Mo/s. Faire passer 53 Go de lecture et de réécriture y prendrait plus de quatre heures en saturant le lien, PC allumé. Le NAS travaille la nuit, gratuitement.
Cet arbitrage vaut pour sale taillestock complet. Sur un lot de quelques dizaines de mégaoctets, le calcul s'inverse — mais la procédure de validation, elle, reste la même.
Points de vigilance permanents
1. La sauvegarde. sync_kdrive_complete.sh ne synchronise que /volume1/photo/2026 vers kDrive, et en miroir (rclone sync --delete-during). Les JPEG de 1967 à 2025 n'ont aucune copie hors du NAS par cette voie. Une archive Hyper Backup (NEXTE_1.hbk) tourne chaque nuit, mais son périmètre exact n'a pas été confirmé. À établir avant toute réécriture de masse.
2. La compression sur place est irréversible. Le profil q80 est un ré-encodage. C'est toute la raison d'être de l'étape de validation.
3. Ne jamais toucher aux @eaDir. Les compresser casserait Synology Photos, qui les régénérerait aussitôt.
4. Synology Photos indexe le dossier de validation et génère ses vignettes : 359comptez photosdu temps machine et quelques gigaoctets de @eaDir supplémentaires, restitués dès le dossier vidé. Hyper Backup le sauvegardera aussi la nuit suivante — gonflement temporaire, résorbé après la bascule.
5. HEIC et vidéos restent confortableshors àde parcourirportée. àPour deux.les Levidéos, lotle 2023,levier avec ses 891 photos, aurait été trop lourd pourserait un premierré-encodage jugement.H.265 : un tout autre chantier, très au-delà d'un J4025.
Voir aussi
- Page 284 — la procédure Photos-Caesium sur le PC, dont celle-ci reprend le moteur et les réglages
- Page 164 — Immich : réparation des dates après l'incident du
-emanquant