J'ai en tête de remonter comme il y a quelques années une radio 24/7 pour pouvoir écouter ma musique sans devoir chercher au préalable "quoi" écouter. Et me laisser parfois surprendre par le contenu de ma médiathèque, il faut l'avouer.
Mais cette fois-ci, j'aimerais avoir des radios thématiques : metal, synthwave, house, rock, et j'en passe. Sauf que pour ça MPD est vite limité et s'il faut gérer ses playlists à la main, c'est vite compliqué.
Entre temps est apparu un monstre dédié à la radio en ligne auto-hébergée : Azuracast. Avec ça, n'importe qui peut monter une station multi-diffusion aux petits oignons bien confortablement installé dans son navigateur (oui un navigateur c'est confortable, cherchez pas).
Du coup : test, et proof of concept qui va bien. Mais voilà, mon installation est un peu exotique car la musique est stockée sur un vieux NAS et Azuracast serait installé lui sur un serveur distinct, via un container Docker qui plus est. J'ai souvenir de galères bien velues avec les montages réseaux (SMB/CIFS ou même NFS), des containers qui démarrent plus ou moins vite et plus ou moins avant les montages réseaux et les machines qu'il faut parfois pouvoir éteindre ou redémarrer individuellement pour une raison ou une autre. Donc je ne cherche pas plus de dix minutes à creuser cette piste sachant à quel point elle est casse-gueule.
Heureusement en 10 ans l'évolution des technologies est passée par là et on a d'autres protocoles réseaux, notamment WebDAV et S3 (OK WebDAV n'a pas attendu l'an 2000 pour arriver mais bref, on se comprend).
WebDAV serait idéal puisque le vieux Synology supporte ce protocole que j'utilise d'ailleurs déjà ailleurs. Mais Azuracast fait son intéressant et ne parle pas ce protocole, seulement le S3 Amazonesque... que Synology ne connait pas évidemment !
Mais en cherchant bien, on tombe sur une de ces pépites que sait si bien créer le monde du libre : RClone. Ce soft est autant un couteau suisse pour gérer les fichiers et systèmes de stockage réseau que cURL peut l'être pour tout ce qui a trait au HTTP. Et parmi ses différentes lames, on trouve une commande magique assez récente : rclone serve s3 qui expose un stockage défini dans son fichier de config comme un endpoint S3. En gros, exactement ce dont j'ai besoin en considérant que mon stockage cible est WebDAV.
...
À ce stade, j'ai fait une pause dans mon écriture pour terminer la mise en place de ce montage. Mais rien ne s'est passé comme prévu.
Oh bien sûr RClone exposait bien un endpoint S3 et je pouvais même le monter depuis un rclone mount distant dans mon filesystem local, et hormis les dossiers en racine qui s'affichaient avec un "+" au lieu d'une espace, ça semblait marcher pas trop mal.
Mais Azuracast par contre n'a rien voulu savoir, et le "petit" problème d'encodage que j'avais avec mon client RClone n'était rien comparé aux gros problèmes rencontrés sur Azuracast qui refusait obstinément d'afficher le contenu du bucket dès qu'un dossier ou fichier contenait des caractère spéciaux, sans compter que RClone renvoit les "préfixes" (sortes d'équivalents des dossiers sur S3) sans le slash final ce qui finit d'embrouiller Azuracast qui prend les dossiers pour des fichiers.
Au final, j'aurais passé plus de 3 jours sur ce problème, à finir par monter un proxy HTTP en PHP pour inspecter les requêtes et les corriger à la volée pour les faire fonctionner, mais le résultat est franchement trop instable et Azuracast refuse toujours de m'ajouter des médias aux playlists que je crée donc je suis arrivé à une impasse et ma motivation s'est tarie.
J'aurais quand même pu trouver ce que je pense être au moins 3 bugs : 2 sur RClone et 1 sur le SDK PHP officiel d'AWS. J'ai ouvert des tickets et une PR pour avoir un peu l'impression que mon temps n'ait pas été totalement perdu.
- https://github.com/rclone/rclone/issues/7836
- https://github.com/rclone/gofakes3/issues/4
- https://github.com/aws/aws-sdk-php/pull/2918
Comment occuper la moitié de ses congés sur des bêtises hein...
Photo d'illustration : "Hoover Dam Bypass Bridge Construction 3" by Alan Stark is licensed under CC BY-SA 2.0.