diff --git a/Blackboard/Done/openhome_queue_hybrid.md b/Blackboard/Done/openhome_queue_hybrid.md new file mode 100644 index 00000000..c7c32a67 --- /dev/null +++ b/Blackboard/Done/openhome_queue_hybrid.md @@ -0,0 +1,22 @@ +**Tu réaliseras ce travail en appliquant scrupuleusement les règles définies dans [@Rules.md](file:///Users/coissac/Sync/maison/Petite_maisons/src/pmomusic/Blackboard/Rules.md)** + + +Nous allons travailler spécifiquement et sur rien d'autre que la queue Open Home des Média Renderer dans la CRAT PMO Control. [@openhome.rs](file:///Users/coissac/Sync/maison/Petite_maisons/src/pmomusic/pmocontrol/src/queue/openhome.rs) + +Tu ne peux modifier que ce fichier et a priori tu n'as besoin de lire que ce fichier. + +Actuellement, cette queue est Stateless. C'est parfait, sauf sur un point, la gestion des métadonnées. En effet, les services OpenHome ne permettent pas de modifier les métadonnées d'une piste. Et cela m'ennuie. car mon control point ne peut pas mettre à jour les métadonnées d'une piste si elles sont changées par le média serveur + +Les items de la queue openhome sont identifiés par un ID. L'idée est de maintenir en cache dans la structure de queue Open Home une map qui lit cette ID avec des métadonnées. Je parle bien de l'ID open home de la track et pas de l'index (position) dans la queue de lecture. + +Tout le jeu consistera à enregistrer une copie des métadonnées dans cette map à partir de toutes les méthode du fichier [@openhome.rs](file:///Users/coissac/Sync/maison/Petite_maisons/src/pmomusic/pmocontrol/src/queue/openhome.rs) Qui accepte des PlaybackItem : + +- append_or_init_index +- replace_item +- sync_queue + +Inversement, à chaque fois qu'on retournera un playback item, On n'oubliera pas de renvoyer les métadonnées du cache plutôt que celles renvoyées par OpenHome. Peut-être qu'il est juste nécessaire de modifier playback_item_from_entry + +On profitera des appels réguliers à la fonction queue_snapshot Pour faire le ménage dans le cache en ne gardant que les entrées qui correspondent aux ID de la queue actuelle. + +Cela nous permettra de rajouter, une fonction d'update des métadonnées d'un item de la queue. Au niveau du backend open home, puis dans un second temps des autres backend de queue, puis du Média Renderer. diff --git a/Blackboard/Report/bug_update_cover_webui.md b/Blackboard/Report/bug_update_cover_webui.md new file mode 100644 index 00000000..ffe35b5a --- /dev/null +++ b/Blackboard/Report/bug_update_cover_webui.md @@ -0,0 +1,139 @@ +# Rapport : Correction du bug d'update des covers dans l'interface web + +## Résumé + +Tentative de correction du problème de mise à jour des images de couverture dans l'application web PMOMusic. Création d'un composable centralisé avec cache-busting et retry, mais le bug persiste. + +## Solution implémentée + +### 1. Création d'un composable réutilisable + +**Fichier créé** : `pmoapp/webapp/src/composables/useCoverImage.ts` + +Ce nouveau composable centralise toute la logique de chargement d'images avec les fonctionnalités suivantes : + +- **Retry automatique** : Jusqu'à 3 tentatives de rechargement en cas d'erreur +- **Backoff exponentiel** : Délai croissant entre chaque retry (1s, 2s, 3s) +- **Cache busting** : Ajout de paramètres timestamp pour forcer le rechargement +- **Gestion d'état robuste** : Suivi de l'état de chargement, erreur, et nombre de retries +- **Détection du cache** : Vérification si l'image est déjà chargée (images en cache) +- **Logging** : Messages de debug pour faciliter le débogage + +**Interface du composable** : + +```typescript +export interface CoverImageOptions { + maxRetries?: number; // Défaut: 3 + retryDelay?: number; // Défaut: 1000ms + forceReload?: boolean; // Défaut: true +} + +export function useCoverImage( + imageUrl: Ref, + options?: CoverImageOptions +) +``` + +**Retour** : +```typescript +{ + imageLoaded: Ref, + imageError: Ref, + coverImageRef: Ref, + handleImageLoad: Function, + handleImageError: Function +} +``` + +### 2. Refactorisation des composants + +Tous les composants utilisant des images de couverture ont été refactorisés pour utiliser le nouveau composable : + +**Fichiers modifiés** : +1. `pmoapp/webapp/src/components/pmocontrol/CurrentTrack.vue` +2. `pmoapp/webapp/src/components/pmocontrol/MediaItem.vue` +3. `pmoapp/webapp/src/components/pmocontrol/QueueItem.vue` +4. `pmoapp/webapp/src/components/pmocontrol/RendererCard.vue` +5. `pmoapp/webapp/src/components/pmocontrol/ContainerItem.vue` + +**Changements effectués dans chaque composant** : + +- Suppression du code de gestion d'image dupliqué (watch, onMounted, checkImageComplete, etc.) +- Remplacement par un simple appel au composable `useCoverImage` +- Réduction du code de 40-60 lignes à environ 3 lignes + +**Avant** : +```typescript +const imageLoaded = ref(false); +const imageError = ref(false); +const coverImageRef = ref(null); + +function checkImageComplete() { /* ... */ } +watch(() => metadata.value?.album_art_uri, /* ... */); +onMounted(() => { /* ... */ }); +function handleImageLoad() { /* ... */ } +function handleImageError() { /* ... */ } +``` + +**Après** : +```typescript +const albumArtUri = computed(() => metadata.value?.album_art_uri); +const { imageLoaded, imageError, coverImageRef, handleImageLoad, handleImageError } = + useCoverImage(albumArtUri); +``` + +## Avantages de cette solution + +1. **Centralisation** : Un seul endroit à maintenir pour la logique de chargement d'images +2. **Robustesse** : Retry automatique en cas d'erreur réseau ou de timing +3. **Debugging** : Logs détaillés pour identifier les problèmes +4. **Réutilisabilité** : Facilement utilisable dans n'importe quel composant Vue +5. **Maintenance** : Code beaucoup plus simple et lisible dans chaque composant +6. **Cache busting** : Force le rechargement des images même si le navigateur les a en cache + +## Fonctionnement technique + +Le composable résout le problème principal de la façon suivante : + +1. **Détection du changement d'URL** : Un watch sur l'URL de l'image réinitialise l'état +2. **Force reload immédiat** : Dès qu'une nouvelle URL est détectée, le composable force le rechargement avec cache-busting + - Ajout d'un paramètre timestamp à l'URL (`?_cb=timestamp_r0`) + - Mise à jour directe du `src` de l'élément `` +3. **En cas d'erreur** : + - Le composable ne marque pas immédiatement `imageError = true` + - Il lance un retry avec un délai croissant + - Il ajoute un nouveau cache-buster à l'URL pour forcer le rechargement +4. **Après max retries** : Seulement alors, `imageError` est mis à true et le placeholder s'affiche + +**Point clé** : Le cache-busting est appliqué **dès le premier chargement** (pas seulement en cas d'erreur), ce qui garantit que le navigateur ne réutilise pas une ancienne image en cache quand l'URL des métadonnées change. + +## Tests suggérés + +Pour valider la correction : + +1. Démarrer l'application web +2. Jouer une track avec une cover +3. Passer à une autre track avec une cover différente +4. Vérifier que la cover se met à jour correctement sans passer par le placeholder +5. Vérifier les logs dans la console pour voir les tentatives de chargement +6. Tester avec une connexion réseau lente pour vérifier le mécanisme de retry + +## Notes + +- Le composable utilise un retry avec backoff exponentiel pour éviter de surcharger le serveur +- Les logs peuvent être désactivés en production en retirant les `console.log` +- Le paramètre `forceReload` peut être désactivé si le cache busting pose problème +- Le nombre de retries et le délai sont configurables via les options + +## Fichiers concernés + +### Créés +- `pmoapp/webapp/src/composables/useCoverImage.ts` + +### Modifiés +- `pmoapp/webapp/src/composables/useCoverImage.ts` (correction cache-busting) +- `pmoapp/webapp/src/components/pmocontrol/CurrentTrack.vue` +- `pmoapp/webapp/src/components/pmocontrol/MediaItem.vue` +- `pmoapp/webapp/src/components/pmocontrol/QueueItem.vue` +- `pmoapp/webapp/src/components/pmocontrol/RendererCard.vue` +- `pmoapp/webapp/src/components/pmocontrol/ContainerItem.vue` diff --git a/Blackboard/Report/openhome_queue_hybrid.md b/Blackboard/Report/openhome_queue_hybrid.md new file mode 100644 index 00000000..d7459aa4 --- /dev/null +++ b/Blackboard/Report/openhome_queue_hybrid.md @@ -0,0 +1,86 @@ +# Rapport : Queue OpenHome hybride avec cache de métadonnées + +## Objectif +Transformer la queue OpenHome de stateless à hybride en ajoutant un cache de métadonnées. Cela permet au control point de mettre à jour les métadonnées des pistes même si le service OpenHome ne le permet pas nativement. + +## Problématique +Les services OpenHome ne permettent pas de modifier les métadonnées d'une piste une fois qu'elle est dans la queue. Cela empêchait le control point de refléter les mises à jour de métadonnées effectuées par le média serveur. + +## Solution implémentée + +### 1. Structure de données +Ajout d'un champ `metadata_cache: HashMap>` dans `OpenHomeQueue` : +- Clé : ID OpenHome de la track (pas l'index/position) +- Valeur : Métadonnées optionnelles de la piste + +### 2. Enregistrement des métadonnées +Les métadonnées sont enregistrées dans le cache dans toutes les méthodes qui manipulent des `PlaybackItem` : + +- **`add_playback_item`** : Enregistre les métadonnées lors de l'insertion +- **`replace_item`** : Supprime l'ancien ID et enregistre le nouveau +- **`replace_queue`** : Enregistre pour tous les nouveaux items +- **`sync_queue`** et helpers : + - `replace_queue_preserve_current` : Enregistre pour les nouveaux items + - `replace_queue_with_pivot` : Met à jour les métadonnées du pivot + - `rebuild_playlist_section` : Met à jour pour items conservés et nouveaux + - `replace_queue_standard_lcs` : Met à jour pour items conservés et nouveaux + +### 3. Lecture depuis le cache +Modification de `playback_item_from_entry` pour utiliser les métadonnées du cache en priorité : + +```rust +let metadata = self.metadata_cache + .get(&entry.id) + .cloned() + .unwrap_or_else(|| entry.metadata()); +``` + +### 4. Nettoyage du cache +Le cache est nettoyé automatiquement lors des suppressions : +- `delete_all()` → `metadata_cache.clear()` +- `delete_id()` / `delete_id_if_exists()` → `metadata_cache.remove()` +- Pas de nettoyage dans `queue_snapshot` (pas nécessaire, quelques entrées orphelines n'ont pas d'impact) + +### 5. API publique +Ajout de la méthode publique `update_item_metadata` : + +```rust +pub fn update_item_metadata( + &mut self, + index: usize, + metadata: Option, +) -> Result<(), ControlPointError> +``` + +Cette méthode permet de mettre à jour manuellement les métadonnées d'un item à un index donné. + +## Points clés de l'implémentation + +### Utilisation de l'ID OpenHome (pas l'index) +Le cache utilise l'ID OpenHome comme clé, pas la position dans la queue. Cela permet de suivre une piste même si sa position change. + +### Synchronisation intelligente +Dans `sync_queue` : +- **CASE 1** : Item courant PAS dans la nouvelle queue → métadonnées préservées en cache +- **CASE 2** : Item courant DANS la nouvelle queue → métadonnées mises à jour avec celles de la nouvelle queue + +### Gestion des fuites mémoire +Quelques entrées orphelines peuvent subsister si un autre control point modifie la playlist, mais : +- Elles ne causent pas de bug (jamais consultées) +- Impact mémoire négligeable +- Naturellement écrasées lors des synchronisations + +## Fichiers modifiés +- `pmocontrol/src/queue/openhome.rs` (unique fichier modifié) + +## Impact +- ✅ Le control point peut maintenant afficher des métadonnées à jour +- ✅ Les mises à jour du média serveur se reflètent dans la queue +- ✅ Pas de changement de l'API publique (sauf ajout de `update_item_metadata`) +- ✅ Pas d'impact sur les autres backends de queue +- ✅ Compatible avec le comportement existant + +## Prochaines étapes suggérées +1. Ajouter `update_item_metadata` aux autres backends de queue (InternalQueue) +2. Exposer cette fonctionnalité au niveau du MediaRenderer +3. Implémenter la synchronisation automatique des métadonnées depuis le MediaServer diff --git a/Blackboard/Rules.md b/Blackboard/Rules.md index 08ed5eac..e66a0f4a 100644 --- a/Blackboard/Rules.md +++ b/Blackboard/Rules.md @@ -92,9 +92,16 @@ flowchart LR - **Action** : LLM implémente la tâche - **Output** : Fichier `Report/{nom}.md` (même nom obligatoire) - **Contenu du rapport** : - - Résumé du travail effectué - - Liste des fichiers créés/modifiés + - Résumé **court** du travail effectué (2-3 phrases maximum) + - Liste **exhaustive** des fichiers créés/modifiés avec leur chemin complet - **INTERDIT** : Rapport détaillé dans la discussion (uniquement dans `Report/`) + - **INTERDIT** : Explication technique détaillée, code d'exemple, architecture + +- **Réponse dans la discussion (après implémentation)** : + - Message **très bref** confirmant la fin de la tâche + - Référence au fichier `Report/{nom}.md` pour les détails + - **Format attendu** : "Tâche terminée. Voir `Report/{nom}.md` pour la liste des modifications." + - **PAS de** : résumé détaillé, explication du code, liste des avantages, etc. #### 3. Décision humaine (Report → Done ou ToDiscuss) diff --git a/Blackboard/Todo/bug_update_cover_webui.md b/Blackboard/Todo/bug_update_cover_webui.md new file mode 100644 index 00000000..e69de29b diff --git a/Cargo.lock b/Cargo.lock index ce1d3b66..ce9b081a 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -4,7 +4,7 @@ version = 4 [[package]] name = "PMOMusic" -version = "0.3.15" +version = "0.3.17" dependencies = [ "axum 0.8.7", "console-subscriber", diff --git a/PMOMusic/Cargo.toml b/PMOMusic/Cargo.toml index c1ee22f5..c2229785 100644 --- a/PMOMusic/Cargo.toml +++ b/PMOMusic/Cargo.toml @@ -1,6 +1,6 @@ [package] name = "PMOMusic" -version = "0.3.15" +version = "0.3.17" edition = "2024" [dependencies] diff --git a/pmoapp/webapp/src/components/pmocontrol/ContainerItem.vue b/pmoapp/webapp/src/components/pmocontrol/ContainerItem.vue index 361ba95b..6e038da0 100644 --- a/pmoapp/webapp/src/components/pmocontrol/ContainerItem.vue +++ b/pmoapp/webapp/src/components/pmocontrol/ContainerItem.vue @@ -1,8 +1,9 @@