Bug 187661 - JJ: "Removed Sound Devices" dialogue does not remember Do not ask again ...
Summary: JJ: "Removed Sound Devices" dialogue does not remember Do not ask again ...
Status: RESOLVED FIXED
Alias: None
Product: Phonon
Classification: Frameworks and Libraries
Component: kded module for audio device listing (show other bugs)
Version: 4.3.0 (KDE 4.2.0)
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Matthias Kretz
URL:
Keywords: junior-jobs
Depends on:
Blocks:
 
Reported: 2009-03-19 23:19 UTC by kavol
Modified: 2010-12-05 21:45 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.4.3


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description kavol 2009-03-19 23:19:20 UTC
Version:            (using KDE 4.2.1)
Compiler:          gcc version 4.3.3 (Gentoo 4.3.3-r1 p1.1, pie-10.1.5) 
OS:                Linux
Installed from:    Gentoo Packages

Hi.

I happen to share one home directory between two computers, one being native and the second over fuse-sshfs. I never login on both computers at once.

At the second computer, where the home directory is mounted from remote, I am always getting a message titled "Removed Sound Devices" after the login. It asks me "Do you want KDE to permanently forget about these devices?" and it lists the soundcard from the first computer. As I want to login at the first computer too, sometimes, I do not want the configuration to get lost and so I answer "No". To prevent to be asked next time, I also check the box "Do not ask again for these devices" before answering. However, after the next login at the second computer, no matter whether I have logged on the first one in the meantime, I get the same question again, and again, and again ...
Comment 1 Kevin Ottens 2009-03-20 08:24:45 UTC
Actually that's phonon which is responsible for this dialog.
Comment 2 Myriam Schweingruber 2009-11-08 14:36:47 UTC
Marked as JuniorJob.
Comment 3 Myriam Schweingruber 2009-11-08 14:52:21 UTC
*** Bug 200157 has been marked as a duplicate of this bug. ***
Comment 4 Dennis Nienhüser 2009-11-23 07:35:32 UTC
(In reply to comment #0)
> I happen to share one home directory between two computers, one being native
> and the second over fuse-sshfs. I never login on both computers at once.

We share the homes for 30 workstations with different hardware over NFS. I'm sure our students would love to have this fixed, so thanks in advance :-)
Comment 5 Dennis Nienhüser 2009-11-23 07:43:30 UTC
(In reply to comment #3)
> *** Bug 200157 has been marked as a duplicate of this bug. ***

To draw attention to the closed bug: I think it's worth to implement both suggestions, storing the settings in a host specific location as suggested in bug 200157 and adding a dont-ask-again option suggested here.
Comment 6 Alex Brandt 2010-01-10 20:13:36 UTC
Would it be appropriate to just store settings in a hostname qualified rc file?  For example: ~/.kde/share/config/${HOSTNAME}-phonondevicesrc.

Regards,

Alunduil
Comment 7 kavol 2010-01-10 21:26:33 UTC
(In reply to comment #5)
>  storing the settings in a host specific location

(In reply to comment #6)
> Would it be appropriate to just store settings in a hostname qualified rc file?

IMO this wouldn't be a good solution, because it would produce a lot of duplicate configfiles on machines that change networks often (like notebooks) ... well, maybe hostid would work better?
Comment 8 Alex Brandt 2010-01-10 21:56:36 UTC
I'm not sure that hostid is going to be unique.  Running hostid on my laptop and a server I have gave me the same output.  Why would hostname change frequently on mobile machines?  Forgive my ignorance, but isn't the hostname a value set in the distribution and not dependent on the network?
Comment 9 kavol 2010-01-10 22:15:57 UTC
(In reply to comment #8)
> I'm not sure that hostid is going to be unique.  Running hostid on my laptop
> and a server I have gave me the same output.

that's strange ... I don't know how the number is computed, but it never gave me the same value on two different machines

but as the lenght seems to be limited to just eight hexadecimal numbers, this doesn't seem too much unique 

>  Why would hostname change frequently on mobile machines? Forgive my
> ignorance, but isn't the hostname a value set in the distribution and not
> dependent on the network?

it depends on the setup - you can get the hostname from DHCP

and also hostname, if chosen by the user, isn't that much unique - but, on the other hand, in the case of the shared homes mentioned in comment #4 I guess the network admin takes care of not having two computers of the same name (hm, but what if they are differentiated by the network and not by the conrete host, like pc1.lab1... pc2.lab1... pc1.lab2...?)
Comment 10 Alex Brandt 2010-01-10 22:45:26 UTC
That's a good point.  We could hash something from /sys or /proc to make a unique identifer, but then that might be something to look into inside of hostid as a command.  I'll poke around there to see how they calculate the number.
Comment 11 Alex Brandt 2010-01-10 23:17:47 UTC
Seems that any of the machines I run hostid on with no /etc/hostid file and that use DHCP return the following value: 007f0100.

Seems to be caused by this (note from man 2 gethostid):

NOTES
       In  the glibc implementation, the hostid is stored in the file /etc/hostid.  (In glibc versions before 2.2,
       the file /var/adm/hostid was used.)

       In the glibc implementation, if gethostid() cannot open the file containing the host ID,	 then  it  obtains
       the hostname using gethostname(2), passes that hostname to gethostbyname_r(3) in order to obtain the host's
       IPv4 address, and returns a value obtained by bit-twiddling the IPv4  address.	(This  value  may  not	be
       unique.)


I'm looking into why Gentoo doesn't have a /etc/hostid file and if it's something easily fixed using hostid should be a viable option.
Comment 12 Myriam Schweingruber 2010-04-10 20:26:07 UTC
Is this still valid with KDE SC 4.4.2/Phonon 4.4.0?
Comment 13 Myriam Schweingruber 2010-07-19 14:50:59 UTC
Closing for lack of feedback. Please only reopen if this is reproducible in KDE SC 4.4.5 or later.