Bug 65805

Summary:	rescanning does work partly only
Product:	[Applications] juk	Reporter:	Joerg de la Haye <haye>
Component:	general	Assignee:	Scott Wheeler <wheeler>
Status:	RESOLVED FIXED
Severity:	normal	CC:	tpr
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Debian testing
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Joerg de la Haye 2003-10-10 14:22:09 UTC

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.

Comment 1 Scott Wheeler 2003-11-09 06:00:03 UTC

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.

Comment 2 Scott Wheeler 2004-04-14 03:29:24 UTC

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();
 
     /**

Comment 3 Scott Wheeler 2004-04-19 03:55:47 UTC

*** Bug 63454 has been marked as a duplicate of this bug. ***