Tout a commencé par la lecture de cet article : Je quitte Spotify pour mon propre cloud musical autohébergé ! L’auteur y explique comment il est passé de Spotify à une solution auto-hébergée avec Nextcloud et son application Music.
Il y soulève d’ailleurs plusieurs points intéressants à propos de l’usage de Spotify : d’abord l’absence de certains artistes, ou de leur disparition soudaine pour d’obscures raisons contractuelles, en d’autres termes l’absence de contrôle sur la musique que l’on souhaite écouter. Mais aussi un autre point très intéressant : utilisateur des « Daily Mix » (des playlists générées chaque jour en fonction de vos goûts), il s’est vite vu s’auto-censurer en n’allant pas écouter une musique dont il avait entendu parler de peur que l’algorithme ne vienne altérer ses « Daily Mix » !
On voit par ces deux exemples les limites de ce que propose Spotify ou Deezer : on perd le contrôle, jusqu’à s’auto-censurer à cause d’algorithmes qui font des choix à notre place. C’est d’ailleurs de plus en plus vrai, avec l’AI qui arrive partout, yc dans les navigateurs, et que je m’empresserai de désactiver quand le pourrai, vu que cela n’apporte rien à part de la confusion. Ce n’est pour moi que le dernier élément marketing des GAFAMs pour vendre leur tambouille du rêve et collecter encore plus de données.
Mais revenons à l’article : je me suis dit pourquoi ne pas « streamer » ma propre musique puisque j’ai mon instance Nextcloud qui tourne sur mon NAS OMV et qui est accessible depuis internet grâce à swag/nginx, le Proxy Server installé ? (voir cet article pour la configuration de mon serveur Nextcloud sur le NAS OpenMediaVault). Le seul souci que je voyais finalement était que ma bibliothèque musicale est assez importante (+14 000 titres) et que je ne voulais surtout pas avoir à dupliquer sur le NAS.
Concernant l’application de lecture côté Android (puisqu’il s’agit de streamer sa propre musique en dehors de chez soi), j’ai utilisé celle mentionnée dans l’article de Flozz, qui m’avait l’air très bien (totalement open-source) puisque Nextcloud Music accepte les clients utilisant l’API Ampache. C’est là que je suis tombé sur un sérieux problème, car il était impossible de me connecter à mon instance Nextcloud Music. J’ai mis du temps à identifier l’origine du problème, mais avec de l’aide côté dev Ampache et Nextcloud, nous avons finis par identifier un problème de configuration sur le proxy serveur nginx.
J’ai également du mettre à jour mon instance Nextcloud, et là je suis tombé sur un nouveau problème lors de l’upgrade. Enfin un problème d’affichage de pochettes m’a embêté quelque temps avant de me rendre compte que cela provenait de la configuration réseau sur mon LAN.
Cela n’a donc pas été sans peine, mais j’ai finalement réussi à tout mettre en ordre de marche. Je vais essayer de reprendre ici toutes les étapes et les problèmes rencontrés.
C’est parti !
Bibliothèque musicale
Ma bibliothèque musicale est en premier lieu sur mon PC, mais celui-ci n’est pas allumé en permanence. Pour l’utiliser avec Volumio sur mon Raspberry, je la synchronise donc sur un disque USB du Raspberry via un script rsync et un accès SSH (voir cet article). Le raspberry est lui tout le temps allumé, et la connexion SSH était donc déjà toute configurée. 😎
Comme je ne voulais exposer toute ma bibliothèque, je l’ai vite réorganisée, en créant deux dossiers à la base de l’arborescence : Intranet (pour la maison uniquement) et Internet (accessible de l’extérieur). Puis j’ai déplacé l’essentiel dans Intranet, et disons toutes mes playlists dans Internet (ce que j’écoute le plus facilement), qui représente tout de même 3 400 titres. Ce devrait être suffisant pour streamer hors de la maison…
Un mot sur les playlists
Sur mon PC, les playlists (avec Rhythmbox) sont en fait des titres réunis dans un même dossier. Or l’API Ampache n’offre pas de fonction de type « vue dossier ». Elle affiche par contre les Playlists que Nextcloud Music permet de créer, et NC Music offre une vue dossier : voir en fin d’article comment gérer cela, c’est très simple.
Nextcloud External Storage Support
Nextcloud fournit une application « External Storage support » qui va me permettre de configurer un accès via SFTP à ma bibliothèque musicale sur le disque USB de Volumio. Il suffit donc d’installer cette application, de créer d’abord un dossier dans Nextcloud Fichiers qui servira de point de montage (ici MyMusic), puis d’aller dans « Paramètres d’administration – Administration – Stockage externe », et d’y donner les informations de connexion à la machine Volumio :
Il faut ensuite aller dans l’application Music, de définir le chemin de votre collection de musique, puis de lancer le scan… qui peut prendre plus ou moins de temps ! On peut d’ailleurs exclure certains dossiers du scan si on le souhaite à ce moment (autre approche).
Cette partie a été vraiment très simple à régler, et j’ai pu tout de suite tester le lecteur dans le navigateur. Tout fonctionnait parfaitement.
Reste tout de même à configurer l’accès à partir du client Ampache : pour ce faire, aller sur la page Nextcloud Music, choisir Settings en bas à gauche, vous y trouverez l’URL qu’il faudra utiliser côté client, ainsi que la possibilité de générer le mot de passe à utiliser pour l’utilisateur Nextcloud :
Notez bien le mot de passe qui est fourni, car une fois la boîte fermée, il n’apparaîtra plus nulle part. On ne peut que l’effacer et en créer un nouveau.
Voilà, côté Nexcloud, tout est prêt. Passons maintenant au client Ampache côté Android.
Power Ampache 2
Power Ampache 2, disponible sur F-Droid, est une application totalement open source, et comme j’ai eu l’occasion d’aborder le sujet avec le développeur, elle ne comporte aucun tracking : en effet, alors que j’investiguais le problème des pochettes (voir plus bas), j’avais noté que Exodus Privacy avait repéré un tracker dans l’application :
Et voilà la réponse du développeur :
All the requests Power Ampache 2 makes are directed to the amapache server you specified at login. I absolutely do not make any third party or tracking requests. All the libraries used are open source and do not make any network request on their own. Even the « (1) pisteur » you see in your report, that’s for email crash report, and you can just refuse to send the email if a crash happens, if you want.
Tout est parfait donc, et l’application est très esthétique je trouve :
Mais il faut d’abord se connecter au serveur, et c’est là que les ennuis ont commencé, il m’était impossible de me connecter :
J’ai commencé à regarder les logs que fourni l’application dans les paramètres (bonne conception) :
2024-06-23 15:51:54
retrofit2.HttpException: HTTP 404 { "exception" : "java.security.cert.CertPathValidatorException: Trust anchor for certification path not found." }
at retrofit2.KotlinExtensions$await$2$2.onResponse(KotlinExtensions.kt:53)
at retrofit2.OkHttpCall$1.onResponse(OkHttpCall.java:161)
at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:535)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
at java.lang.Thread.run(Thread.java:1012)
authorize() - cannot load data HttpException {"code":404,"message":"{ \"exception\" : \"java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.\" }","detailMessage":"HTTP 404 { \"exception\" : \"java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.\" }","stackTrace":[],"suppressedExceptions":[]}
Le message semblait pointer un problème de certification (« Trust anchor for certification… »), or mon certificat était bien valide, puisque je pouvais accéder en HTTPS via le navigateur. Je ne comprenais donc pas le problème. En regardant les logs du serveur nginx, je pouvais voir quelque chose de ce genre :
92.xxx.yyy.zzz - - [23/Jun/2024:18:11:56 +0200] "GET /apps/music/ampache/server/json.server.php?action=handshake&auth=0dc8eab854xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx289e9ded5423&user=xxxxxxx×tamp=1719159117 HTTP/2.0" 404 146 "-" "PowerAmpache2-1.00-60-fdroid"
Erreur 404 (not found), celle-là tout le monde la connaît ! Mais cela ne m’aidait guère… Je me suis alors tourné vers le dev Ampache pour leur demander de l’aide. Le dev a vite pensé à un problème avec le proxy et les « Nextcloud rewrites » (on verra plus tard que c’était bien le problème). Il ajoutait que cela pouvait être aussi un problème avec la version de Nextcloud ou celle de Nextcloud Music…
Mise à jour serveur Nextcloud
Je me suis donc d’abord tourné vers mon serveur Nextcloud, qui n’était effectivement pas à jour : je devais être à la version 25 alors que la 29 venait de sortir. Il était temps de me mettre à jour.
J’ai donc dans un premier temps fait les mises à jour via l’interface de Nextcloud, passant de la 25 à la 26, puis 26 -> 27 -> 28 -> jusqu’à la dernière version disponible, soit la 29.0.3. Tout s’est très bien passé à ce niveau, c’est vraiment la meilleure façon de mettre à jour Nextcloud dans son container Docker. Les scripts de Nextcloud sont vraiment bien faits, ils font même une sauvegarde de la version de départ au cas où un problème surviendrait.
En écrivant cet article, j’ai vérifié si une nouvelle version était dispo, et c’était le cas avec la 29.0.4. J’ai donc en toute confiance lancé la mise à jour, et bien sûr, comme je venais d’écrire que les scripts étaient super bien faits, cette fois ça a planté :
Et là, j’étais bloqué, le bouton « Retry update » ne donnait rien. J’ai fini par recharger la page, et j’ai alors eu droit à ce message et cette commande un peu rebutante :
C’est un peu obscur à première vue, mais en fait assez simple à gérer : d’abord se connecter en SSH sur la machine, et coller la commande indiquée.
pascal@odroidhc2:~$ php -r '$password = trim(shell_exec("openssl rand -base64 48"));if(strlen($password) === 64) {$hash = password_hash($password, PASSWORD_DEFAULT) . "\n"; echo "Insert as \"updater.secret\": ".$hash; echo "The plaintext value is: ".$password."\n";}else{echo "Could not execute OpenSSL.\n";};'
Insert as "updater.secret": $2y$10$5q.oWf0b.bBlGxxxxxx
The plaintext value is: MUk9s3iBnUFjip0mptqSxxxxxx
pascal@odroidhc2:~$
Il suffit lors d’ajouter la valeur de « updater.secret » à la fin du fichier /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config/www/nextcloud/config/config.php :
'dbpassword' => 'keepsecret',
'installed' => true,
'theme' => '',
'loglevel' => 0,
'maintenance' => false,
'maintenance_window_start' => 1,
'has_rebuilt_cache' => true,
'app_install_overwrite' =>
array (
0 => 'carnet',
),
'updater.secret' => '$2y$10$5q.oWf0b.bBlGxxxxxxxxx'
);
Puis sur la page web de rentrer le mot de passe en « plain text value » et de cliquer sur le bouton « Login ». La mise à jour vous propose alors de reprendre où elle avait échouée, et se termine sans encombres.
NOTE : La ligne ajoutée précédemment au fichier config.php est automatiquement supprimée une fois utilisée ! Encore une bonne chose d’apprise avec Nextcloud ! 😳
Une fois cette première phase terminée, on peut soit continuer via l’interface Web (une nouvelle page s’ouvre) pour démarrer la mise à jour proprement dit. On peut tout aussi bien ouvrir une boite de commande via Portainer ou Dockge (au passage un très bon outil pour gérer ses containers, j’en suis très content) pour lancer la mise à jour très simplement avec la commande occ upgrade :
J’ai ensuite pu installer l’application Music à la version 2.0.0 comme recommandé sur l’écran de connexion du client Power Ampache (voir plus haut).
Messages d’erreur (warnings)
Toujours dans Nextcloud, j’avais deux alertes (en rouge) dans la page « Vue d’ensemble » des paramètres d’administration que je me suis attaché à corriger, afin de partir d’une situation la plus propre possible :
Le premier message a été corrigé en modifiant le fichier /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config/nginx/site-confs/default.conf du serveur nginx (il suffit d’ajouter l’extension mjs pour le javascript) :
include mime.types;
types {
text/javascript js mjs;
application/wasm wasm;
}
Pour la seconde erreur, c’était un peu plus compliqué. Mon fichier /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config/www/nextcloud/config/config.php était configuré comme ceci concernant les « trusted_proxies » :
'trusted_proxies' =>
array (
0 => 'swag',
),
Depuis la console de l’instance Docker de Nextcloud, je pouvais voir son adresse IP et celle du proxy swag/nginx comme ceci :
root@0e47f46ce787:/# ip address
158: eth0@if159: mtu 1500 qdisc noqueue state UP
link/ether 02:42:ac:1a:00:03 brd ff:ff:ff:ff:ff:ff
inet 172.26.0.3/16 brd 172.26.255.255 scope global eth0
valid_lft forever preferred_lft forever
root@0e47f46ce787:/#
root@0e47f46ce787:/# ping swag
PING swag (172.26.0.4): 56 data bytes 64 bytes from 172.26.0.4: seq=0 ttl=64 time=1.020 ms
Et dans la console Docker Swag, je pouvais aussi vérifier son adresse :
root@8077149332c5:/# ip addr
160: eth0@if161: mtu 1500 qdisc noqueue state UP
link/ether 02:42:ac:1a:00:04 brd ff:ff:ff:ff:ff:ff
inet 172.26.0.4/16 brd 172.26.255.255 scope global eth0
valid_lft forever preferred_lft forever
Ce qui me permettait d’utiliser la notation CIDR suivante pour que Nextcloud soit content pour la déclaration de ses « trusted_proxies » :
'trusted_proxies' =>
array (
0 => '127.26.0.0/16',
),
Voilà, je suis désormais à jour côté serveur Nextcloud, et je n’ai plus aucune erreur critique (en rouge). Une bonne chose de faite finalement.
Il reste bien quelques messages, mais non critiques, comme de me signaler que j’utilise une version 32 bits de PHP et que je ferais mieux de passer à une version 64 bits ! Information dont je suis bien conscient, mais mon odroid-hc2 fonctionnant parfaitement, je le garderai tant que ce sera le cas ou que je me retrouverai coincé (j’ai déjà vu que mes containers Docker n’étaient plus disponibles, voir cet article).
Erreur 404
Mais hélas, il m’est toujours impossible de me connecter à partir du client Ampache, et toujours avec la même erreur. Je peux toutefois raisonnablement penser que côté Nextcloud, tout est bon.
Première solution
Je finis par trouver un ticket ouvert sur le Github de Music qui correspond à mon message d’erreur : Ampache api with nextcloud served by nginx gets 404 when following nextclou admin docs.
Apparemment, quand Nextcloud est utilisé avec nginx (pas de problème avec Apache), il ne manipule pas correctement les fichiers avec une extension .php, renvoyant l’erreur 404. Bon, je n’ai pas tout maîtrisé ici, mais la directive try_files pose problème. en la modifiant comme ci-dessous, je peux effectivement enfin me connecter avec le client Ampache.
--- nextcloud-old.conf 2021-05-05 01:02:35.871870022 +0200
+++ nextcloud.conf 2021-05-05 01:03:11.491904219 +0200
@@ -113,7 +113,7 @@
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
set $path_info $fastcgi_path_info;
- try_files $fastcgi_script_name =404;
+ try_files $fastcgi_script_name /index.php$fastcgi_script_name?$args;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
Dans ma configuration, le fichier de configuration en question, celui de nginx, est /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config/nginx/site-confs/default.conf. Il est préconfiguré pour être utilisé avec Nextcloud, puisque j’utilise une solution « clef en main » fournie par Linuxserver.io avec les 3 containers Docker requis : Nextcloud, Mariadb et Swag (Swag intègre nginx + fail2ban + Letsencrypt).
Sauf que la modifier de cette façon peut avoir un impact sur le fonctionnement global de Nextcloud. Et sur les conseils du dev Ampache, j’ai ajouté une nouvelle « location » dans le fichier de configuration de Nextcloud pour traiter spécifiquement les fichiers concernant ampache et de laisser le reste du code tel quel :
location ~ ^/apps/music/ampache/server/.*\.php$ {
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
set $path_info $fastcgi_path_info;
try_files $fastcgi_script_name /index.php$fastcgi_script_name?$args;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $path_info;
fastcgi_param HTTPS on;
fastcgi_param modHeadersAvailable true; # Avoid sending the security headers twice
fastcgi_param front_controller_active true; # Enable pretty urls
fastcgi_pass php-handler;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
}
Le problème semble donc réglé ! 😎 Reste à signaler le problème à qui de droit.
La documentation Nextcloud
Pour faire les choses bien, et comme conseillé par un dev de Music, le meilleur endroit pour déclarer ce problème, c’est la doc de Nextcloud. En effet, cette dernière donne les infos pour configurer le serveur nginx sur cette page. Je crée donc un ticket ici pour signaler le problème et suggérer d’ajouter ce cas de figure dans la section Tips and tricks.
Quelques jours plus tard, une personne me répond qu’effectivement, l’API Ampache (exposée par l’application Music) possède des routes qui intègrent des fichiers .php. et que nginx gère cela différemment qu’Apache. Il me propose une autre solution, plus simple et qui évite de créer une « location » spécifique. En se basant sur ce document, on ajoute une règle qui devrait être présente pour bien gérer les fichiers .php de l’API Ampache.
La personne m’en propose une modifiée pour Ampache, mais ce sera finalement la ligne de rewrite de la documentation qui va se révéler la bonne. Elle est indiquée comme « required for legacy », mais n’était pas présente dans le fichier que j’utilisais, et qui venait des containers nextcloud+mariadb+swag proposés ici.
# Ensure this block, which passes PHP files to the PHP process, is above the blocks
# which handle static assets (as seen below). If this block is not declared first,
# then Nginx will encounter an infinite rewriting loop when it prepends `/index.php`
# to the URI, resulting in a HTTP 500 error response.
location ~ \.php(?:$|/) {
# Pascal - added for Nextcloud Music and Ampache client PHP (routes handling)
# Required for legacy support
rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|ocs-provider\/.+|.+\/richdocumentscode(_arm64)?\/proxy) /index.php$request_uri;
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
set $path_info $fastcgi_path_info;
try_files $fastcgi_script_name =404;
Cette fois tout est bon ? Euh… un autre problème va apparaître.
Pas de pochettes affichées
Dans la plupart des cas de ma bibliothèque musicale, chaque dossier correspond à un album, et contient en plus des morceaux un fichier image cover.jpg. représentant la pochette de l’album. C’est assez standard et fonctionne généralement sans problème particulier.
Si la connexion fonctionnait désormais :cool:, je n’ai pas les pochettes dans le cient Ampache, alors que je les ai dans le navigateur :
Sur ce coup là, je n’ai pas été très bon, car le problème venait de ma config, et j’aurais pu/du le trouver tout seul. J’ai d’abord sollicité le dev de Music, qui m’a vite répondu en m’expliquant comment cela fonctionnait et comment je pouvais tester. Par exemple, en utilisant une URL de ce type :
(en utilisant un token auth valide), je devais avoir une réponse avec une autre URL pour la clef art., qu’il me suffisait alors de tester : si j’obtenais la pochette, alors tout était bon côté Nextcloud Music.
Pour obtenir un token valide, il me suffisait de me connecter avec Ampache tout en affichant les logs de nginx. Exemple :
root@odroidhc2# cd /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config/log/nginx#
root@odroidhc2# tail -f access.log
...
192.168.1.126 - - [30/Jul/2024:17:01:12 +0200] "GET /apps/music/ampache/server/json.server.php?action=stats&auth=d41a91089dcxxxxxxxxxxxx&limit=40&username=pascal&type=album&filter=newest&offset=0 HTTP/1.1" 200 3298 "-" "PowerAmpache2-1.00-62-fdroid"
...
Il me suffisait alors d’utiliser auth=d41a91089dcxxxxxxxxxxxx dans l’URL indiquée par le dev de Music pour pouvoir la tester. Et j’obtenais bien une autre URL « art » :
Et l’URL m’affichait bien la pochette ! Voilà, je laisse cette info ici car cela peut servir pour tester le fonctionnement de Nextcloud Music.
En fait le problème venait tout bêtement de ma config réseau. Lorsque j’avais mis en place mes containers Nextcloud-Mariadb-Swag, pour des conflits de ports entre Nextcloud et Swag, j’avais du rediriger le port 443 vers le 444 entre la box et le proxy :
Ce qui m’obligeait, quand j’étais à la maison, à définir le port 444 à la fin de l’URL pour accéder à mes services, et qui compliquait inutilement les choses. J’avais fait ça, je crois, parce que dans ma stack Nextcloud, je définissais le port 443, et que je faisais de même dans la stack Swag, j’avais alors un conflit de port au démarrage des containers et cela ne fonctionnait pas.
---
version: "2.1"
services:
nextcloud:
...
ports:
- 443:443
...
swag:
...
ports:
- 443:443
...
En fait la solution était toute simple : ne rien spécifier pour Nextcloud (supprimer la déclaration « ports »), le port https par défaut étant 443 et dès lors tout démarrait sans erreur et fonctionnait sur toute la chaîne sur le port 443 (j’ai bien sûr modifié le routeur de la box et aussi le fichier de configuration Nextcloud : /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config/www/nextcloud/config/config.php :
'trusted_domains' =>
array (
0 => '192.168.1.30:443',
1 => 'nextcloud.xxx.pled.fr',
),
Et me voilà de retour à une configuration plus standard et moins problématique.
Dès lors, Power Ampache 2 affichait bien mes pochettes (si tant est qu’elles étaient fournies par mes fichiers audio), et tout fonctionnait à merveille : je pouvais enfin « streamer » ma propre musique en allant me promener ! 😎
Playlists
Reste à gérer mes playlists ! Comme je l’expliquais plus haut, elles viennent de Rhythmbox sur mon PC, et sont chacune dans un dossier spécifique qui contient tous les titres (pas de playlist dynamique réunissant X titres provenant de Y dossiers. Je n’utilise donc pas de fichier de type m3u par défaut. Même les playlists de Rhythmbox créées au fil des écoutes et contenant donc des chemins absolus vers différents dossiers, j’ai fini par les transformer en dossier « playlist » : cela duplique les-dits morceaux, mais cela simplifie largement le passage des playlists vers Volumio : en effet il est très facile via l’interface web de Volumio de sélectionner un dossier et de choisir « Ajouter à la playlist » puis d’en créer une nouvelle. De cette façon, j’ai pu recréer très facilement mes playlists de Rhythmbox.
Or, l’API Ampache, comme me l’a confirmé le développeur, ne propose pas de vue par dossier. Elle propose par contre les Playlists que l’on crée à partir de NC Music. Heureusement, NC Music permet non seulement de créer des Palylists, mais propose aussi une vue « Dossier » : il suffit donc de créer une nouvelle playlist, puis de passer en vue « Dossier », et de faire un « glisser-déposer » du nom du dossier sur celui de la playlist, et le tour est joué ! 😎
Par contre, si l’on souhaite avoir les pochettes dans cette configuration, il va falloir intégrer chacune d’entre elles dans le fichier .mp3 ou .ogg s’il ne la contient pas déjà. Dans ce cas, je l’ajoute avec Puddletag (mais ce ne sont pas éditeurs de tags qui manquent) :
Conclusion
Voilà, cela n’ a pas été de tout repos, mais finalement c’est assez simple, hormis les deux problèmes rencontrés :
- l’un était du à l’absence d’une directive de rewrite dans le fichier de configuration du proxy serveur, pourtant marquée comme « required for legacy ». Un problème sans doute lié à la configuration par défaut proposée par le container Swag. Celui-là n’était pas simple à résoudre.
- Le deuxième, celui des pochettes était du à ma configuration et j’aurais du y penser tout de suite. En fait, je testais tout à partir de mon LAN, ayant remis à plus tard son utilisation depuis l’extérieur en attendant que tout fonctionne : en l’utilisant hors de la maison, j’aurais vu les pochettes arriver, et j’aurais rapidement fait le lien ! Finalement, cela m’a forcé à corriger ce problème de config avec le port 443 et les deux containers pointant dessus, ce qui est une bonne chose, cela m’avait déjà posé des contraintes avec d’autres applications (Joplin).
En dehors de ces deux points, il m’a fallu mettre à jour mon instance Nextcloud, afin de bénéficier de Music 2.0.0. L’occasion de vérifier que la mise à jour via leur interface est plutôt fiable et robuste (mais un problème peut toujours survenir !). Tout est parfaitement détaillé sur cette page (bravo à la qualité de la documentation Nextcloud).
Enfin, pour rappel, voilà les tickets Github que j’ai créé soit pour demander de l’aide, soit pour signaler ce que je croyais être un bug, ou encore pour signaler qu’une mise à jour de la doc était nécessaire :
- Trust Anchor – Ampache : https://github.com/ampache/ampache/issues/3973
- No cover – NC Music : https://github.com/owncloud/music/issues/1156
- No cover – Power Ampache : https://github.com/icefields/Power-Ampache-2/issues/13
- NC Music documentation : https://github.com/nextcloud/documentation/issues/11951
Et encore merci à tous ces devs qui m’ont aidé à investiguer ce problème, ils ont tous été vraiment super !