Skip to main content

261001-les playlistes de Claude sur Navidrome

En une phrase

AudioMuse-AI écoute réellement les morceaux (analyse sonore, pas les tags), les regroupe par parenté musicale, fait nommer les groupes par Gemini, et dépose le résultat en playlists dans Navidrome — où elles restent, même PC éteint.

1. Pourquoi sur le PC, et nulle part ailleurs

AudioMuse n'est pas un greffon : c'est une pile d'analyse (Flask + worker ONNX + PostgreSQL embarqué, 2,4 Go installés) qui exige AVX2 et 8 Go de RAM.

Machine AVX2 RAM disponible Verdict
NAS sasnexte non — Celeron J4025 0,6 Go éliminé, ne démarrera jamais
jux-debian non — même CPU hôte 3 Go éliminé, même raison
VPS Jux oui (Haswell, 6 cœurs) 2,5 Go, swap à 4,9/8 Go trop juste
PC julie oui — Ryzen 5 2600X, 12 threads 16 Go retenu

L'absence d'AVX2 sur le J4025 est définitive : ni le NAS ni la VM qui tourne dessus ne pourront héberger AudioMuse, quelle que soit la version.

2. Ce que le PC éteint change — et ne change pas

Point vérifié dans le code (tasks/mediaserver/navidrome.py) et non supposé : AudioMuse crée les playlists dans Navidrome, par l'API Subsonic (createPlaylist, puis updatePlaylist public=true). Elles vivent donc dans la base du VPS, comme si elles avaient été faites à la main.

PC allumé PC éteint
Écouter les playlists (web, Symfonium, Feishin) oui oui
Fabriquer / rafraîchir les playlists oui non
Instant Mix & Radio (greffon .ndp) oui non

Le greffon Navidrome audiomuseai.ndp n'a pas été installé : il interroge AudioMuse en direct à chaque clic, donc il exige un service permanent — ce que le PC n'est pas. Seules les playlists nous intéressent, et elles n'en ont pas besoin.

3. Emplacement, et les deux pièges du poste

D:\AudioMuse-AI\
├── app\                      le bundle (PostgreSQL embarqué compris), 2,4 Go
├── donnees\AudioMuse-AI\     base, audio temporaire, modèles, journaux, secrets
├── sauvegardes\              dumps produits par sauvegarder_base.py
├── Demarrer AudioMuse.cmd
├── Arreter AudioMuse.cmd
└── sauvegarder_base.py

Hors de l'arbre Syncthing, volontairement : 1,5 Go d'archive et plusieurs Go de données n'ont rien à faire sur les 7 appareils du maillage, dont un téléphone. Même raison que D:\Procedures photos\ et D:\Musique\.

⚠ Piège n°1 — MSIX

native-build/windows/paths.py construit les chemins de données à partir de la variable d'environnement LOCALAPPDATA. Or Claude Code tourne dans un conteneur MSIX : tout processus lancé depuis une session Claude voit son %LOCALAPPDATA% redirigé vers …\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\. Lancé ainsi, AudioMuse installerait sa base dans un chemin fantôme — exactement l'incident Android Studio du 2026-08-26.

Demarrer AudioMuse.cmd force donc LOCALAPPDATA=D:\AudioMuse-AI\donnees avant d'appeler l'exécutable. Double bénéfice : hors périmètre de virtualisation, et hors du SSD système (95 Go libres, 146 arrêts brutaux au compteur, contre 596 Go sur D:).

C'est Julien qui lance, jamais Claude Code.

⚠ Piège n°2 — l'espace dans le chemin

Toujours dans paths.py : si le chemin de données contient une espace, AudioMuse bascule en silence vers %PROGRAMDATA%. Le lanceur vérifie et refuse de démarrer le cas échéant, plutôt que d'écrire ailleurs sans rien dire.

4. Mise en route

  1. Double-cliquer Demarrer AudioMuse.cmd. Au premier lancement, PostgreSQL s'initialise : compter 1 à 2 minutes. Le lanceur attend que le port 8000 réponde, puis ouvre le navigateur. Une icône apparaît dans la zone de notification (état, journal, arrêt).
  2. Dans l'assistant, serveur de musique : Navidrome, https://navidrome.juxjux.ovh, utilisateur julien, mot de passe Navidrome.
  3. Authentification AudioMuse : un identifiant, un mot de passe, un jeton d'API. Le jeton ne sert qu'au greffon (non installé) mais l'assistant l'exige.
  4. Première analyse — page Analysis and Clustering → Start Analysis.

Le coût de la première analyse

AudioMuse télécharge chaque morceau en entier par l'API Subsonic (download_track → stream), l'analyse, puis passe au suivant. Un seul fichier à la fois : rien ne s'accumule sur le disque. Mais au total ~133 Go transitent depuis le VPS (donc depuis kDrive), une seule fois.

Durée annoncée par le projet : « de quelques heures à plusieurs jours ». L'analyse est reprenable — les titres déjà traités sont en base, une interruption ne fait rien perdre — et incrémentale ensuite : un nouvel album ne coûte que sa propre taille.

5. Noms de playlists par Gemini

Il n'y a aucun greffon à installer : c'est de la configuration. Le modèle ne reçoit que des étiquettes de genre et d'humeur, jamais la musique ni les fichiers.

  1. Créer la clé (gratuite, sans facturation) sur aistudio.google.com → Clés API → Créer une clé API. C'est à Julien de le faire : Claude ne crée pas d'identifiants.
  2. AudioMuse → Administration → Configuration → Configuration avancée → Fournisseur d'IA & Nommage de playlist :
    • AI_MODEL_PROVIDER = GEMINI
    • GEMINI_API_KEY = la clé
    • GEMINI_MODEL_NAME = gemini-flash-latest — alias toujours à jour ; le défaut livré est gemini-2.5-pro, qui échoue souvent en version gratuite
  3. AI Prompt → Clustering Naming → style Titre complet de l'IA, et ajouter en fin de prompt la consigne de langue et de longueur (2 à 4 mots, sans underscore, jamais le mot « automatic »).
  4. Aperçu des titres teste sans rien enregistrer. Si les noms restent des étiquettes (no AI title so the tag name is kept), la clé ou le nom de modèle est faux.

Si Gemini cesse un jour de répondre, les playlists sont quand même créées, avec les anciens noms à base d'étiquettes.

6. ⚠ Le suffixe _automatic — à savoir avant de s'attacher à une playlist

Toute playlist produite se termine par _automatic. Au début de chaque clustering, AudioMuse appelle delete_automatic_playlists() qui supprime dans Navidrome toutes les playlists dont le nom finit par ce suffixe — y compris celles d'une exécution précédente. C'est voulu : il les recalcule.

Pour garder une playlist définitivement : la renommer dans Navidrome en retirant _automatic. Elle devient invisible de ce ménage et survit à tout, y compris à une réinstallation.

7. La base d'analyse, et sa sauvegarde sur kDrive

Son poids — calculé sur le schéma réel

Trois empreintes par titre, toutes en BYTEA float32 :

Empreinte Dimensions Octets/titre
MusiCNN (EMBEDDING_DIMENSION) 200 800
CLAP (CLAP_EMBEDDING_DIMENSION) 512 2 048
Paroles GTE (LYRICS_EMBEDDING_DIMENSION) 768 3 072
Métadonnées (score) — ~1 000

~7 Ko/titre × 16 069 ≈ 113 Mo de données brutes, que l'index de recherche (ivf_cell) double à peu près. Base vivante attendue : 250 à 350 Mo ; dump : 150 à 250 Mo.

⚠⚠ Pourquoi la base VIVANTE n'est pas sur kDrive

Demande initiale de Julien : « on mettra la base d'analyse dans le kDrive, on y a de la place, c'est pérenne ». L'objectif est le bon — cette base vaut des heures de calcul et 133 Go téléchargés — mais une base PostgreSQL vivante ne peut pas être posée sur kDrive : WebDAV n'offre ni fsync fiable, ni verrouillage de fichier, ni renommage atomique, et un fichier de base synchronisé pendant qu'il est ouvert se corrompt. C'est le mode de panne classique, pas une précaution théorique.

La pérennité s'obtient par un dump poussé sur kDrive — exactement le schéma de vps_backup.sh pour les 7 autres services. Restaurable sur n'importe quelle machine, et survit à un formatage.

Le script

py -3.12 D:\AudioMuse-AI\sauvegarder_base.py                 REM dump + envoi kDrive
py -3.12 D:\AudioMuse-AI\sauvegarder_base.py --simulation    REM dump local seulement
py -3.12 D:\AudioMuse-AI\sauvegarder_base.py --restaurer     REM recupere et reinjecte
  • AudioMuse doit tourner : le PostgreSQL embarqué n'écoute que pendant ce temps. Le script refuse poliment sinon.
  • Destination kDrive : SYNC-pour_VPS/backups/audiomuse, dossier id 1517484, créé le 2026-10-01 à côté des sept autres sauvegardes.
  • Un seul nom, audiomuse_base.dump, avec conflict=version : kDrive conserve lui-même les versions précédentes.
  • pg_dump -Fc (format personnalisé, déjà compressé), écriture atomique .partiel puis os.replace, et refus d'envoyer un dump de moins de 1 Ko — un dump vide ne doit jamais écraser un bon.
  • Au-delà de 900 Mo il bascule sur l'envoi par session et morceaux : l'upload simple de kDrive refuse au-delà de 1 000 000 000 octets (leçon du 2026-09-27). Ce seuil ne sera probablement jamais atteint ici, mais le chemin existe.
  • Identifiants PostgreSQL : utilisateur et base postgres sur 127.0.0.1:5432, mot de passe aléatoire lu dans donnees\AudioMuse-AI\secrets\pg_password.

8. Désinstallation

  1. Arreter AudioMuse.cmd
  2. Supprimer D:\AudioMuse-AI\

C'est tout : archive portable, rien dans Program Files, rien dans le registre, aucun service, aucun résidu dans %LOCALAPPDATA% puisque les données sont sur D:.

Les playlists déjà créées restent dans Navidrome — elles ne lui appartiennent pas. Seule disparaît la base d'analyse ; d'où le dump kDrive, qui permet de revenir sans refaire les 133 Go.

9. Repères

  • Version installée : v3.6.3 (2026-09-26), AudioMuse-AI-amd64-windows.zip, 1 588 225 001 octets, téléchargé en 187 s
  • Ports locaux : 8000 (interface), 8001 (contrôle), 5432 (PostgreSQL embarqué) — les trois vérifiés libres avant installation, tous sur 127.0.0.1
  • Portmaster : l'interface est en 127.0.0.1, couverte par la règle Allow Localhost. Rien à ouvrir, aucune connexion entrante
  • Le PC appelle navidrome.juxjux.ovh en sortant : rien à ouvrir sur la Livebox
  • Dépôt : https://github.com/NeptuneHub/AudioMuse-AI (AGPL-3.0)
Back to top