Bug 113769 - when available m3u files are updated, juk add one more entry in the left panel, instead of updating the existing one
Summary: when available m3u files are updated, juk add one more entry in the left pane...
Alias: None
Product: juk
Classification: Applications
Component: general (show other bugs)
Version: 2.1.2
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Scott Wheeler
Depends on:
Reported: 2005-10-03 12:15 UTC by Mathieu Roy
Modified: 2012-01-26 02:33 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.8.1
Sentry Crash Report:


Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Roy 2005-10-03 12:15:13 UTC
Version:           2.1.2 (using KDE KDE 3.3.2)
Installed from:    Debian testing/unstable Packages

When available (not generated by juk) m3u files are updated, juk add one more entry in the left panel, instead of updating the existing one.

I give you my use case to help you understand the issue.

I have a lot of ogg/mp3 files in a directory mount on NFS. In all top directories there, there's an m3u file that is generated by a perl script.
When I lauch juk for the first time, it correctly add the m3u as playlist, in the left panel.

But if one of these m3u gets updated by the perl script, for some reason, when juk is restarted, it adds one more playlist entry in the left panel, instead of updated the current one. It is quite annoying, makes harder to deal with updated playlist. And weird, since if you say you want to remove the outdated playlist, it will actually want to delete the file which was updated.

There should be only one playlist entry per m3u file.
Comment 1 Michael Pyne 2005-10-04 04:06:01 UTC
Does this happen whenever the .m3u changes, or at the next JuK startup?  I suspect the former but I wasn't aware that JuK had that magic implemented, although it sounds like a quite possible side effect.
Comment 2 Mathieu Roy 2005-10-04 07:52:33 UTC
No, it happen only at JuK startup. 
Comment 3 Michael Pyne 2012-01-26 01:35:45 UTC
OK, I think I see what the issue is (five years late...).

The originally saved playlists are reloaded *after* the search for m3u files. So the m3u files are loaded and make a new dynamic playlist, and then the playlists saved from the last run are loaded. This would lead to duplication with each startup.
Comment 4 Michael Pyne 2012-01-26 02:24:44 UTC
SVN commit 1275917 by mpyne:

Don't load a playlist if it's already found by folder scan.

The way file scanning is performed, it's possible for a playlist that is stored
with a .m3u file to be found and loaded before JuK has finished loading its
cached playlists.

There's a few ways to fix this, but the most conservative (especially for those
dealing with this bug for awhile) is to filter playlists as they are being
loaded from the cache and remove any that have already been loaded. This also does not
require a change to the QDataStream binary format used for saving playlists.

This should fix a bug that's been open for more than five years now... by the
way, anyone want to help with finding/fixing more JuK bugs? :D

 M  +8 -0      cache.cpp  
 M  +9 -1      playlistcollection.h  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1275917
Comment 5 Michael Pyne 2012-01-26 02:33:08 UTC
SVN commit 1275920 by mpyne:

Backport m3u playlist fix to KDE SC 4.8.1.

This backports to KDE SC 4.8.1 the fix given in r1275917 for .m3u playlists
being loaded in duplicate with folder scan enabled.


 M  +8 -0      cache.cpp  
 M  +1 -1      main.cpp  
 M  +9 -1      playlistcollection.h  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1275920