Version: unspecified (using KDE 4.5.90) OS: Linux Ever time I change to a new folder in Dolphin with a CD or DVD in my drive, the light and the drive comes on and the drive spins up. Dolphin then locks up until it is finished with whatever it is doing with the drive. Reproducible: Always
So you are entering folders that are *not* from the CD or DVD, right? Could you please let us know which panels you have enabled in Dolphin (Information Panel, Places Panel, Folders Panel, Terminal Panel)?
On further investigation, it only happens when opening a new window or a new tab. It does NOT happen on every folder change, but it does happen every time I open a window or tab no matter what folder is being view, and it locks up Dolphin until it is done. It also happens every time I open a save or open dialog (locking up the dialog), but not when I change the folder in the dialog. It happens even when the new window or tab I am opening is not in any CD or DVD driver. It even happens if it is just my home folder. It happens even when I have closed all the panels.
There is a related, but not identical, issue: when I change focus to or from dolphin with the places panel open, it also reads from my CD and DVD drives. This once again locks up dolphin for a few seconds, but it does so every time I click on another window (any window from any program) then back on the dolphin window. I can submit a second bug report if this helps. To re-iterate: The issue with the driver reading when opening new dolphin windows or tabs happens even if no panels are open. The issue with the driver reading when changing window focus only happens when the places panel is open. Both happen even when when viewing a folder that is not on any CD or DVD, and both completely lock up dolphin for several seconds. There are two separate issues here: 1. Reading from the CD or DVD drive locks up the dolphin window. I don't think this should happen when you are not browsing a CD or DVD. It should be able to look up the information it needs without blocking the UI. 2. Dolphin reads from the CD or DVD drive a lot, even when it is not necessary. I would think it needs to read the CD or DVD drive when the disk is inserted, perhaps when it is mounted. CDs and DVDs do not change that often, so it should not need to read from them very often, certainly not on a focus change or every time you open a new tab.
Sorry for the double-post, but I realized something else. both of these issues only happen when the disc is inserted but not mounted. So if the disc is mounted, both of these problems seem to stop. So it seems to be something dealing specifically with non-mounted discs.
I can confirm this behaviour. This slowed down dolphin-startup extremely, took ~3 seconds. Could it be that solid queries all devices, when the places-view triggers a repaint? Could this info be cached somewhere?
Confirmed here on KDE 4.6.1. When I have a CD in my drive (curiously the Driving School CD did not do anything, the Star Trek Armada 2 CD causes those issues) and launch anything that has the Places bar in it, i.e. a Dolphin window or a Save/Open dialog, the CD starts up spinning and until the CD has reached its full speed, nothing responds or opens. After that everything works just fine. This does not happen alway if the CD is already stopped but I think after some time when the CD is really idling then.
Even if the CD has went to idle and Dolphin just gets FOCUS, i.e. you click on the Dolphin window it locks up until the CD is fully spinning. This is so annoying, I just want to “park” my CD in the drive since I play the game sometimes and don‘t want to insert the disc since it‘s the only game I am playing at the moment (that requires a CD). But it is just impossible working fluently if every Open dialog, ever Dolphin window is just slow and unresponsive because of that behavior. I would even appreciate Dolphin not getting the CD title or CD icon if it would just make it stop lagging.
It gets even stuck completely when you‘re accessing an external hdd (which is currently busy because of some copy action) and thus does not respond quickly or just went to idle…
It's really annoying.
*** This bug has been confirmed by popular vote. ***
*** Bug 270220 has been marked as a duplicate of this bug. ***
For assigning this to the correct sub component it would be helpful to check: - Does something change if the Places Panel of Dolphin is hidden (see comment #1)? - Is the issue reproducible also when changing directories inside the file-dialog (e.g. when opening a document in kwrite)? Thanks!
It even gets Plasma to hang if you are browsing the desktop widget… Hiding the Places panel did not help here. Yes, file dialog is also affected, when opening it hangs. Or if the CD has gone to idle then it also hangs when changing directories just like dolphin does.
Thanks for the update. I've added Kevin Ottens and David Faure to CC as this issue is not related to Dolphin. But I don't know whether it is related to Solid or something in KFilePlacesView...
Looks like the UDisks backend hits the advanced content probe too easily.
Is there some progress in fixing this? Or is it that hard? It really sucks, having a helicopter starting beside your desk (and a lag for several seconds) every time you open/save/browse files. Even hiding the DVD-device in places-view does not help (why is it neccessary to query non-visible devices?) If i can help fixing, please tell me where to look at. I browsed the sources, but really did not know, where to find the "advanced content probe".
Hm, I think the problem lies in: kdelibs/solid/solid/backends/udisks/udisksopticaldisc.cpp The behavior of m_needsReprobe seems outrageous. I think I will temporarily force-false this variable since I do know what kind of optical media I have in my drive ^^
Hmmm... There are 2 points, where m_needsReprobe is set to true: * initialization list (l. 165, kde-4.7.0) * OpticalDisc::slotChanged() [private] (l.254) slotChanged gets called whenever UDisksDevice::changed() ist emitted. This is done solely in UDisksDevice::slotChanged() [private], which gets called only when the UDisks-DBus-Service says "Changed()!" This is what i can see from the sources, so probably it is no Solid-problem, but one in UDisks. Or a config-issue :/
How does udisks know when you click on a folder in Dolphin?
(In reply to comment #19) > How does udisks know when you click on a folder in Dolphin? That's not what I meant. I thought, that somehow UDisks emits a Changed() too easily, so that m_needsReprobe get's true, and the next time e.g. the places-view queries the disc-contents, the advanced content probe is triggered -> disc spin. But I really don't know enough about solid, udisks or dbus. I just looked, where m_needsReprobe is set to true, and followed the way up...
OK, it's not a problem with UDisks. Missing AVX-Support in valgrind threw stones in my way, but finally I got callgrind running on another PC. The problem seems to be, that OpticalDiscs-Objects get instantiated much too often. Each object gets constructed with m_needsReprobe set to true, and querying content triggers the advanvedContentsProbe. CallGrind tells me, that 1 call came from UDisksDevice::createDeviceInterface(), 20 calls from UDiscsDevice::icon(). Filtering for "advancedDiscDetect" does not return a result (probably the function gets inlined), Searching for "QFile::encodeName" gives me one entry with 20 calls (among 7000 others): OpticalDisc::availableContent() which gets called 20 times by UDiscsDevice::icon().
Created attachment 67030 [details] remove the hack, that works around udisks/udev-shortcomings The patch also applies fine to kdelibs-4.7.4. I don't know, who to blame, but it really seems to be a problem within either udisks or udev. ============== $ udisks --show-info /dev/sr0 [...] mounted by uid: 0 presentation hide: 0 presentation nopolicy: 0 presentation name: presentation icon: automount hint: size: 8268341248 [...] ===================== udisks tries to get the icon through the udev-DB. As even udisks says "I don't have an icon", I think KDE should not try to be smarter. nautilus also doesn't. Somehow I thought, Gentoo just forgot to install some dependencies, that would automagically make PresentationIcons appear in udisks. So I installed Gnome. And - no - even when running a Gnome-Session, there is no PresentationIcon in udisks. Nautilus also just shows the plain "media-optical"-Icon. So I removed the "we want to be exact and smart"-Code, that creates UDisks::OpticalDisc-objects again and again, just to show the best icon. In my opinion, this is just a hack. For those of you that don't suffer from this problem, please could you look into your udev-rules, if there are some hints that could fix the root of this problem.
Ping, any news on this?
Created attachment 73997 [details] Adds a global cache, so advancedDiskDetect calls occour less frequently Commenting out the line m_cachedContent |= advancedDiscDetect(m_device->prop("DeviceFile").toString()); in "solid/solid/backends/udisks/udisksopticaldisc.cpp" fixes the problem for me. But maybe it's not the best solution possible. It seems that OpticalDisk instances are recreated frequently, so m_needReprobe almost always is set to true. I created a patch that adds global cache for availableContent(), and now dvd drive spins up only when I open a new Dolphin window. Sadly I don't know how to make such cache shared between processes. Maybe advancedDiskDetect just shouldn't be called for non-mounted disks.
OpticaIDisc instances are indeed recreated on demand by Dolphin or the Device Notifier so adding a global cache like this is a good idea, not so much with commenting out the advancedDiscDetect line ;) Going to give the patch a try and submit, thanks a lot!
Git commit 9177a643eb5bd3208b3c6c7a15097fb11b32bf48 by Lukas Tinkl. Committed on 18/09/2012 at 17:39. Pushed by lukas into branch 'KDE/4.10'. Fix 261552 - Dolphin reads CD or DVD with every folder change by introducing a QMutexLocker around the sensitive part M +22 -2 solid/solid/backends/udisks/udisksopticaldisc.cpp http://commits.kde.org/kdelibs/9177a643eb5bd3208b3c6c7a15097fb11b32bf48
Git commit 9b8a0ef5fd6cf3e9334d69f8ee458c1895a42394 by Lukas Tinkl. Committed on 18/09/2012 at 17:39. Pushed by lukas into branch 'KDE/4.9'. Fix 261552 - Dolphin reads CD or DVD with every folder change by introducing a QMutexLocker around the sensitive part M +22 -2 solid/solid/backends/udisks/udisksopticaldisc.cpp http://commits.kde.org/kdelibs/9b8a0ef5fd6cf3e9334d69f8ee458c1895a42394
Git commit 05d37a921b85e3bf1b3983f758bd1bce61242252 by Lukas Tinkl. Committed on 18/09/2012 at 17:50. Pushed by lukas into branch 'KDE/4.10'. similar mutex locker fix for udisks2 backend M +21 -1 solid/solid/backends/udisks2/udisksopticaldisc.cpp http://commits.kde.org/kdelibs/05d37a921b85e3bf1b3983f758bd1bce61242252
Created attachment 74014 [details] Use SOLID_GLOBAL_STATIC instead of global variables Please apply this patch too
*** Bug 264487 has been marked as a duplicate of this bug. ***
Git commit 3f07cb578e2c62a498f313cbc7b0249d0c841abd by Lukas Tinkl. Committed on 19/09/2012 at 10:20. Pushed by lukas into branch 'KDE/4.10'. use SOLID_GLOBAL_STATIC for the mutex M +10 -10 solid/solid/backends/udisks2/udisksopticaldisc.cpp http://commits.kde.org/kdelibs/3f07cb578e2c62a498f313cbc7b0249d0c841abd
I don't think that this bug is completely fixed. I still experience unnecessary disk spin-ups. They happen less frequent than without patch, but they are still unnecessary. This happens because cache isn't synchronized between processes. It is much better to move the caching to some daemon, or share the cache somehow. Does solid have any daemon? Also, advancedDiskDetect looks too low-level. Is scanning of non-mounted disks really needed? It seems that other DEs don't do this.
*** Bug 184449 has been marked as a duplicate of this bug. ***
*** Bug 268103 has been marked as a duplicate of this bug. ***
No comment since more than 4 months, not even assistance in fixing this issue. Seems to be really hard to tell people where such a global cache should be put... This bug REALLY made KDE unusable for me: Many apps (gwenview, all calligra-apps, kdevelop, digikam, kile and many more) add a view on the filesystem in the mainwindow. Those apps need several seconds to start up making it unusable to work. I like kde, but it's time to leave... This is the main issue, though there are some others.
This bug should be completely fixed in 4.9.5 and 4.10, what version are you using?
4.9.5 on one PC, 4.9.98 on the other one. Also tried most recent fedora-patches to incorporate udisks2-backend, when updating to 4.9.5 still showed this issue.
Franz : Your issue is that upon application startup your drive is scanned, which is true and, when combined with a slow drive, is a nuisance. This bug is about the scan occuring on every folder change/tab creation (which is truly fixed).
Martin: Read comments #2 and #3 - "On further investigation". From that point the "DVD spin up on new window" was one of the central points. At that time the summary should have been changed to something more appropriate. Furthermore, comment #32 even mentioned the "global cache" and the willingness to help - no response.
short update: 4.9.98 with udisks2-backend indeed seems to have fixed the issue, but not udisks1. I also had a look at the CMakeLists.txt: it is not possible to build WITHOUT ANY udisks when on linux: if ( WITH_SOLID_UDISKS2 ) # add usidks2-sources else ( WITH_SOLID_UDISKS2 ) # add udisks1-sources endif ( WITH_SOLID_UDISKS2 ) Is that really by intention?
Yes, building w/o udisks(2) on Linux doesn't make sense these days, HAL has been dead for a long time
May be, but think of the people who don't need such device-managers. Or people who are happy that they still can have a decent desktop without all that polkit/consolekit (sorry, dead - systemd...) stuff.
GRRRR! When I claimed this finally was fixed I was running gnome3. This morning I started kde desktop - and spinning optical disks start driving me crazy again! I even created a test user (in case it is borked config related) and still the same issue. So please could someone tell me * where the fix (cache, whatsoever) was introduced (best would be a link to the commit) * if there is an option one has to set (systemsettings,etc.) * some special group I have to be in (as all works fine with gnome3 I don't think so) * some "hidden" service has to be started (All services in "kdmshell4 kcmkded" are checked) I realized that when running gnome3 I get a dbus service "org.gtk.Private.UDisks2DeviceMonitor" registered - might that be related?
see comment #26 through comment #31 for the related commits (with links).
(In reply to comment #44) > see comment #26 through comment #31 for the related commits (with links). see comment #32 why it's not. Those commits linked here just introduced a cache for each client (dolphin application, other apps using filedialog). This still does not prevent the disk spinning for the very first infvocation (dolphin start/open,save file in calligra/...)
true, that may be as good as it gets for now. Certainly better than what bug $SUBJECT suggests
If you want to stop drive spin-ups, just enable automounting. It seems that mounted filesystem's contents are cached by kernel. My fix couldn't be enabled/disabled, so no options, no groups, no hidden services. Also this fix possibly introduces another problem - if disk is changed when there is no UDisksOpticalDisk class instances, corresponding cache item won't be invalidated, and won't be updated later. It's strange that nobody noticed this. And again: This disk probing code must be moved to a daemon, like automounter, and applications should only request information from it. Maybe I'll try to write it in near future.
> If you want to stop drive spin-ups, just enable automounting. I know that this might fix the issue. But my discs are Video DVDs and Audio CDs - there is no need to mount them in order to read them. I had big trouble in the past when I mounted optical discs (that's why I don't interact with the Device Manager-plasmoid, as it mounts every time even if it is not neccessarily needed!) - I could not eject the disc anymore by pressing the button on the drive. Even worse after pressing it was not possible anymore to eject using the GUI - I had to eject --force as root, which did work in some but not all cases, forcing me to reboot if I wanted to eject the disc... > And again: This disk probing code must be moved to a daemon, like > automounter, and applications should only request information from it. Maybe > I'll try to write it in near future. But that would break every single client that makes use of Solid! Wouldn't it be better to simply store plain data in the daemon. Daemon listens for UDisks-events (new device, device removed, ... don't know what UDisks exposes) and update the data. Solid UDisks-Backend simply queries that daemon.
(In reply to comment #48) > Wouldn't it be better to simply store plain data in the daemon. Daemon > listens for UDisks-events (new device, device removed, ... don't know what > UDisks exposes) and update the data. Solid UDisks-Backend simply queries > that daemon. I meant exactly that
My first attempt at creating daemon: https://github.com/sanya-m/solid-disk-prober Could someone test it? I have only data cd's, so can't test that I didn't broke video cd detection etc. KDE 4.10 and udisks2 required, patch included. For me, drive spin-ups are gone, didn't found any regressions. Commenting here, because it seems that all interested people are subscribed to this bug.
Thx! A! LOT! Works fine here, disc type is recoginzed correctly. (tested with Video DVD and Audio CD). Gentoo users can test this with packages from my overlay: https://github.com/ff2000/gentoo-overlay
was this fixed in 4.9.2? I'm using 4.9.5 and my cdrom always spins up whenever I open dolphin.
I’m running 4.10.2 and now that you reminded me of this bug, I checked again and the issue has gone. Yay! (I’ve had my optical drive open ever since it began, so I never noticed a fix being implemented).
Created attachment 81359 [details] Final (?) fix Today I committed this change. It should finally fix the problem. Please test it. Should apply without problems to 4.10 and 4.11 rc, but it works only for UDisks 2. It would be good to be sure that it doesn't break anything for anyone.