Guida a Logitech Media Server, Squeezelite e derivati.

[UnixMan]

Non so se ti è chiaro, ma il branch "debian" è li perche tu lo possa testare, quando per te sarà definitivamente a posto, faccio la merge in release.

direi che lo sia già: funziona perfettamente.

Provaci anche tu: da una qualsiasi Debian, anche in VM (32 o 64 bit, non ha importanza... se lo fai su una "Jessie" a 32bit mandami i pacchetti che verranno prodotti, così li metto sul solito sito) dai in sequenza questi comandi:

sudo apt-get install dpkg-dev build-essential git
sudo apt-get build-dep squeezelite
cd /var/tmp
git clone -b debian https://github.com/marcoc1712/squeezelite.git
cd squeezelite
dpkg-buildpackage -b

fatto. Se non ci sono errori, in /var/tmp ti ritroverai i due .deb (l'uno con il supporto per "PulseAudio", l'altro per ALSA) per l'architettura del tuo sistema. Non hai che da installarlo con "sudo gdebi nomefile.deb" o "sudo dpkg -i nomefile.deb" ed il gioco è fatto.

BTW: mi sono accorto che c'è un errore minore in uno degli esempi nel file di configurazione (quello che il pacchetto installa in /etc/default/squeezelite), che trovi nel file "debian/squeezelite.squeezelite.default" (in una delle righe manca un "8" alla fine). Se vuoi, cambia gli esempi con questi:

# Additional options to pass to squeezelite:
# Please do not include -z to make squeezelite daemonise itself.
# Give command: "man squeezelite" for option details. Examples:
#SB_EXTRA_ARGS=""
#SB_EXTRA_ARGS="-C 1 -a 250:10:32:1 -r 44100-384000 -u vIE"
#SB_EXTRA_ARGS="-C 1 -a 250:10:32:1 -r 352800-384000 -u vLE:0::28:98"
#SB_EXTRA_ARGS="-C 1 -a 250:10:32:1 -r 352800-384000 -u vIE:0::64:98::"
#SB_EXTRA_ARGS="-C 1 -a 250:10:32:1 -r 352800-384000 -u vIE:2::64:98::"
#SB_EXTRA_ARGS="-C 1 -a 250:10:32:1 -r 352800-384000 -u vIE:8::64:98::"
#SB_EXTRA_ARGS="-C 1 -a 250:10:32:1 -r 352800-384000 -u vIE:32::64:98"

oppure correggilo ed integralo con gli esempi ed i commenti che ritieni più opportuni.

ATTENZIONE:

molto probabilmente cambierò nome al repo in squeezelite-R2

nessun problema.

(però IMHO forse sarebbe bene che, soprattutto in tal caso, la versione "head" -pardon, "master"- sia quella di sviluppo con inclusa la tua patch. Se vuoi tenere copia della versione originale "upstream" ti conviene metterla in un branch apposito chiamato per l'appunto "original" oppure "upstream", "Triode", ecc).

[marcoc1712]

direi che lo sia già: funziona perfettamente.

Provaci anche tu: da una qualsiasi Debian, anche in VM (32 o 64 bit, non ha importanza... se lo fai su una "Jessie" a 32bit mandami i pacchetti che verranno prodotti, così li metto sul solito sito) dai in sequenza questi comandi:

sudo apt-get install dpkg-dev build-essential git
sudo apt-get build-dep squeezelite
cd /var/tmp
git clone -b debian https://github.com/marcoc1712/squeezelite.git
cd squeezelite
dpkg-buildpackage -b

fatto. Se non ci sono errori, in /var/tmp ti ritroverai i due .deb (l'uno con il supporto per "PulseAudio", l'altro per ALSA) per l'architettura del tuo sistema. Non hai che da installarlo con "sudo gdebi nomefile.deb" o "sudo dpkg -i nomefile.deb" ed il gioco è fatto.

BTW: mi sono accorto che c'è un errore minore in uno degli esempi nel file di configurazione (quello che il pacchetto installa in /etc/default/squeezelite), che trovi nel file "debian/squeezelite.squeezelite.default" (in una delle righe manca un "8" alla fine). Se vuoi, cambia gli esempi con questi:

# Additional options to pass to squeezelite:
# Please do not include -z to make squeezelite daemonise itself.
# Give command: "man squeezelite" for option details. Examples:
#SB_EXTRA_ARGS=""
#SB_EXTRA_ARGS="-C 1 -a 250:10:32:1 -r 44100-384000 -u vIE"
#SB_EXTRA_ARGS="-C 1 -a 250:10:32:1 -r 352800-384000 -u vLE:0::28:98"
#SB_EXTRA_ARGS="-C 1 -a 250:10:32:1 -r 352800-384000 -u vIE:0::64:98::"
#SB_EXTRA_ARGS="-C 1 -a 250:10:32:1 -r 352800-384000 -u vIE:2::64:98::"
#SB_EXTRA_ARGS="-C 1 -a 250:10:32:1 -r 352800-384000 -u vIE:8::64:98::"
#SB_EXTRA_ARGS="-C 1 -a 250:10:32:1 -r 352800-384000 -u vIE:32::64:98"

oppure correggilo ed integralo con gli esempi ed i commenti che ritieni più opportuni.



nessun problema.

(però IMHO forse sarebbe bene che, soprattutto in tal caso, la versione "head" -pardon, "master"- sia quella di sviluppo con inclusa la tua patch. Se vuoi tenere copia della versione originale "upstream" ti conviene metterla in un branch apposito chiamato per l'appunto "original" oppure "upstream", "Triode", ecc).

Il fatto è che quando crei il repo come clone da google code, prende i nomi delle branch da la, quindi Master è la sua... Devo fare delle prove, ma mi sono già accorto che qualcuno mi ha clonato... e non posso più rinominare.

Alla peggiorimane così.

Sicuramente ho cambiato il testo in license.txt

[UnixMan]

Alla peggiorimane così.

va beh, poco male.

Sicuramente ho cambiato il testo in license.txt

occhio che quello che finisce nel pacchetto credo sia il file debian/copyright.

[UnixMan]

Ciao,

scusate una domanda: a parte l'interfaccia web (che personalmente detesto, in generale...) di LMS e le App per i dispositivi mobili, non esistono applicazioni client ("controller", o comunque si chiamino nella terminologia dell'ambiente SB) native per PC, ed in particolare per Linux?

Per capirci, qualcosa di simile a quelle per MPD quali ad es. "gmpc", "Cantata", ecc?

Di client per MPD ce ne sono a dozzine... possibile che per LMS non ce ne sia neanche l'ombra?!

[marcoc1712]

Ciao,

scusate una domanda: a parte l'interfaccia web (che personalmente detesto, in generale...) di LMS e le App per i dispositivi mobili, non esistono applicazioni client ("controller", o comunque si chiamino nella terminologia dell'ambiente SB) native per PC, ed in particolare per Linux?

Per capirci, qualcosa di simile a quelle per MPD quali ad es. "gmpc", "Cantata", ecc?

Di client per MPD ce ne sono a dozzine... possibile che per LMS non ce ne sia neanche l'ombra?!

Risposte breve: No, non servono

Risposta lunga:

Esiste squeezeplay, che faceva proprio quello, ma - credo - sia stato completamente abbandonato. Comunque esistono almeno 2 protocolli: CLI e Jive (credo si chiamino così) oltrea slimproto (proprietaio ma open) che permettovo di costruire applicazioni di qualiasi tipo per controllare il server e ti consentono di fare quello che vuoi da qualiasi ambiente, sito web, desktop o locale che tu voglia. ? dalla pagina del server ed hai già alcune info, poi c'è la wiki (poco aggiornata) o il forum.

Io ho realizzato a scopo di test in 10' una piccola applicazione java che dal gestore di libreiria (sempre in java) integrato con i servizi on line (musicbrainz, discogs, last-fm, amazon,...) invia in esecuzione il file al server (ovviamente se raggiungibile), molti hanno integrato gestori di libreria esterni (es MUSO ma anche Itunes).

Sono tutti progetti 'esterni' che fanno uso di LMS motore di broadcasting e si sostituiscono alla sua interfaccia, eventualmente arricchendola con informazioni aggiuntive.

Mia opinione:

La differenza con MPD è che il DB e la libreria è del server, il 'client' (renderer) è il più possibile stupido (v. squeezelite) il (client) 'controller' altrettanto, usa i servizi del server e NON ha dati in locale. A mio avviso è una scelta vincente.

Nel tempo, ci sono stati tantissimi progetti di 'estensione su questi aspetti:

1. migliorare l'interfaccia -> puoi facilmente realizzare SKIN semplici (es. Daphile) ma anche molto complesse usando HTML5 (qualcuno ha realizzato in questo modo una skin clone di gmpc...).

2. aggiungere servizi e funzionalità -> plugins.

3. ampliare i metadati gestiti -> plugins e/o interazione con terze parti.

A mio avviso solo nella situazione 3 (e se hai già quello che ti serve) ha senso realizzare un'interfaccia di controllo che si sostituisca a LMS inviando i comandi direttamente al server in uno dei modi previsti.

Cosa rimpiangi di gmpc o cantata?

[DacPassion]

Secondo me l'interfaccia web di LMS è ben fatta, il problema è usarla da dispositivi come smartphone o tablet in questo caso non è il massimo e l'app è obbligatoria

[UnixMan]

Risposte breve: No, non servono

questo lo dici tu...

La differenza con MPD è che il DB e la libreria è del server, il 'client' (renderer) è il più possibile stupido (v. squeezelite) il (client) 'controller' altrettanto, usa i servizi del server e NON ha dati in locale. A mio avviso è una scelta vincente.

per inciso, guarda che anche MPD si può usare in quel modo: non è affatto obbligatorio che il server che si occupa del DB, dei files e dell'interfaccia ed il "renderer" che li suona siano gestiti dallo stesso processo, o dalla stessa macchina.

1. migliorare l'interfaccia -> puoi facilmente realizzare SKIN semplici (es. Daphile) ma anche molto complesse usando HTML5 (qualcuno ha realizzato in questo modo una skin clone di gmpc...).

detesto le interfacce web almeno quanto tu detesti le CLI...

Cosa rimpiangi di gmpc o cantata?

Tutto. La praticità, il non dover usare un browser e, soprattutto, l'integrazione con il desktop. Più di ogni altra cosa il fatto di poter controllare tutto con la sola tastiera, utilizzando "shortcut" e tasti "multimediali".

Ad es. potevo usare il tasto play/pausa, i tasti per saltare da un brano al precedente o al successivo, quelli del volume. Nonché premere un tasto per visualizzare la finestra del client e premerlo di nuovo per farla scomparire... ecc. Tutto infinitamente più comodo.

Secondo me l'interfaccia web di LMS è ben fatta, il problema è usarla da dispositivi come smartphone o tablet in questo caso non è il massimo e l'app è obbligatoria

ovvio, sul telefono ho messo l'app. Che non è male, ci sono alcune cose che mi piacciono... sebbene per altri aspetti anche da questo punto di vista mi piaceva di più quella per MPD.

[bigtube]

Provaci anche tu: da una qualsiasi Debian, anche in VM (32 o 64 bit, non ha importanza... se lo fai su una "Jessie" a 32bit mandami i pacchetti che verranno prodotti, così li metto sul solito sito) dai in sequenza questi comandi: .........................................................................

sudo apt-get install dpkg-dev build-essential git
sudo apt-get build-dep squeezelite
cd /var/tmp
git clone -b debian https://github.com/marcoc1712/squeezelite.git
cd squeezelite
dpkg-buildpackage -b

fatto.

Paolo ho provato a eseguire il builduing dei deb file con quella procedura per la versione 32 bit i386 di squeezelite ma non ha funzionato.
Questa la risposta della shell dopo l'ultimo comando ( di fatto non ha creato i deb file nella dir Squeezelite )

root@debian:/var/tmp# cd squeezelite
root@debian:/var/tmp/squeezelite# dpkg-buildpackage -b
dpkg-buildpackage: source package squeezelite
dpkg-buildpackage: source version 1.8.1-R2-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Paolo Saggese <pms@audiofaidate.org>
dpkg-buildpackage: host architecture i386
dpkg-buildpackage: warning: debian/rules is not executable; fixing that
 dpkg-source --before-build squeezelite
dpkg-source: info: applying Makefile-tweaks.patch
dpkg-source: info: applying Makefile-portaudio.patch
dpkg-checkbuilddeps: Unmet build dependencies: liblircclient-dev
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
root@debian:/var/tmp/squeezelite#

[UnixMan]

Con E fa upsampling alla MASSIMA AMMESSA

con "massima ammessa" intendi dire la max possibile (a prescindere dal s/r dello stream in ingresso) o il massimo multiplo intero? A me pare sia la seconda: posso vedere il s/r effettivo sul display dell'interfaccia USB e, con quei settings, se mando in play uno stream a 44.1 (o 88.2) leggo 352.8K, mentre se ne mando uno a 48 (o 96) leggo 384K. C'è qualcosa di strano? Non dovrebbe essere così? Che opzioni si dovrebbero utilizzare per impostare l'upsampling "sincrono" (max multiplo intero)?

Questa la risposta della shell dopo l'ultimo comando ( di fatto non ha creato i deb file nella dir Squeezelite )
[...]

dpkg-checkbuilddeps: Unmet build dependencies: liblircclient-dev
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting

Ops... mi ero dimenticato che, rispetto alla versione distribuita da Debian, in questa c'è una dipendenza in più (che ovviamente non viene risolta automaticamente da "apt-get build-dep", che legge quelle del pacchetto sorgente che trova nei repositories, non di quello "locale" di cui non conosce l'esistenza).

Per risolvere, come dovrebbe essere auto-esplicativo dal messaggio di errore, basta che installi la dipendenza (il pacchetto) mancante (sudo apt-get install liblircclient-dev) e poi ripeti l'ultimo comando (dpkg-buildpackage -b).

[bigtube]

Ops... mi ero dimenticato che, rispetto alla versione distribuita da Debian, in questa c'è una dipendenza in più (che ovviamente non viene risolta automaticamente da "apt-get build-dep", che legge quelle del pacchetto sorgente che trova nei repositories, non di quello "locale" di cui non conosce l'esistenza).

Per risolvere, come dovrebbe essere auto-esplicativo dal messaggio di errore, basta che installi la dipendenza (il pacchetto) mancante (sudo apt-get install liblircclient-dev) e poi ripeti l'ultimo comando (dpkg-buildpackage -b).

Certo Paolo,come risolvere è evidente, ce lo dice la shell....mi sembrava opportuno segnalartelo se credi di apportare delle correzioni.
Cosi mi pare che possa essere chiuso il cerchio su malfunzionamenti inattesi e fastidiosi. Se non l'avessi fatto mi avresti rimproverato con tutte le ragioni.
Giusto?