Version: (using KDE KDE 3.1.4) Installed from: Debian testing/unstable Packages OS: Linux I'm not sure if my report is bug or just a wishlist item. I've done some testing concerning Bug 55553 and Bug 60163 because re-scanning of directories works for me partly only, even with version 1.95. If you remove a file from a directory you added sometime before, it disappears form the Collection List and also from a possible custom playlist where it was in. This works - as it should - for restarting juk and also with the Refresh option. But if you copy a new file to a directory you specified before for a playlist, the new track appears in the Collection List (again, as it should do), but it does not appear in the custom playlist you created for this directory. Is this not a bug and the expected behaviour of juk? If so, is it possible to give the custom playlist an option wether the added directory should be rescanned or not? This is very useful if you have a large collection of tracks and have them sorted in different dirs according to - let's say - different styles. Now you generate a playlist for one particular style and you doesn't want to generate the playlist again just because you got some new songs that fits that category. The longer I think about that issue the more I'm sure that it's the best to have the possibility to create two different forms of custom playlists, the one like it is now, and the one I talked about. P.S.: It would be nice to have an option wether to include subdirectories or not if you add a directory to the Collection List or to a custom playlist.
Yeah, this mostly comes from KDE's component for picking up changes in the file system not actually working very well. I meant to add a manual reload of sorts to JuK before the string freeze and just give up on the the automatic stuff, but I had too many other things I was working on at the time and forgot about this issue. I'll see if I can either fix the automatic stuff or find a way to do this without introducing a new string before 3.2. Otherwise it might be stuck this way until post-3.2.
CVS commit by wheeler: Make it possible to rescan the collection by clicking on reload in the RMB or file menu. CCMAIL:65805-done@bugs.kde.org M +1 -1 juk.cpp 1.187 M +8 -0 playlistsplitter.cpp 1.170 M +1 -1 playlistsplitter.h 1.103 --- kdemultimedia/juk/juk.cpp #1.186:1.187 @@ -552,5 +552,5 @@ void JuK::slotPlaylistChanged() action("file_save_as")->setEnabled(false); action("renamePlaylist")->setEnabled(false); - action("reloadPlaylist")->setEnabled(false); + action("reloadPlaylist")->setEnabled(m_splitter->collectionListSelected()); action("deleteItemPlaylist")->setEnabled(false); } --- kdemultimedia/juk/playlistsplitter.cpp #1.169:1.170 @@ -397,4 +397,12 @@ void PlaylistSplitter::slotDeleteSelecte } +void PlaylistSplitter::slotReloadPlaylist() +{ + if(collectionListSelected()) + slotScanDirectories(); + else + visiblePlaylist()->slotReload(); +} + void PlaylistSplitter::slotAddToPlaylist(const QString &file, Playlist *list, PlaylistItem *after) { --- kdemultimedia/juk/playlistsplitter.h #1.102:1.103 @@ -192,5 +192,5 @@ public slots: * \see slotRefresh() */ - void slotReloadPlaylist() { visiblePlaylist()->slotReload(); } + void slotReloadPlaylist(); /**
*** Bug 63454 has been marked as a duplicate of this bug. ***