# [audiocd]Chi tardi arriva, male alloggia.[Risolto]

## cloc3

Ho il seguente problema con audiocd:

Se accendo il computer e lo apro, tutto ok. Ma se un secondo utente con le mie stesse caratteristiche (privilegi) vi accede dopo il mio logout, ciccia. Deve proprio fare reboot.

GULP!

----------

## fedeliallalinea

Nel senso che il secondo non sente nulla? Se si probabilmente il device e' ancora occupato prova a vedere con lsof

----------

## cloc3

 *fedeliallalinea wrote:*   

> Nel senso che il secondo non sente nulla? Se si probabilmente il device e' ancora occupato prova a vedere con lsof

 

Sarebbe nulla non sentire: non vede nemmeno!

Quando scrive audiocd:/ sulla barra degli indirizzi di konqueror riceve un messaggio di errore.

Che cosa è Isof ?

```

cloc3@gentoo-amd ~ $ esearch isof

[ Results for search key : isof ]

[ Applications found : 1 ]

*  app-misc/zisofs-tools

      Latest version available: 1.0.6

      Latest version installed: [ Not Installed ]

      Size of downloaded files: 51 kB

      Homepage:    http://www.kernel.org/pub/linux/utils/fs/zisofs/

      Description: User utilities for zisofs

      License:     GPL-2

```

 :Question: 

----------

## fedeliallalinea

Ma che sto audiocd?

Comunque intendevo

```
*  sys-apps/lsof

      Latest version available: 4.71

      Latest version installed: [ Not Installed ]

      Size of downloaded files: 978 kB

      Homepage:    ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/README

      Description: Lists open files for running Unix processes

      License:     GPL-2
```

----------

## randomaze

 *cloc3 wrote:*   

> Che cosa è Isof ?

 

lsod e non isof:

Livorno-Sassari-Oristano-Domodossola

(sta per "list open file")

----------

## fedeliallalinea

 *randomaze wrote:*   

> Livorno-Sassari-Oristano-Domodossola
> 
> (sta per "list open file")

 

Che c'entra domodossola???? Se mai Firenze  :Laughing:   :Laughing:   :Laughing: 

----------

## randomaze

 *fedeliallalinea wrote:*   

>  *randomaze wrote:*   Livorno-Sassari-Oristano-Domodossola
> 
> (sta per "list open file") 
> 
> Che c'entra domodossola???? Se mai Firenze   

 

 :Embarassed:  Vero. Mi sa che é l'ora del caffé  :Rolling Eyes: 

----------

## Onip

 *fedeliallalinea wrote:*   

> Ma che sto audiocd?

 

La spiegazione tecnica non so dartela, ma praticamente "assegna" un filesystem ai cd audio. Infatti aprendo konqueror e digitando

```
audiocd://
```

 si "apre" il lettore cd con i "file" delle varie canzoni e in più anche le cartella "ogg" e "mp3" con i file compressi in quel formato (le specifiche di compressione si impostano nel centro di controllo). Konqueror, inoltre è in grado di "leggere" i titoli e il resto da freedb.org. Quindi per rippare un cd basta aprirlo e copiare la relativa cartella sul disco fisso. Un'ultima cosa, per ottenerol bisogna compilare "kdemultimedia" con le flags audiofile e cdparanoia attivate.

Ciao!

----------

## fedeliallalinea

 *Onip wrote:*   

> La spiegazione tecnica non so dartela, ma praticamente "assegna" un filesystem ai cd audio.

 

Era per essere sicuri. Probabilmente konqueror non rilascia la periferica

----------

## cloc3

[quote="fedeliallalinea"] *Onip wrote:*   

>  Probabilmente konqueror non rilascia la periferica

 

Aiuto. Probabilmente non è konqueror.

Ho scoperto che succede lo stesso con xmms. Si lancia xmms, si configurano le preferenze del plugin CD Audio Player 1.2.10 (libcdaudio.so), definendo una directory per l'ascolto dei cd (per esempio /mnt/audiocd ) e si esegue il contenuto di quel percorso.

L'utente successivo non può accedere allo stesso indirizzo, fino al reboot.

lsof | grep audio (grazie per lo spelling) conferma una attività che si protrae successivamente alla fine della riproduzione.

Se non ci fosse un antidoto, concluderei che l'ascolto di musica, in Linux, non è conpatibile con la multiutenza. Vi prego, smentitemi!

----------

## randomaze

 *cloc3 wrote:*   

> L'utente successivo non può accedere allo stesso indirizzo, fino al reboot.
> 
> lsof | grep audio (grazie per lo spelling) conferma una attività che si protrae successivamente alla fine della riproduzione.

 

Fammi capire.

Tu avvi la riproduzione con un utente e vorresti spegnerla con un altro utente?

----------

## cloc3

 *randomaze wrote:*   

> 
> 
> Tu avvi la riproduzione con un utente e vorresti spegnerla con un altro utente?

 

No. Smetto di ascoltare musica, rilascio la sessione e affido il computer a un secondo utente che fa login con il suo nome e prova ad ascoltare il cd.

----------

## yardbird

 *cloc3 wrote:*   

> 
> 
> No. Smetto di ascoltare musica, rilascio la sessione e affido il computer a un secondo utente che fa login con il suo nome e prova ad ascoltare il cd.

 

Controlla di non avere fatto il login da qualche altra parte con il primo utente. Quanto un utente si logga "acquista" l'ownership di alcuni dispositivi (schede audio, cd, etc.); quando fa il log-out i dispositivi ritornano ad un utente generico, per essere ri-acquisiti dal prossimo utente che fa il login. 

Potresti postare i permessi dei dispositivi interessati (cdrom e scheda audio), prima e dopo il logout del primo utente.

Controlla anche che il secondo utente sia membro dei gruppi che permettono l'accesso alle periferiche cdrom.

----------

## randomaze

 *yardbird wrote:*   

> Quanto un utente si logga "acquista" l'ownership di alcuni dispositivi (schede audio, cd, etc.); quando fa il log-out i dispositivi ritornano ad un utente generico, per essere ri-acquisiti dal prossimo utente che fa il login. 

 

In particolare se avvio xmms dopo aver fatto "su - utente_paritetico" mi da l'errore:

```
alsa_get_mixer(): Attaching to mixer hw:0 failed: Permiso denegado

```

Tutto assolutamente normale se faccio logout/login.

Ergo in futuro magari evita affermazioni come:

 *Quote:*   

> Se non ci fosse un antidoto, concluderei che l'ascolto di musica, in Linux, non è conpatibile con la multiutenza. Vi prego, smentitemi!

 

----------

## cloc3

Innanzitutto scusate se ho ecceduto con i toni, ma evidentemente la questione mi eccita più del dovuto. E' una cosa che mi infastidiva da tempo, ma solo ora ho focalizzato la questione in un modo che mi è sembrato utile per farne un post.

 *randomaze wrote:*   

> 
> 
> Tutto assolutamente normale se faccio logout/login.
> 
> 

 

Questo significa che è un problema esclusivamente mio. Ma mi capita su installazioni diverse.

La cosa strana è che il messaggio che a randomaze è prodotto dall'utente paritetico, a me è generato dal primo, che tuttavia acolta regolarmente la musica.

L'utente paritetico, al quale è negato l'accesso (dopo il logout-login), rileva questo messaggio:

```

maria@gentoo-amd ~ $ xmms

GLib-WARNING **: g_main_iterate(): main loop already active in another thread

```

A questo punto farò ulteriori verifiche sul mio sistema, qualche prova con dei knoppix, dei masterizzatori esterni e qualche ricerchina su internet. A risentirci.

----------

## SilverXXX

Se mi dite come aggiungere audiocd:/ (che da me non c'è, con kde 3.3.1) faccio un pò di prove anch'io, qanto per cercare conferme.

----------

## Onip

c'è nel mio post un op' + sopra....

cmq devi emergere kdemultimedia con le USE flags

```
+audiofile +cdparanoia
```

----------

## cloc3

 *Onip wrote:*   

> c'è nel mio post un op' + sopra....
> 
> cmq devi emergere kdemultimedia con le USE flags
> 
> ```
> ...

 

Grazie, ma purtroppo non credo sia questo il punto, altrimenti audiocd:/ non funzionerebbe affatto:

```

gentoo-amd cloc3 # emerge -pv kdemultimedia

These are the packages that I would merge, in order:

Calculating dependencies ...done!

[ebuild   R   ] kde-base/kdemultimedia-3.3.2  +alsa +arts +audiofile +cdparanoia -debug +encode -flac +oggvorbis -speex -xine -xinerama 0 kB

```

Tra l'altro ho anche qualche problemino di troppo con la masterizzazione da utente che, a questo punto, comincio a pensare connesso. Ma, in concreto, brancolo nel buio.

----------

## Onip

era per SilverXXX che aveva chiesto come metterlo

----------

## SilverXXX

Grazie onip. Cmq ho fatto un pò di prove in lettura, e il cd non mi ha dato problemi (usando kscd).

----------

## cloc3

Forse ho fatto dei passi avanti.

Intanto ho scoperto kscd, che non conoscevo ed è carino. Poi ho visto scomparire sotto il naso l'effetto su di una installazione (senza assolutamente capire il perchè) e, alla fine, ho potuto confrontare le differenze tra le installazioni funzionanti e quelle no.

Credo (ma tengo ancora prudentemente il condizionale) che dipenda dalle impostazioni dei permessi del dispositivo /dev/hdc. Dovrebbe essere:

```

cloc3@gentoo-amd ~ $ ls -l /dev/hdc

brw-rw----  1 cloc3 cdrom 22, 0 15 dic 14:51 /dev/hdc

```

Se invece si ha:

```

cloc3@linux17 ~ $ ls -l /dev/hdc

brw-------  1 cloc3 root 22, 0 15 dic 14:51 /dev/hdc

```

Non funziona. Resta da capire come mai le cose vadano così.

Prima di tutto ho aggiornato le versioni di udev, poi dovrò studiarmi i meccanismi di definizione dei permessi per vedere se c'è qualcosa da correggere. Fino ad ora non avevo assolutamente mai toccato quelle configurazioni.

----------

## cloc3

Confermo. Serve necessariamente:

```

linux17 cloc3 # emerge -pv udev

These are the packages that I would merge, in order:

Calculating dependencies ...done!

[ebuild   R   ] sys-fs/udev-049  (-selinux) -static 0 kB

```

Anche la versione 046 mi dava problemi seri. E' stata dura, però, adesso va tutto in automatico.

----------

## randomaze

 *cloc3 wrote:*   

> Anche la versione 046 mi dava problemi seri. E' stata dura, però, adesso va tutto in automatico.

 

Quindi (suppongo... udev non lo conosco bene) la olpa era del file di configurazione di udev che assegnava alla periferica i diritti sbagliati (anzi, un gid sbagliato).

Gia controllato se é già segnalato su bugzilla?

(se no potresti provvedere tu...)

----------

## cloc3

[quote="randomaze"] *cloc3 wrote:*   

> Quindi (suppongo... udev non lo conosco bene) la olpa era del file di configurazione di udev che assegnava alla periferica i diritti sbagliati (anzi, un gid sbagliato).
> 
> Gia controllato se é già segnalato su bugzilla?
> 
> (se no potresti provvedere tu...)

 

Credo di si. Infatti, prima di emergere il nuovo udev, avevo osservato che la tabella dei permessi di udev era impostata così (cioè proprio come ora):

```

cloc3@gentoo-amd /var/www/localhost/htdocs $ cat /etc/udev/permissions.d/50-udev.permissions |grep cdrom

sr*:root:cdrom:660

scd*:root:cdrom:660

pcd*:root:cdrom:0660

cdrom*:root:cdrom:0660

dvd:root:cdrom:0660

rdvd:root:cdrom:0660

cdroms/*:root:cdrom:0660

```

ma io avevo i permessi tutti ribaltati.

Non credo tuttavia di pubblicare un bug. Per scriverlo decentemente in inglese mi ci andrebbero due giorni, e sono piuttosto occupato. D'altra parte i programmatori queste cose le sanno benissimo: ultimamente le nuove versioni di udev si sono succedute a ritmo serrato, segno che sono consapevoli delle proprie cappelle e che sanno muoversi molto più rapidamente di noi.

Il problema vero è che ho messo su tutte le macchine il solito noiosissimo ~x86, così non posso confrontare le differenze tra le cose vecchie e quelle nuove. Per un attimo ho pensato a tornare x86 su di una, ma mi sono subito accorto dalla lista di emerge di quanto la cosa potrebbe risultare complessa e pericolosa.

----------

## cloc3

Allora:

 *Quote:*   

> 
> 
> gentoo-amd cloc3 # ls /dev/hdc -l
> 
> brw-------  1 cloc3 cdrom 22, 0 dic 21 16:44 /dev/hdc
> ...

 

Mo, una bella seganlazione di baco non gliela toglie nessuno!

----------

