Version: 2.0 svn (using KDE 4.1.2) OS: Linux Installed from: SuSE RPMs If one has playlists within the collection tree and re-scans the collection, they are added again, although they already exist in the playlist-pane. since they did not change, i.e. their filename, content, date and path is the same, they should not be added but skipped as "already existing".
I can confirm this
SVN commit 884294 by nhnielsen: A ton of improvements to the SQL playlists ( the user playlists in the playlist browser ) 1. Playlist generated from files during collection scanning now have a urlid, this is used to ensure that duplicates are not added when rescanning. Instead the playlist is recreated so any updates to the playlist file is reflected in the SQL playlist 2. Streams loaded from a playlist are now given propper title, album and artist values if no service recognizes them. This means that it now works well for keeping a list of, for instance, favorite books from the librivox service. 3. After a collection rescan, any SQL playlists generated or updated based on a playlist file would contain many tracks with no metata at all since the scanner did not give them any. Now a reload of the playlist is forced when it is subsequently used, giving collections a chance to add info about any tracks they know. All this goodnes comes at a cost though. After this update, all old SQL playlists will be deleted ( no files are affected, only playlists stored in the database ). Any playlists based on files on disk can be recovered simply by rescanning the collection. If you have any custom made playlists that you care about, they can be added to the playlist and exported to a file ( and later readded ) _BEFORE_ this update is applied. BUG: 173180 M +3 -3 browsers/playlistbrowser/SqlPlaylistGroup.cpp M +60 -12 browsers/playlistbrowser/UserPlaylistModel.cpp M +1 -0 browsers/playlistbrowser/UserPlaylistModel.h M +57 -4 meta/SqlPlaylist.cpp M +2 -1 meta/SqlPlaylist.h M +3 -3 playlistmanager/PlaylistManager.cpp M +1 -1 playlistmanager/PlaylistManager.h WebSVN link: http://websvn.kde.org/?view=rev&revision=884294
Rev: 940281, it happens again.
Is this still valid with latest SVN?
should have been fixed in svn recently by bart. re-open if not.