Che errore? Se HQP/Rigel si presenta come renderer UPNP; deve funzionare, ma ci sono molti limiti, tra i quali i formati (dipende dal renderer) ed il gapeless (che credo proprio non sia possibile).
Printable View
Risolto! ;oookk
Era un problema di configurazione del plugin UPnP. Questa è la configurazione che sta funzionando:
https://up.nexthardware.com/user_ima...519_233740.png
Per Rygel, va bene quella fornita con hqplayerd.
stiamo ancora testando... nel frattempo c'è stato qualche altro problemino.
edit: con C3PO... mi ero dimenticato di disabilitarlo per quel particolare "player". Ora tutto a posto. Nei prox giorni RiRo farà tutti i test del caso, e vedremo se saltano fuori altri problemi imprevisti.
@marco
ma con i dovuti accorgimenti non è possibile utilizzare LMS senza passare per UPNP?
Paolo, con questo sistema hqplayer potrebbe risiedere in una terza macchina? (Quindi: pc1 LMS pc2 hqplayer pc3 nad)
allo stato attuale non vedo come. Certo, se Marco scrivesse un plugin LMS specifico per hqp/hqpd o (meglio?) un più generico e versatile plugin MPRIS, magari... :gosh
BTW: una possibile alternativa, già testata e funzionante (che usa comunque UPnP) è utilizzare LMS solo per esportare la libreria (come file server, in sostanza) e comandare hqp via Rygel da un client UPnP. Ma ovviamente è più scomodo e molto meno funzionale.
non ho provato, ma in teoria dovrebbe essere senz'altro possibile.
Bisogna realizzare il bridge 'nativo' verso HQP. Il diavolo è nei dettagli, ma è già stato fatto, oltre che per UPNP, anche per ChromeCast, Air ed altro.
Quello a cui penso io è una cosa molto simile che però pubblica uno stream unico corrispondente alla playlist (per eliminare l problema del gapeless) e non al singolo pezzo come fa questo bridge).
HQP è 'compliant' MPRIS?
Usando HQPCommand o UPNP via Rygel alimenti la playlist di HQP con gli URI dei sincoli pezzi, quindi devi 'replicare' le azioni che fai localmente sulla playlist su HQP. La realizzazione è più semplice, ma i limiti ci sono e sono evidenti. QUello cui pensavo io era qualcosa che limita il colloquio tra HQP ed il server alla sola esecuzione su uno stream continuo (come se fosse una web radio) prodotto dal Bridge che, nella versione più semplice, con HQP scambia solo i comandi:
PLAY(URI dello stream);
STOP;
mettendosi così al riparo da tutte le limitazioni di formato ed altro, mentre tutte le funzionalità aggiuntive vengono limitate all'ambito del rapporto server/client e comandate dal relativo protocollo (Slimproto) ma NON tradotte in comand per HQP, che continua a riprodurre quanto riceve.
Sembra semplice, ma ovviamaente il diavolo è nei dettagli.