Guida a Logitech Media Server, Squeezelite e derivati.

[bigtube]

Marco, sei una persona intelligente... perché -scusa se te lo dico fuori dai denti- dici stupidaggini? Cosa c'entra l'interfaccia utente, CLI o GUI che sia, con i problemi e le difficoltà incontrate da "squonk"?!

.................................................................................................... ...........................................................
“There ain't no such thing as a free lunch”.

Paolo non è una stupidaggine che per dare ordini corretti ed efficaci con la shell bisogna conoscere un numero considerevole di ordini.
Non solo ma bisogna conoscere la sintassi degli ordini da impartire, bisogna conoscere le strutture del filsystem, cos'è e come funziona il kernel e
i moduli. Come diavolo manipolare il sistema e.....posso andare avanti per mezz'ora. La gente comune a meno che non si prenda la briga di
dedicarci tempo e studio non sa' nemmeno da dove iniziare. Averci a che fare è ostico .....c'è poco da dire. squonk probabilmente nemmeno
sospetta che i problemi hardaware sono una cosa concreta e qundo il problema si presenta la prima idea che viene in mente con linux è :
"ma avro' dato gli ordini correttamente" e poi scopri che mancano al tuo bagaglio interi capitoli di cose da sapere. Certo che la liberta' è un
percorso difficile.....ma qualcosa per semplificarlo è doveroso metterlo in atto e certamente si sta facendo di gran lena....ma ancora è un
territorio che non è per tutti. Almeno lo è per chi voglia fare qualcosa di piu' che scrivere una mail o girarsi internet o scriversi una realazione.

[marcoc1712]

Marco, sei una persona intelligente... perché -scusa se te lo dico fuori dai denti- dici stupidaggini? Cosa c'entra l'interfaccia utente, CLI o GUI che sia, con i problemi e le difficoltà incontrate da "squonk"?!

Com'è che su windows hai tutti quei problemi con C3PO che non invece non hai con Linux e MacOS? Colpa della GUI?

Per inciso, dimentichi poi che anche Linux ha le sue GUI. Non una sola, ma molte e diverse (KDE, Unity, Gnome, Cinnamon, Mate, XFCE, ecc, ecc...) tra cui scegliere liberamente quella che si preferisce. Oggi ci sono molti utenti "desktop" che usano Linux senza avere a che fare con una linea di comando più di quanto non facciano gli utenti windoze e mac (cosa che personalmente ritengo un mezzo abominio, ma tant'è).

Tornando in tema, i problemi che ha avuto squonk non sono certo legati all'interfaccia utente, ma al suo HARDWARE specifico. Che presenta delle incompatibilità con (almeno) alcune versioni del kernel Linux (come per altro probabilmente ne ha anche con alcune versioni di Windows, visto che il produttore stesso dichiara come supportate solo alcune versioni specifiche).

Il punto è che esistono troppi hardware (e firmware) diversi. Le diverse combinazioni -ciascuna con le proprie peculiarità ed idiosincrasie- sono praticamente infinite, per cui è materialmente impossibile supportarle e garantire che funzionino bene tutte... a meno che non siano i produttori stessi a farsene carico. Cosa che avviene puntualmente per windoze, stante la sua posizione dominante sul mercato: un produttore di hardware i cui prodotti non fossero compatibili con quello si taglierebbe fuori da una larga parte dei possibili acquirenti, per cui tutti si assicurano che i propri prodotti siano compatibili e funzionino bene con windows (almeno con alcune delle versioni correnti) e si premura anche di fornire l'eventuale supporto software necessario (driver, ecc). Per non parlare poi di Apple, che aggira ed evita il problema a priori fornendo il suo sistema esclusivamente con e per il suo stesso hardware specifico.

Nulla di tutto ciò accade per Linux (e per gli altri sistemi liberi). In questo caso sono gli stessi sviluppatori (per lo più semplici appassionati come te e me) a doversi far carico di supportare -a posteriori- "tutto" l'hardware (cioè, quello che hanno o che gli capita per le mani). Il tutto, nella maggior parte dei casi, senza avere il minimo supporto da parte dei produttori. Che anzi, al contrario, a volte fanno di tutto per mettergli i bastoni tra le ruote. Al punto che non di rado è necessario ricorrere addirittura al "reverse engineering"!

Se volete evitare rogne, prima di comprare un qualsiasi pezzo di hardware, assicuratevi che sia perfettamente compatibile con il sistema con cui volete utilizzarlo. Se nella lista dei sistemi supportati leggete solo "Windows versione x/y", girate alla larga. O aspettatevi possibili problemi...

È il prezzo della libertà. Il totalitarismo funziona, ed è semplice. La libertà non è mai semplice, né tanto meno facile. È fragile, complessa, e richiede sforzi ed attenzione costanti. Non viene mai gratis. Bisogna sapersela conquistare e mantenere.

“There ain't no such thing as a free lunch”.

Temevo questo e forse faccio pure male a chiarire, ma ci tengo, visto che mi ritengo solo mediamente intelligente ma ENORMEMENTE dotato di cocciutaggine...

Non ho detto che non ci sono GUI per Linux o che la complessità sia una 'colpa' di chi ha scritto o mantiene le diverse distro di linux, ma è un dato di fatto, come tu spieghi benissimo, amplificato dalla necessità di funzionare su una molteplicità di hw a fronte di una minor 'suasion' nei confronti dei produttori di hw.

Per questo realizzare qualsiasi cosa in Linux (ed a maggior ragione in multipiattaforma) è complicato, costa molto più sforzo.

Farlo solo per Win è più semplice, farlo solo per un ambiente Linux controllato (es. Daphile) pure, come dici tu la libertà di scelta si paga (...anche se a pagarla è chi realizza e non chi utilizza...).

Le difficoltà che sto avendo sono dovute a Perl su Windows, in Java o C non le avrei, questo perchè perl è nato per sistemi *x e la portabilità su win non è sempre garantita (nella fattispecie Filehandle ed IO), altro dato di fatto, che dimostra come l'incompatibilità va nei due sensi e nessuno è immune da errori o lacune.

Quello che mi sta facendo perdere un sacco di tempo è che mi tocca riscoprire l'acqua calda, come se nessuno avesse mai dovuto scrivere in perl un programma che necessita di sincronizzare in e out (anche) su windows... Però i Monaci (mome adeguatissimo!) del perl scrivono di tutto ma non dei problemi di portabilità e della loro soluzione... cosa ci vorrebbe a pubblicare una libreria che risolva o anche solo un esempio reale? Ma no, se vuoi usare win devi soffrire e la soluzione te la cerchi da te, così nel frattempo impari quanto è bello POSIX...

Vabbè...

Quello che ho scritto riguarda però più la 'forma mentis' di chi storicamente è più vicino ai sistemi linux, che spesso - come te - "ritengono un mezzo abominio", non avere a che fare con la riga di comando, per definizione basata sul paradigma VERBO, OPZIONI, OGGETTO.

Chi ha vissuto dal di dentro la rivoluzione Apple dei primi anni 80 (come me) sa benissimo la grandissima fatica e battaglia che si è combattuta per imporre l'altro paradigma agli addetti ai lavori, che ora come allora vivrebbero contentissimi con la riga di comando, ma la 'mente' della maggioranza delle persone fa fatica a ragionare così, come fa fatica a ragionare in partita doppia...

Sai che la definizione della 'struttura' dei menu mela, File ed Edit (presenti sempre ed ovunque in mac) è costata qualcosa come 16 anni uomo di lavoro e che Steve Jobs non ha voluto il tasto destro sul mouse perchè 'poco immediato'? La battaglia sul se ammettere o meno gli shortcut da tastiera è stata epica (lotus funzionava SOLO con gli shortcuts ai tempi) e si è conclusa in pareggio: sono stati ammessi solo quelli 'sensibili al contesto' cioò riferibili all'oggetto selezionato, non a verbi generici.

Il corso per diventare sviluppatore certificato apple era incentrato su questi principi e pochissimo sugli aspetti tecnici, ma ha portato al primato di mac per lungo tempo.

Nell'ambito della programmazione, questo ha segnato il passaggio dall'approccio funzionale/procedurale (tipico delle righe di comando e dei linguaggi di terza generazione o precedenti) a quello ad oggetti, ed oggi direi che non esiste più battaglia.

Non mi devi convincere che per un sistemista la riga di comando è molto più versatile di una GUI, così come so che per un ragioniere non esiste modo di ragionare diverso dalla partita doppia, ma per tutti gli altri entrate ed uscite è bastevole e più chiaro di dare/avere...

Comunque, è ovvio che i problemi specifici NON SONO MAI generati dalla mancanza di una gui (anzi, a volte sono generati dalla presenza di una gui) , ma la sensazione di 'troppo difficile e complicato' che si abbatte sui neofiti è in buona parte dovuto a quello.

Chiedi a squonk se per lui il problema è il suo hardware (che - ha ripetuto più volte - con Daphile va) o che piuttosto 'linux' (come se daphile fosse altro) è troppo complicato e 'delicato'.

Hai certamente ragione tu dal punto di vista tecnico ed oggettivo, ma quello che squonk si porta con se e - presumibilmente - riporta ad altri è proprio questo...

Mac (ed altre belle distro grafiche linux) dimostra invece come sia possibile mascherare la complessità, pur se a maggor costo, ma - francamente - a me traspare spesso la 'mentalità' sottostante...

Es. Se voglio far ripartire LMS in Ubuntu:

TERMINALE ->sudo /etc/init.d/logitechmediaserver restart. -> password -> restarting logitechmediaserver.

Non è 'naturale' ed i passi richiesti ad un utente 'normale' per automatizzare la cosa in uno shortcut da scrivania (ad esempio) sono ben oltre le sue (e mie) normali capacità.

Fai un esercizio, prova a descriverli (anche perchè così li uso ).

In mac è peggio, non ci sono mai riuscito e devo accendere e spegnere il mac... (v. sopra).

in win lo fa l'installer, ma sarebbe banale.

Cosa sarebbe costato ai guru del perl di logitech (o della comunità) sistemare e rendere disponibile questi shortcut? Semplicemente per loro non è importante... Ed infatti i forum sono pieni di thread su come avviare e spegnere LMS in mac e linux, con lenzuolate di scripts incomprensibili ai più.

Questo è quello che volevo dire e su cui vi invito a pensare, non è (quasi) per nulla una questione tecnologica, solo di forma mentis, ma è anche solo un'opinione, OVVIO che ognuno è liberissimo di pensarla come crede, soprattutto quando parliamo di progetti 'pro bono' come questo.

[marcoc1712]

Paolo non è una stupidaggine che per dare ordini corretti ed efficaci con la shell bisogna conoscere un numero considerevole di ordini.
Non solo ma bisogna conoscere la sintassi degli ordini da impartire, bisogna conoscere le strutture del filsystem, cos'è e come funziona il kernel e
i moduli. Come diavolo manipolare il sistema e.....posso andare avanti per mezz'ora. La gente comune a meno che non si prenda la briga di
dedicarci tempo e studio non sa' nemmeno da dove iniziare. Averci a che fare è ostico .....c'è poco da dire. squonk probabilmente nemmeno
sospetta che i problemi hardaware sono una cosa concreta e qundo il problema si presenta la prima idea che viene in mente con linux è :
"ma avro' dato gli ordini correttamente" e poi scopri che mancano al tuo bagaglio interi capitoli di cose da sapere. Certo che la liberta' è un
percorso difficile.....ma qualcosa per semplificarlo è doveroso metterlo in atto e certamente si sta facendo di gran lena....ma ancora è un
territorio che non è per tutti. Almeno lo è per chi voglia fare qualcosa di piu' che scrivere una mail o girarsi internet o scriversi una realazione.

Ci siamo sovrapposti, ma esprimi molto più sinteticamente il mio pensiero.

[UnixMan]

Non ci siamo capiti: nessuno mette in discussione il fatto che una GUI sia (possa essere...) più "intuitiva" di una CLI, specie per un utente inesperto. È ovvio: le GUI sono state inventate proprio per quello.

Per contro, è altrettanto ovvio che una buona CLI (come quelle Unix o al limite quella di VMS, non certo quella cosa indegna che c'è sui prodotti M$, da DOS in poi...) è enormemente più potente e versatile di qualsiasi GUI. Nonché, per molte cose, anche molto più comoda e veloce (se la conosci e la sai usare, ovviamente).

Ma il punto era tutt'altro: che c'entra l'interfaccia utente con i problemi incontrati da "squonk"?

[UnixMan]

Puff, pant... finalmente sono riuscito a trovare un attimo di tempo per rimettere mano allo script.

Se non mi è sfuggito qualcosa, dovrei aver aggiunto tutti i vari suggerimenti. Incluso questi:

Pei i nostri scopi, questo sembra un articolo interessante...

Linux Tune Network Stack (Buffers Size) To Increase Networking Performance

(anche se ho qualche serio dubbio che sia effettivamente utile ai nostri fini; anzi, alcuni dei settaggi suggeriti potrebbero essere controproducenti).

...ed altro ancora. Ho anche aggiunto opzioni per disabilitare completamente lo swap e disinstallare il syslogger (rsyslog).

Lo script è stato modificato in modo da poter essere (ri-)eseguito anche per aggiornare un sistema che era già stato configurato con una versione precedente; i vecchi files di configurazione vengono rinominati aggiungendo un suffisso ".bak", e sostituiti con quelli nuovi.

Per evitare perdite di tempo negli aggiornamenti, nonché per scopi particolari, ho aggiunto una opzione per eseguire la sola configurazione di base, senza (ri)installare né LMS né squeezelite.

Ho pensato di aggiungere anche un "menù" per selezionare semi-automaticamente il dispositivo di uscita per squeezelite. Ma per metterlo a punto mi ci vorrà un po' di tempo, per cui la cosa è rimandata ad una prossima versione.

Lo script è al solito posto (dove restano disponibili anche le vecchie versioni, rinominate con l'aggiunta di un numero progressivo) e le "istruzioni per l'uso" restano le medesime.

Tanto per cambiare, anche stavolta ho appena terminato di metterci mano e non l'ho ancora testato... quindi vale il solito avvertimento sulla probabilità di sviste ed errori vari. Lo proverò ed apporterò le eventuali correzioni appena possibile. Nel frattempo, se qualcuno volesse darci una occhiata...

http://www.audiofaidate.org/sw/aasetup.sh

[marcoc1712]

...Ma il punto era tutt'altro: che c'entra l'interfaccia utente con i problemi incontrati da "squonk"?

Nulla se non che avrebbe reso più semplice la sua esperienza, ma non tanto per quanto riguarda i problemi reali che ha incontrato, quanto la capacità di muoversi e sperimentarli da solo senza derivarne l'impressione di essere troppo complicata e fuori della sua portata...

E' davvero necessario quel calvario per rendersi conto che il tasto mute è stato premuto? Io non credo, una bella gui che lo raffiguri avrebbe reso la cosa semplice e banale. E' tanto vero che è saltato agli occhi non appena ha lanciato alsamixer, con la sua ORRENDA GUI.

Squonk è arrivato ai problemi veri, quando ormai era abbattutto, frastornato dalle inutili difficoltà sui non problemi...

[antonellocaroli]

Puff, pant... finalmente sono riuscito a trovare un attimo di tempo per rimettere mano allo script.

Se non mi è sfuggito qualcosa, dovrei aver aggiunto tutti i vari suggerimenti. Incluso questi:

(anche se ho qualche serio dubbio che sia effettivamente utile ai nostri fini; anzi, alcuni dei settaggi suggeriti potrebbero essere controproducenti).

...ed altro ancora. Ho anche aggiunto opzioni per disabilitare completamente lo swap e disinstallare il syslogger (rsyslog).

Lo script è stato modificato in modo da poter essere (ri-)eseguito anche per aggiornare un sistema che era già stato configurato con una versione precedente; i vecchi files di configurazione vengono rinominati aggiungendo un suffisso ".bak", e sostituiti con quelli nuovi.

Per evitare perdite di tempo negli aggiornamenti, nonché per scopi particolari, ho aggiunto una opzione per eseguire la sola configurazione di base, senza (ri)installare né LMS né squeezelite.

Ho pensato di aggiungere anche un "menù" per selezionare semi-automaticamente il dispositivo di uscita per squeezelite. Ma per metterlo a punto mi ci vorrà un po' di tempo, per cui la cosa è rimandata ad una prossima versione.

Lo script è al solito posto (dove restano disponibili anche le vecchie versioni, rinominate con l'aggiunta di un numero progressivo) e le "istruzioni per l'uso" restano le medesime.

Tanto per cambiare, anche stavolta ho appena terminato di metterci mano e non l'ho ancora testato... quindi vale il solito avvertimento sulla probabilità di sviste ed errori vari. Lo proverò ed apporterò le eventuali correzioni appena possibile. Nel frattempo, se qualcuno volesse darci una occhiata...

http://www.audiofaidate.org/sw/aasetup.sh

Ti faccio sempre i complimenti per questo script!!! che risolve molte rogne!!!

L ho subito provato!!!

Adesso lo script puó essere lanciato anche da utente normale senza sudo poi ti chiede la password di root...

Mi da un errore nell´installazione si squeezelite:

Download ed installazione di squeezelite-R2
/var/tmp /var/tmp /home/filippo
2015-11-22 08:46:36 URL:http://www.audiofaidate.org/sw/squeezelite_1.8.1mc2-1_amd64.deb [72408/72408] -> "squeezelite_1.8.1mc2-1_amd64.deb" [1]
./aasetup.sh: riga 170: gdebi: comando non trovato
/var/tmp /home/filippo
Failed to stop squeezelite.service: Unit squeezelite.service not loaded.
Setup completato. Saranno ora visualizzate le note finali, che si prega di
leggere attentamente. Utilizzare i tasti freccia e PgUp/PgDn per scorrere il
file. Premere "q" per uscire dal visualizzatore.

I files che state per leggere si trovano nella directory "/var/tmp"; potete
consultarli nuovamente in seguito con il comando "less nome_del_file".
Premere "Invio" per continuare...
./aasetup.sh.*.txt: File o directory non esistente
/home/filippo
That's all, folks!

Il resto é tutto ok anche cat /sys/class/rtc/rtc0/max_user_freq

Tranne
in /etc/default/grub manca intel_idle.max_cstate=0
GRUB_CMDLINE_LINUX="threadirqs intel_idle.max_cstate=0"

nel mio specifico caso per esempio questo parametro é importante, mi elimina un fastidioso fischio quando la cpu é in idle....

non so se é importante, manca in
/etc/sysctl.conf
fs.inotify.max_user_watches = 524288

Installare le cpufrequtils
e impostare in /etc/init.d/cpufrequtils
cambiare GOVERNOR="ondemand" in GOVERNOR="performance"

Originariamente inviato da antonellocaroli
Pei i nostri scopi, questo sembra un articolo interessante...

Linux Tune Network Stack (Buffers Size) To Increase Networking Performance

Paolo se le ritieni controproducenti non metterle

[DacPassion]

Paolo, ancora non ti sei pronunciato, hai fatto qualche confronto tra questo sistema e quello che utilizzavi precedentemente (mpd credo)?

[marcoc1712]

Ti faccio sempre i complimenti per questo script!!! che risolve molte rogne!!!

Mi aggiungo. Va esattamente ed efficacemente nella direzione di nascondere complessità, quindi ottimo!

p.s.

Grazie per aver cambiato il nome a squeezelite.

[UnixMan]

Nulla se non che avrebbe reso più semplice la sua esperienza, ma non tanto per quanto riguarda i problemi reali che ha incontrato, quanto la capacità di muoversi e sperimentarli da solo senza derivarne l'impressione di essere troppo complicata e fuori della sua portata...

comprendendo che anche questa è fondamentalmente una questione sostanzialmente psicologica, di "percezione", hai centrato il problema. Però IMHO sei fuori strada sul resto. Purtroppo a mio avviso si tratta di un problema molto più profondo, e sostanzialmente insolubile. Mi spiego (ci provo...).

La prima riflessione è addirittura banale. Di fatto, a ciascuno di noi sembra facile ciò che conosciamo e sappiamo già fare, mentre ci appare (più) difficile ciò che (ancora) non conosciamo e non sappiamo fare. Esempio banale: andare in bicicletta è facile, giusto? Ma prova a pensare a come ti sembrerebbe difficile (se non addirittura impossibile) pensare di dover restare in equilibrio su quelle due ruote sottili se non fossi mai salito su una bici in vita tua, e magari non avessi neanche visto nessuno farlo!

Tornando al contesto in questione, tipicamente un utente Windows si trova spaesato ed in difficoltà ad usare un Mac (a meno che non lo conosca già), e viceversa. Entrambi poi si troverebbero spaesati di fronte ad una GUI Linux. Ed ovviamente vale anche il contrario: un utente Linux che non conosca win o mac si troverebbe spaesato ed in difficoltà di fronte a quei sistemi. Eppure in tutti e tre i casi stiamo parlando di GUI. Tipicamente pure piuttosto simili, quanto meno concettualmente (se non anche "graficamente").

Il problema non è quindi se si tratti di una GUI piuttosto che una TUI, o altro. Il problema è se si tratta di qualcosa di conosciuto, di "familiare", oppure no.

Se il nostro anziché l'installer "text-mode" (l'installatore di Debian, sebbene utilizzi un terminale in modalità testuale è a tutti gli effetti una "Guided User Interface"; più propriamente è una "TUI"; un tempo si sarebbe detta una "interfaccia semigrafica") avesse utilizzato la versione grafica (GUI propriamente detta, in tutti i sensi), non sarebbe cambiato nulla. Così come non sarebbe cambiato nulla se si fosse trattato di un qualsiasi altro installatore di qualsiasi altra distribuzione... o se è per questo di qualsiasi altro OS con cui non avesse già una buona familiarità.

Presumibilmente è un problema che deriva dalla nostra ancestrale paura dell'ignoto: di fronte ad un territorio nuovo e sconosciuto possiamo anche essere incuriositi e/o affascinati ma, fondamentalmente, specie se incontriamo qualche difficoltà, tendiamo sempre ad essere intimoriti e disorientati. C'è poco da fare, è nella natura umana.

Molto poi dipende anche dai presupposti psicologici inculcati dal marketing:

Dopo decenni di martellanti campagne pubblicitarie in tal senso, tutti si sono convinti che Windows e Mac siano "facili da usare". Per cui, se si trovano in difficoltà, automaticamente (ed inconsciamente) pensano: "OK, ma allora sono scemo... il sistema è semplice, sono io che non riesco a vedere la soluzione... cerchiamola, non posso essere così stupido da non riuscire a trovarla da solo".

Al contrario per Linux esiste il mito che "è difficile", complicato, una cosa adatta solo ad hackers e "Nerds", ecc. Di conseguenza, di fronte alla prima difficoltà, anziché cercare di ragionare per trovare la soluzione, il tipico atteggiamento psicologico (inconscio) del neofita è: "OK, questo è troppo complicato per me, non posso farcela"... così non ci prova nemmeno. Mentre magari invece la soluzione è li, banale, davanti ai suoi occhi. Basterebbe osservare, leggere e riflettere tranquillamente per trovare la soluzione (ovviamente sto parlando in generale, non mi riferisco al caso particolare... dove ci sono effettivamente state delle difficoltà oggettive non banalmente superabili).

E' davvero necessario quel calvario per rendersi conto che il tasto mute è stato premuto?

No. Infatti bastava pensarci... solo che a nessuno è venuto in mente. Non è poi così raro che le cose più banali siano quelle cui si pensa per ultimo. Specie se (in questo caso più che comprensibilmente) ci si è convinti di essere di fronte a difficoltà astruse e insormontabili.

Comunque sia, siccome l'esperienza insegna, alla fine dell'esecuzione dello script, tra le varie note che visualizzo, ora ho aggiunto una bella avvertenza che suggerisce di controllare il livello dei volumi e l'eventuale presenza del "mute" con alsamixer, spiegando dove guardare.

(avrei voluto risolvere la cosa in modo ancora più semplice automatizzandola, cosa facilmente fattibile grazie all'interfaccia CLI "amixer" ma, purtroppo, avendo a che fare con configurazioni hardware diverse ed imprevedibili, non sarebbe facile né affidabile da gestire in modo automatico).

Squonk è arrivato ai problemi veri, quando ormai era abbattutto, frastornato dalle inutili difficoltà sui non problemi...

a dire il vero direi che è arrivato (più che comprensibilmente...) abbattuto e demoralizzato a causa dei problemi veri, prima quelli imprevedibili legati al suo hardware e poi a quelli prevedibilissimi (ed attesi) legati ad un progetto appena nato ed ancora tutto da sviluppare ed affinare (il mio script). Solo alla fine si è scontrato con un problema banale...