Version: 1.90 (using KDE Devel) Installed from: Compiled sources OS: Linux Hi, I have my music mp3 files on windows partition which must be manually mounted. If I forgot to mount the drive before starting JuK then all lists (collection and playlists) are empty. After that I closed JuK, I mounted the partition and restarted JuK. Now the collection list is full again but the playlists are still empty although the saved m3u files are still okay. To get the playlists back, I have to do the following: 1. Remove the playlist without deleting the saved file. 2. Close JuK and start it again. 3. Load the playlist from disk with menu item "Open..." It would be nice when JuK could restore the playlists without the workaround. Thanks for this great app! It's my favourite everyday music player. Christian
First some things that will happen -- it will at some point be possible to remove multiple playlists at once. There is also a "reload playlist" that was in CVS a while back, but I've aparently managed to break it somehow. ;-) I could make it so that "reload playlist" worked on multiple playlists at once... Now onto the logical difficulty -- when *should* tracks be removed from a playlist? The logic has been to not add files that don't exist. There kind of needs to be some mechanism for cleaning out the playlists, so just not showing those items would seem a bit problematic. (Playlists could grow without ever having a way to remove items that don't exist.) So there's the issue -- there has to be some sort of precise logic to doing this (i.e. something that can be translated into code). Thoughts?
Hi Scott, A "reload playlist from disk" functionality that works on multiple lists at once would be enough. There doesn't have to be some automatic (magic) "recovery logic" for me. Of course, the other possibility would be to not automatically clear the playlists when the files don't exists. But then you would have to have some flag that visually signals a non existing file and you would need a "clear playlist" function. I don't know if this option is really better. But as I said, a reload playlist function is enough for me. Thanks, Christian
Subject: kdemultimedia/juk CVS commit by wheeler: Make it possible to reload multiple playlists at once. CCMAIL:60356-done@bugs.kde.org M +24 -2 dynamicplaylist.cpp 1.3 M +16 -1 dynamicplaylist.h 1.3 M +10 -1 playlist.cpp 1.109 M +1 -1 playlist.h 1.68 M +1 -0 playlistsplitter.h 1.71
Hi, I just tested you changes and they work flawlessly. It's very easy now to restore all the playlists. Did I already say that I love this app? :-) Thanks again, Christian
what happens if the file gets deleted or moved while the playlist is open? Most players test to see if the file exists right before playing, and skip it if it doesn't exist. Playlists can be a lot of work to create, and I view it as an error to change them without notification. a less bad solution: there could be a dialog: Some of Playlists files are missing? clean playlist? I would rather see a button to "clean playlists", rather than restore playlists... because one rarely knows what ve is restoring, and it might be a worse copy! perhaps there could be modes of playlists: 1. folder playlist.. shows empty with an error message: containing volume not mounted or empty. if the folder isn't mounted, changes dynamically, if one mounts the disk, it shows up again, because it queries the directory every time it's accessed. (some settings to control accessing frequency would probably be in order) saved playlist... this will show up as long as the drive that holds the playlist is mounted.. it will be empty.. WITH A MESSAGE that says, containing volume not mounted if it is there, the files that are not mounted are grayed out in the playlist and do not get loaded in to the applications "real" playlist, so they are skipped.. if the user clicks on it, it will attempt to be loaded. there could be a button: clean playlist and recheck status of playlist ( formerly offline files) basically, greying out and not playing the non available files would be cool, and would have a single button ability to get it to clear but this either requires a new internal playlist, or an extra hidden field in the playlist table (that manifists in graying out) AND, the ability to make sure that when no files are present, the random play doesn't go berserk, basically a second playlist... OR... my prefered method of random play, as is in noatun, is to remix the playlist, and actually show where they are going to be. Thanks for this product, I'm using it because it's the only one that seem to be working on my system right now... but Now I'll probably keep using it, even when others are working. (xmms-arts died, so noatun and juk are getting a lot of new users) *************** The logic has been to not add files that don't exist. There kind of needs to be some mechanism for cleaning out the playlists, so just not showing those items would seem a bit problematic. (Playlists could grow without ever having a way to remove items that don't exist.)
Can we re-open this as a wish? I was really excited when I first encountered Juk, because it occurred to me that I could re-use the play list as a CD catalog for music that are on CDs. It'd be really nice, for instance, to be able to search for a song that may be on some removable media. The only thing stopping juk from being used this way is the decision to have playlists automatically cleared. My proposal, then, is to add a little "x" to titles when the songs are in a playlist but the files for them aren't available. You could still search for a song by title (it may be asking too much for juk to cache metadata offline as well) and it would be obvious that the song isn't available. You might need another menu function to "clear" missing files from the playlist or, alternatively, have each playlist be flaggable as removable media. In any case, juk's playlist is *almost* a music catalog, and it is a shame to have to have two applications when Juk alone could do the job.
Well, these are really separate issues -- but I'm planning on adding support for "removable volumes" in the next JuK version. Rather than an "x" they'll most likely just use the grayed-out (disabled) color for the items that aren't currently available.