J'avais été le premier à manifester mon intérêt pour ce projet suite à l'ouverture de ce fil
https://forum-hifi.fr/thread-41831-post-...#pid942713
Je le dis d'emblée : l'idée de Tune est prometteuse, et je souhaite sincèrement à ce projet de trouver sa place.
Mais, après plus de 3 mois à le suivre et à le tester, je m'étonne de la méthode de développement, qui cafouille pour le moins et qui semble virer, itération après itération, à un code de plus en plus difficile à maîtriser.
Je ne fais de procès d'intention à personne — je constate, avec des faits plutôt qu'avec des impressions.
Quand je lis quelques posts plus haut : "
Gardez en tête que chaque petite modification peut avoir de grandes répercussions sur le soft et le déstabiliser", ou "
C'est un projet certes en développement mais il est déjà à un niveau de maturité qui récompense largement ceux qui ont un peu de patience, avec quelques bugs et lenteurs de fonctionnement" — j'ai voulu vérifier par moi-même, à partir des notes de version publiées par Bertrand
Je sais que c'est paradoxalement en développant en pelure d'oignon plutôt qu'en spaghetti qu'on limite le risque de pleurer en cours de route.
Je sais aussi que plus on avance, plus il devient difficile d'appuyer, a minima sur le bouton pause, et plus probablement sur le bouton rewind pour sauver le soldat Ryan.
Sans être développeur moi-même, les initiés comprendront.
Des faits, donc : rien de plus factuel que les notes de version elles-mêmes qui permettent de savoir où on en est réellement depuis la mi-mai.
1. Le volume des corrections sur les 16 derniers jours, donc après déjà 3 mois de développement
Entre la v0.9.70 et la v0.9.130 — soit 44 versions documentées (certaines builds n'ont jamais été mises en ligne) — on comptabilise environ 550 corrections annoncées. Les deux dernières versions (0.9.129 et 0.9.130) en apportent à elles seules 150. Sur cette même période, 6 versions n'ont jamais atteint les utilisateurs : trois taguées puis jamais livrées à cause de pannes de build, une retirée après publication (exécutable Windows cassé), une livrée sans aucune image du système, une autre sans le paquet macOS Intel.
Plus préoccupant : la v0.9.129 corrige une faille de sécurité livrée dans la version précédente. La note le dit sans détour : "wasmtime passe en 47.0.4. La 0.9.128 embarquait une version affectée par une évasion de bac à sable." Une vulnérabilité touchant l'isolation du système, pas seulement le confort d'écoute, s'est donc retrouvée entre les mains des utilisateurs avant d'être corrigée.
2. La nature des correctifs
L'essentiel du vocabulaire utilisé n'est pas celui d'un ajustement de nouvelle fonctionnalité, mais celui d'une réparation de comportement de base : "n'est plus", "cesse de", "cesse d'être".
Exemple révélateur, en v0.9.119 : "Depuis la v0.9.97, aucune zone navigateur n'alimentait ni Last.fm ni votre historique" — un défaut resté actif sur au moins 22 versions sans être détecté.
Deux cas dépassent largement ce chiffre :
En v0.9.76 : un crash au démarrage sur toute machine Windows équipée d'un pilote ASIO capricieux, actif "depuis la v0.9.45" — soit 31 versions durant lesquelles la machine ne pouvait plus jamais relancer Tune, sans le moindre message d'erreur.
En v0.9.127 : le bouclage des fichiers Ogg-Opus corrigé alors que "la protection équivalente existait depuis longtemps pour l'Ogg Vorbis" — corrigée, elle, dès la v0.9.74. Soit 53 versions d'écart pour appliquer le même correctif à un format cousin.
3. Des régressions documentées noir sur blanc, dans les notes elles-mêmes
En v0.9.116 : "Cinq comportements sont restaurés… perdus lors d'une fusion de juillet." Un aveu direct qu'une fusion de code antérieure avait fait disparaître des fonctionnalités.
Le nom de fichier accentué : corrigé en v0.9.121 ("les noms accentués sont comparés dans les deux formes Unicode"), puis décrit comme "de nouveau retrouvé" en v0.9.125, quatre versions plus tard.
Le mélange stéréo/mono en v0.9.124 : le correctif est présenté comme "déjà en place" mais qu'il fallait "verrouiller par un test" pour l'empêcher de revenir — preuve qu'il était déjà reparti une fois.
Et le même motif se répète encore en v0.9.130 : "Un dossier de genre s'ouvre — c'était la moitié manquante d'un correctif précédent." Un correctif livré incomplet, dont l'autre moitié n'arrive qu'à la version suivante — exactement le schéma déjà vu en v0.9.94 sur les durées MP3.
4. Le cas le plus parlant : une contradiction interne au même fichier
En v0.9.127 : "Baisser le volume ne fait plus annoncer « Transcodé »." Depuis fin août, un volume à 85 % suffisait pour faire perdre la mention bit-perfect à un FLAC sans égaliseur, en contradiction avec la règle écrite de quelques lignes plus bas dans le même fichier. Ici, ce n'est même plus un couplage caché entre deux composants distants : c'est une règle qui se contredisait elle-même, à quelques lignes d'écart, dans un seul et même bloc de code — et qui a tenu ainsi pendant des semaines.
Dans la même veine, la v0.9.130 corrige un cas où "l'analyse acoustique ne se condamne plus elle-même" : une panique au chargement d'un modèle empoisonnait un verrou interne, bloquant toute nouvelle tentative jusqu'à un redémarrage complet du serveur.
L'aveu de méthode
La note de la v0.9.127 se termine par : "Comme toujours, si quelque chose se comporte différemment de ce que précisent ces notes, dites-le : c'est exactement ce genre de retour qui a permis de trouver plusieurs défauts ci-dessus." Ce sont donc les retours des testeurs bénévoles, pas une suite de tests internes, qui jouent le rôle de filet de sécurité.
Ce que j'en conclus
Ce ne sont pas des bugs anodins : ce sont de vraies régressions et des incohérences sur des points qu'on croyait réglés ou qui auraient dû être vérifiés dès l'écriture du code. Une modification quelque part peut en réactiver une autre ailleurs, ou coexister avec une règle contradictoire sans que rien ne le signale avant qu'un utilisateur ne le remarque à l'oreille. C'est le signe d'un développement qui ressemble de plus en plus à du spaghetti, difficile à stabiliser dans la durée. On met actuellement en place des patchs qui sont censés patcher des patchs.
Je le répète, le projet est louable et j'espère sincèrement qu'il trouvera sa stabilité. À l'heure actuelle j'en doute et je préfère attendre que ce soit plus mûr avant d'y revenir.
Bon courage aux bêta-testeurs qui ont la patience et l'énergie d'aider au débogage au quotidien — c'est un vrai travail.
Il en faudra encore beaucoup pour que Tune soit le futur compagnon de route de JPlay, BubbleUPnP, Daphile, HQPlayer et Diretta dans le paysage audiophile — plutôt que celui de SIRHEN, Louvois ou l'ONP.
