kde 4.6 device actions broken

[Sergio Callegari]

After update to kde 4.6, device actions regarding optical disk are broken.

Inserting an audio cd does not show up in the device manager any action among

open in filemanager
open with k3b
open with kscd

as it should.

Installing amarok makes the single action

open in amarok

appear, but then amarok cannot see the audio cd device anyway.

If I change the kscd action in /usr/share/kde4/apps/solid/actions from

X-KDE-Solid-Predicate=[ StorageVolume.ignored == false AND OpticalDisc.availableContent == 'Audio' ]

to

X-KDE-Solid-Predicate=OpticalDisc.availableContent & 'Audio'

then the kscd action becomes available.

If I try to make the same change as a user from the system settings, then no luck. Don't even know were the personal preference is stored since I do not have a ~/.kde/share/apps/solid dir at all.

So, I don't know if there is a bug wrt the device actions files whose format needs to be updated with kde 4.6 or there is a bug somewhere else in kde 4.6 that is also preventing amarok from seeing the audiocd device.

[Sergio Callegari (callegar)]

By the way, can someone tell me where the personal preferences regarding solid are stored?

[Dominik Cermak (d-cermak)]

The personal preferences are stored in ~/.kde/share/apps/solid/actions.

I think the problem is the change from HAL to udisks. solid-hardware list details list the cd but it says:

SorageVolume.ignored = true

With HAL as backend it says:

StorageVolume.ignored = false

I think thats the key cause the standart actions look like:

X-KDE-Solid-Predicate=[ StorageVolume.ignored == false AND OpticalDisc.availableContent == 'Audio' ]

so it should be:

X-KDE-Solid-Predicate=[ StorageVolume.ignored == true AND OpticalDisc.availableContent == 'Audio' ]

to work.
Still enhanced audio cds are working, solid says StorageVolume.ignored == false.

I don't know whether it is a bug in udisks, solid or in the solid-actions

[Dominik Cermak (d-cermak)]

I want to add, that it's likely no Kubuntu specific problem, as I have the same problem with archlinux.

[Dominik Cermak (d-cermak)]

Sorry in my first post I wrote that it should be

X-KDE-Solid-Predicate=[ StorageVolume.ignored == true AND OpticalDisc.availableContent == 'Audio' ]

but this doesn't work, it should be

X-KDE-Solid-Predicate=[ StorageVolume.ignored == true AND OpticalDisc.availableContent & 'Audio' ]

[Sergio Callegari (callegar)]

Thanks, but:

made a change in my personal preferences from system settings
ls ~/.kde/share/apps/solid/actions still gives
cannot access /home/callegar/.kde/share/apps/solid/actions: No such file or directory
yet the change appears to be persistent.
But anyway, to change the personal setting does not affect at all the wrong way in which device actions behave.

For what concerns solid, it is not clear to me if it is expected to still use hal if it is there (as in my case) or not.

Found the solid-hardware command to enquire about the state of hal.
Still wonder why even those pieces of kde that are meant to be used command line do never have a man page so that one can apropos them.

Wonder if amarok cannot see audiocd for the same reason.

[Dominik Cermak (d-cermak)]

As I understood the release notes, solid doesn't use HAL anymore, no matter if it is there or not.
solid-hardware doesn't show state of HAL but the state of solid.
You can use 'solid-hardware --commands' to show all possible commands. If it is a problem with solid, it's likely that amarok cannot see the audiocd cause it relies on solid.

[Sergio Callegari (callegar)]

Checked with strace. Device actions set from system settings go into
.local/share/applications/
and are then ignored.

[Dominik Cermak (d-cermak)]

I never edited them, only created new ones, they were saved in ~/.kde/share/apps/solid/actions and are not ignored.

[Sergio Callegari (callegar)]

... not that copying them into .kde/share/apps/solid/actions makes any difference.

Editing preferences in the files in /usr/share/kde4/apps/solid/actions makes a difference, though.

So I guess that for the time being it would be better if ubuntu could ship correct entries for /usr/share/kde4/apps/solid/actions and disable the device actions module in system settings which is anyway useless, until this is fixed upstream.

The former would simply consist in leaving only

OpticalDisc.availableContent & 'Audio'

for all the X-KDE-Solid-Predicate for applications that can manage audio CDs.

[Sergio Callegari (callegar)]

When inserting a data cdrom, the proper actions are shown.

However on clicking solid fails to mount the cdrom.
Cannot mount the folowing device: NOLTA99

On the other hand, mounting from the command line with

sudo mount /dev/cdrom /mnt/tmp

works. After having manually mounted the device, clicking on the button in the notifier can correctly open dolphin on the device.

Not clear to me where the problem is.
KDE 4.6 should be a stable release having enjoyed 2 RC cycles and many betas. So I reported the bug in launchpad expecting the problem to be in the packaging. However the problem now appears to me as a bit to extended to be packaging only.
Should I start reporting upstream?

[Dominik Cermak (d-cermak)]

It's likely to be a packaging problem since I tried inserting a data cdrom on archlinux and there are no problems the notifier shows up and clicking on 'Open with Filemanager' works, dolphin opens.

[Dominik Cermak (d-cermak)]

Finaly I tested it with a data cd on kubuntu and I see no problems. Checked it with different cdroms and there are no problems with any of them.

[Sergio Callegari (callegar)]

Tried with another data cd I found around. Same result.

Suppose that I start with a music cd in. If I:

1a) Take out the music CD by pressing the button on the cd drive rather than using the eject button on the device notifier
2a) Insert the data CD

Then the device notifier does not update and keeps telling "play audio cd with amarok" as the single option

If I:

1b) Take out the audio cd by pressing the eject button on the device notifier
2b) Insert the data CD

Then the device notifier recognizes the data CD, correctly printing the CD label and shows me 3 actions: download photos, copy with k3b, open in file manager. Now if I

3c) Click on "Open with file manager" or on the small "mount button" on the right "click to make this device accessible from other applications"

then the device notifier gives me an error "Could not mount the following device CDSTOMPER35"

I wonder if this may then be due to the fact that my computer has been upgraded since lucid, so my .kde folder may contain a lot of coming over information that confuses the system or what.

Any hint at how to debug this?

Specifically

a) Why does the kscmshell4 solid_actions try to save actions in .local/share/applications rather than .kde/share/apps/solid/actions? Is the saving location hardwired or made configurable somewhere?

b) Is there any place where one finds the commands that solid uses to mount devices? Or is it hardwired?

c) Is there something that one can modify to make solid log what it is doing?

[Sergio Callegari (callegar)]

Ok... experimented a bit about how solid-hardware works and found what the latest problem is

One needs to create /media/cdrom0 by hand.

Solid does not manage mount points automatically creating dirs in media at need
Solid does not anymore mount by label... namely should have mounted as /media/CDSTOMPER35 but mounts as /media/cdrom0

[Sergio Callegari (callegar)]

I can also confirm that whenever one ejects a cdrom manually, namely by the driver button, solid does not get anymore the notification that the cd is not anymore there (after 15 minutes still reports the availability of the CD in the drive).

My personal feeling is that the new solid stuff should not have gone into kde at 4.6 being rather immature and untested. So, unless something changes with 4.6.1 etc, I strongly suggest that kubuntu stays with kde 4.5.x for Natty.

[Christoph Schwaeppe (gatonero)]

I'm running KDE 4.6.3 and still have all the problems described above. Is there meanwhile a solution for this strange behaviour?

[Mark Fraser (launchpad-mfraz)]

I've upgraded to KDE 4.7.0 and audio CDs are still not being correctly detected.

[Sergio Callegari (callegar)]

I confirm the issue in 4.7.0 on natty

To summarize:

1) Inserting an audio CD pops up the "play audio cd with amarok" but does not pop up the "play audio cd with kscd", meaning that the solid action for kscd is wrong

2) Indeed the action is wrong, since in /usr/share/kde4/apps/solid/actions/kscd-play-audiocd.desktop it is
X-KDE-Solid-Predicate=[ StorageVolume.ignored == false AND OpticalDisc.availableContent == 'Audio' ]
while solid-hardware clearly shows that the StorageVolume.ignored property should be true and the OpticalDisc.available contain should contain "Audio" rather than being equal to it.

But this is not the only issue.

3) When trying to fix the rule from system settings, the fixed rule goes into
.local/share/applications/kscd-play-audiocd.desktop
from which it is nicely ignored.

Furthermore:

4) If I move the kscd actions to ~/.kde/share/apps/solid/actions, then they remain ignored. Furthermore the system settings stops seeing the updated actions.

[Lari Natri (larva)]

The problem continues existing in Oneiric (beta) with KDE 4.7.0. Many apps have incorrect Solid predicates for optical media (using "==" with OpticalDisk.AvailableContent instead of '&'), but the main problem is that Solid reports StorageVolume.ignored property as being "true" for all optical disc types for some reason.

There are two bugs in KDE bug tracker related to this: 280229 and 265870.

[Mikael Bergqvist (mikaelb)]

Running Kubuntu 11.04, I experience the same problem

[skierpage (skierpage)]

Yes this sounds like https://bugs.kde.org/show_bug.cgi?id=280229 , and in my case it was fixed in the recent KDE 4.7.3 update, which now according to the output of `solid-hardware list details` sets StorageVolume.ignored = false on CD-ROM drives. However, my second CD-ROM drive still doesn't trigger Device Actions, so I filed KDE bug 288854.

[Simon Quigley (tsimonq2)]

Thank you for taking the time to report this bug and helping to make Kubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Kubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. It would help us a lot if you could test it on a currently supported Kubuntu version. If you test it and it is still an issue, kindly upload the updated logs by running only once:
apport-collect 709868

and any other logs that are relevant for this particular issue.