Given a local collection built from audio files located on a autofs mounted network share, Amarok seems to flush the collection data when the connection to that share is lost (or is inaccessible in some way). Upon reconnection, this triggers the rescanning of the entire shared location. This behavior might not really be problematic for small collections but for larger ones, it makes the local collection totally unusable if accessed from a device that's not always connected to the network drive (e.g.: a laptop). Reproducible: Always Steps to Reproduce: 1. Here I'll be assuming your music collection resides on a NAS and is locally mounted via CIFS. 2. Using Autofs, mount your CIFS network share at /somelocation 3. Mark /somelocation/music as being part of your local music collection 4. Make sure: "Watch folder for changes" is unchecked 5. Initiate the collection scan/indexation 6. Close Amarok 7. unmount /somelocation (stop autofs, simulate a disconnection) 8. Start Amarok 9. Intermediate result: Your collection is not accessible (I assume it's been flushed when it failed to be accessed). 10. Restart autofs (re-mount your network drive to /somelocation) 11. Start Amarok Actual Results: Amarok begins re-indexing the collection. Expected Results: Amarok recognizes the share, avoids the re-scanning process and marks the previously indexed files as currently accessible. (Amarok will only remove a file from it's index when the shared location is connected but the file cannot be accessed anymore). Since Amarok now uses Solid as it's backend, I believe that Solid can inform amarok of the presence/absence of an Autofs mounted share so that, using the proper logic, Amarok won't trigger the index purger on disconnection nor will it re-scan the whole drive on reconnection (this problem might also apply to more conventional mounts). Please refer to the following bug for more info: https://bugs.kde.org/show_bug.cgi?id=290755
Also note that the https://bugs.kde.org/show_bug.cgi?id=290755 has been fixed. Namely: Solid should now be able to recognize if /somelocation matches a networked drive. Btw: I haven't tested it on USB drives, but I would expect the local collection to behave in the same way: not re-scanning each time the network drive is reconnected (and I believe that this should be possible with solid).
I have my local collection on an external USB HD and I can't reproduce this here at all, using Amarok v2.8.0-109-g6a9a3b5, no full collection scan I can see, and my collection has +18.000 tracks. I configured my system to auto-mount the USB disk, might be a good idea for your NAS share as well, as Amarok will query Solid on start-up. FWIW: Amarok uses Solid since several years, that is not something recent :) Could somebody test with a NAS?
I did some more tests and I can confirm that Amarok does not rescan the collection if the share has been mounted in /etc/fstab which is good (it also might correctly handle external usb hardrives as well, but I haven't tested this since a year or so) . As for my issue it then seems specific to Autofs. The thing is that Autofs does not create any fstab entry for the mounted share; as mentionned in https://bugs.kde.org/show_bug.cgi?id=290755 solid is now supposed to report this share and Amarok should be aware of it. If you wish to test this setup, you can set a local dummy music collection. Run a samba/cifs server locally and mount the shared folder on another location on your machine using autofs - it shoudl do the trick. (I can provide some config files if needed). Many thanks! Mathieu
I guess this is then not so much an Amarok problem but a mount problem, and maybe a solid one. But with the changes in the various distributions with udev and udev2 and the whole bunch of new stuff this might not be that easy to find the culprit. FWIW: Amarok only uses what Solid provides, it doesn't mount anything, so if there are problems with a specific way of mounting things this should be checked with solid IMHO
My guess would be that Amarok has some interfacing problem with Solid (I'm aware it only provides information). If you refer to https://bugs.kde.org/show_bug.cgi?id=290755, in the end, it clearly says that solid had a problem seeing autofs mounted CIFS shares but this should now be corrected. If the re-scanning was due to a bug in Solid, I guess Nepomuk would behave the same as Amarok - which is not the case. Unfortuntely, I'm not familiar with Amarok's code base but I could try to look into it in the next following weeks. Meanwhile, it might be worthwhile to check with the people who fixed she scanning problem on traditionally mounted shares (see: https://bugs.kde.org/show_bug.cgi?id=171213#c45)
We should be able to easily see whether solid is the culprit please paste inline output of `solid-hardware list details` both when the share is (auto)mounted and when it is not. You may leave just the entries for various storage items (drives, mounts, partitions..).
Created attachment 84073 [details] Output of solid-hardware list details when cifs share mounted with autofs
Created attachment 84074 [details] Output of solid-hardware list details when autofs has been shutdown
Matěj: Seems like the test was worth it: an ediff on the above attachments shows that there is no differences in the output (I attached them anyway for the sake of completeness). This looks like a bug against Solid then. Feel free to let me know what you think about it (I'll see to report the bug in a few moments). Thanks!
(In reply to comment #9) > Matěj: Seems like the test was worth it: an ediff on the above attachments > shows that there is no differences in the output (I attached them anyway for > the sake of completeness). This looks like a bug against Solid then. Feel > free to let me know what you think about it (I'll see to report the bug in a > few moments). Right, these seems to be no entry for your autofs mount in neither of the outputs, which makes Amarok unhappy. In order for Amarok's Dynamic Collection to work properly, it would need an entry for the mount in both cases with StorageAcess.accessible = true/false as appropriate. Please CC me on the solid bug report you've filled and make this bug a duplicate of it. (Use the "Mark at Duplicate" link)
I did some more testing with autofs, and it seems Solid does add an entry after I've been trying to access the share: With autofs on, using the --ghost option, when accessing the share via dolphin, the following entry is added to solid-hardware list details: udi = '/org/kde/fstab///192.168.1.150/share/' parent = '/org/kde/fstab' (string) vendor = 'share/' (string) product = '192.168.1.150' (string) description = 'share/ on 192.168.1.150' (string) StorageAccess.accessible = true (bool) StorageAccess.filePath = '/home/strav/nas/share' (string) StorageAccess.ignored = false (bool) NetworkShare.type = 'Cifs' (0x2) (enum) NetworkShare.url = 'smb://192.168.1.150/share/' (string) With autofs off (when trying to access the mounted root folder or not) it does not appears. Now without the --ghost option, I'm getting somewhat inconsistent behaviours: - If autofs is on and I succeeded in accessing the share, the Solid entry (udi = '/org/kde/fstab///192.168.1.150/share/') is consistently listed whether or not I am accessing the mounted folder. - If autofs is on while I'm disconnected, the udi = '/org/kde/fstab///192.168.1.150/share/ entry still shows up in solid-hardware list details (with: StorageAccess.accessible = true) while accessing the mounted location hangs Dolphin in a very nasty way (killall -9 dolphin is barely effective). Note that this sort of behaviour on faulty mounted network location is the reason I use autofs with --ghost in the first place. In the end, I really ain't sure if the actual collection re-scanning problem with autofs mounted share really is a Solid issue. Thanks for keeping me updated on this!
Mathieu, have you already created the bug report against solid? If yes, please post the information there, not here, and CC me. If not yet, we'll reassign this to solid.
Matěj, Nope I haven't created the bug report yet. Since the autofs-cifs entry is listed after all, I tend to think that Solid does a proper job after all. (As for the issues I'm experiencing without the --ghost option, this might be another story). What I'm unclear about is whether Solid should list the share whether or not it's been accessed (in my sense, perhaps Solid itself should try to access the location and independly report it's accessible or not).
(In reply to comment #13) > Matěj, Nope I haven't created the bug report yet. Since the autofs-cifs > entry is listed after all, I tend to think that Solid does a proper job > after all. It does not, see comment #10 for what would be needed from Solid to make Amarok happy.
*** This bug has been marked as a duplicate of bug 328808 ***