Le projet Tune, un concurrent à Roon, libre, gratuit et Français ?

[yacine]

J'ai donné la marche à suivre pour l'installation
simplement, valable quelque soit votre config.

Voici le rapport de Claude concernant LMS :

# Rapport de bug — Renderer UPnP Tune : champ `Sink` vide dans `GetProtocolInfo`

## Résumé

Le renderer UPnP/DLNA exposé par Tune (`DENAFRIPS USB HiRes Audio, USB Audio (Tune)`) répond à l'action SOAP `GetProtocolInfo` du service `ConnectionManager` avec un champ **`Sink` complètement vide**. Pour un appareil de type `MediaRenderer`, ce champ doit lister les formats audio que l'appareil est capable de **recevoir et lire**. Son absence empêche tout contrôleur UPnP tiers (testé ici avec Lyrion Music Server / squeeze2upnp) de déterminer un format de flux valide à envoyer, ce qui bloque totalement la lecture.

## Environnement

* **Application** : Tune (MozAIk Labs), version modelNumber `0.9.96`
* **Serveur UPnP testé** : Lyrion Music Server 9.1.1 + plugin UPnPBridge (squeeze2upnp-linux-x86\_64 v3.4.4)
* **OS** : Fedora (station Linux), Tune et Lyrion sur la même machine
* **Périphérique audio** : DAC DENAFRIPS USB HiRes Audio (exposé via USB)
* **Adresse du renderer** : `http://192.168.0.39:8888/upnp/renderer/7/`

## Étapes de reproduction

1. Activer l'option "Renderer UPnP" dans les paramètres de Tune.
2. Depuis un contrôleur UPnP tiers (ici Lyrion/squeeze2upnp), effectuer une requête SOAP `GetProtocolInfo` vers le service `ConnectionManager` du renderer Tune :

```bash
curl -s -X POST "http://192.168.0.39:8888/upnp/renderer/7/ConnectionManager/control" \\
  -H 'Content-Type: text/xml; charset="utf-8"' \\
  -H 'SOAPAction: "urnchemas-upnp-orgervice:ConnectionManager:1#GetProtocolInfo"' \\
  -d '<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:GetProtocolInfo xmlns:u="urnchemas-upnp-orgervice:ConnectionManager:1">
</u:GetProtocolInfo>
</s:Body>
</s:Envelope>'
```

## Résultat obtenu

```xml
<u:GetProtocolInfoResponse xmlns:u="urnchemas-upnp-orgervice:ConnectionManager:1">
  <Source>http-get:\*:audio/flac:\*,http-get:\*:audio/wav:\*,http-get:\*:audio/mpeg:\*,http-get:\*:audio/ogg:\*,http-get:\*:audio/aac:\*,http-get:\*:audio/mp4:\*,http-get:\*:audio/x-aiff:\*</Source>
  <Sink></Sink>
</u:GetProtocolInfoResponse>
```

* Le champ **`Source`** contient une liste de formats (`audio/flac`, `audio/wav`, `audio/mpeg`, `audio/ogg`, `audio/aac`, `audio/mp4`, `audio/x-aiff`).
* Le champ **`Sink`** est **vide**.

## Résultat attendu

Pour un `MediaRenderer`, c'est le champ **`Sink`** qui doit contenir la liste des formats acceptés en entrée (ceux que l'appareil sait décoder et jouer), typiquement quelque chose comme :

```xml
<Sink>http-get:\*:audio/flac:\*,http-get:\*:audio/wav:\*,http-get:\*:audio/L16;rate=44100;channels=2:\*,http-get:\*:audio/mpeg:\*,...</Sink>
```

Le champ `Source` concerne normalement les appareils de type **serveur média** (`MediaServer`), qui *fournissent* du contenu — il n'a pas vocation à être rempli (ou en tout cas pas à la place de `Sink`) pour un `MediaRenderer`.

## Impact

Sans formats déclarés dans `Sink`, aucun contrôleur/serveur UPnP tiers respectant la norme ne peut déterminer quel format de flux envoyer à l'appareil. Dans notre cas, cela se traduit côté Lyrion/squeeze2upnp par un échec systématique au démarrage de la lecture, quel que soit le mode de transcodage configuré (`pcm`, `wav`, `flac`...), avec les erreurs suivantes dans les logs :

```
process\_strm:342 no matching codec p
process\_start:1277 something went wrong starting process
sendSTAT: STAT:\[STMf] msplayed 0  (Stream Failed)
```

Le développeur du plugin squeeze2upnp (philippe\_44) confirme sur son forum que ce symptôme précis ("no matching codec" + `Sink` vide) est dû à un renderer qui ne déclare pas correctement ses capacités via `GetProtocolInfo`.

## Suggestion de correctif

Remplir le champ `Sink` de la réponse `GetProtocolInfoResponse` avec la liste réelle des formats audio que Tune sait décoder et envoyer vers le périphérique de sortie sélectionné (ici le DAC USB DENAFRIPS), en respectant la syntaxe standard DLNA/UPnP :

```
http-get:\*:<mime-type>:\*
```

pour chaque format supporté, séparés par des virgules.

## Contournement actuel

En attendant un correctif, la lecture via Tune fonctionne normalement en **mode local direct** (sans passer par le pont UPnP/Lyrion). Seule l'intégration UPnP/DLNA avec des contrôleurs tiers est affectée.