Version: 2.3.5 (using KDE 3.5.9) Compiler: precompiled in debian sid repository OS: Linux Installed from: Debian testing/unstable Packages After Juk finishes loading, in the Collection List, right click on a file and remove it from the Collection List (which removes it from all playlists). Then select another playlist the file is in. Juk crashes with the following backtrace. [Thread debugging using libthread_db enabled] [New Thread 0xb605e700 (LWP 3809)] [KCrash handler] #5 FileHandle (this=0xbfa782d8, f=@0x84e9430) at /tmp/buildd/kdemultimedia-3.5.9/./juk/filehandle.cpp:60 #6 0x080e8fef in PlaylistItem::file (this=0x9356780) at /tmp/buildd/kdemultimedia-3.5.9/./juk/playlistitem.cpp:83 #7 0x080d1f15 in Playlist::time (this=0x92cbf80) at /tmp/buildd/kdemultimedia-3.5.9/./juk/playlist.cpp:449 #8 0x080f9102 in StatusLabel::updateData (this=0x92eee98) at /tmp/buildd/kdemultimedia-3.5.9/./juk/statuslabel.cpp:123 #9 0x080e82be in Watched::dataChanged (this=0x85bce20) at /tmp/buildd/kdemultimedia-3.5.9/./juk/playlistinterface.cpp:37 #10 0x080d8c6d in PlaylistBox::slotPlaylistChanged (this=0x85bcd80) at /tmp/buildd/kdemultimedia-3.5.9/./juk/playlistbox.cpp:630 #11 0x080d8fff in PlaylistBox::contentsMouseReleaseEvent (this=0x85bcd80, e=0xbfa78464) at /tmp/buildd/kdemultimedia-3.5.9/./juk/playlistbox.cpp:536 #12 0xb707f271 in QScrollView::viewportMouseReleaseEvent (this=0x85bcd80, e=0xbfa789b4) at widgets/qscrollview.cpp:1753 #13 0xb707d090 in QScrollView::eventFilter (this=0x85bcd80, obj=0x85bd5d0, e=0xbfa789b4) at widgets/qscrollview.cpp:1504 #14 0xb704b666 in QListView::eventFilter (this=0x85bcd80, o=0x85bd5d0, e=0xbfa789b4) at widgets/qlistview.cpp:3870 #15 0xb6f6c78c in QObject::activate_filters (this=0x85bd5d0, e=0xbfa789b4) at kernel/qobject.cpp:906 #16 0xb6f6c7fb in QObject::event (this=0x85bd5d0, e=0xbfa789b4) at kernel/qobject.cpp:738 #17 0xb6fa543c in QWidget::event (this=0x85bd5d0, e=0xbfa789b4) at kernel/qwidget.cpp:4681 #18 0xb6f0f18a in QApplication::internalNotify (this=0xbfa78d88, receiver=0x85bd5d0, e=0xbfa789b4) at kernel/qapplication.cpp:2638 #19 0xb6f100ba in QApplication::notify (this=0xbfa78d88, receiver=0x85bd5d0, e=0xbfa789b4) at kernel/qapplication.cpp:2424 #20 0xb6c2bc22 in KApplication::notify (this=0xbfa78d88, receiver=0x85bd5d0, event=0xbfa789b4) at /tmp/buildd/kdelibs-3.5.9.dfsg.1/./kdecore/kapplication.cpp:550 #21 0xb6eaea52 in QETWidget::translateMouseEvent (this=0x85bd5d0, event=0xbfa78c98) at kernel/qapplication.h:526 #22 0xb6eadafd in QApplication::x11ProcessEvent (this=0xbfa78d88, event=0xbfa78c98) at kernel/qapplication_x11.cpp:3611 #23 0xb6ebdfe6 in QEventLoop::processEvents (this=0x84dbe90, flags=<value optimized out>) at kernel/qeventloop_x11.cpp:195 #24 0xb6f25b80 in QEventLoop::enterLoop (this=0x84dbe90) at kernel/qeventloop.cpp:201 #25 0xb6f25a16 in QEventLoop::exec (this=0x84dbe90) at kernel/qeventloop.cpp:148 #26 0xb6f0ecff in QApplication::exec (this=0xbfa78d88) at kernel/qapplication.cpp:2761 #27 0x080b7374 in main (argc=1474660693, argv=0xec835356) at /tmp/buildd/kdemultimedia-3.5.9/./juk/main.cpp:97 Thanks!
Version: 3.1.1 (using KDE 4.1.1) Compiler: gcc 4.2.4 OS: Gentoo GNU/Linux This bug happens to me as well. Lets get it marked as confirmed and find a solution. While I have not had time to hack around in the juk sources, I would imagine a media player could do a few things when a file is removed from the master collection: 1) Remove it from the master collection, but still let the playlist play the file. 2) Remove it from the master collection, then whenever a playlist is "loaded" it should see that the song it references is not there and remove the item. 3) Remove it from the master collection, and continue removing that file from each playlist (this may take time if the user has many playlists -- do we want a remove from collection operation to be instant?) Personally, I vote for number 2. Lastly, (not sure if this bug has been reported) but I can get juk to crash if I remove a file from my HD which is referenced in a playlist when I click on the playlist. It appears as if Juk doesn't know what to do when I file it once know existed can not be referenced.
I've been using JuK for about 6 months, and this crash started about 3 months ago. I've always removed songs from the Collection List and JuK used to successfully do what it says in the dialog box that pops up when I ask to remove the files: ---------------- Warning - JuK Removing an item from the collection will also remove it from all of your playlists Are you sure you want to continue? Note, however, that if the directory that these files are in is in your "scan on startup" list, they will be readded on startup. -----------------
This may be related to bug 142366 (similar backtrace)
*** Bug 142366 has been marked as a duplicate of this bug. ***
Created attachment 31357 [details] Fix crash in some cases because improper deleter used I think I've fixed a similar bug in KDE 4 trunk, due to not removing all deleted PlaylistItems from some cached lists. Can you try this patch out (I haven't compiled it against 3.5 yet as I no longer run 3.5)? If it works I'll forward it to whatever the KDE packagers list is so that it can be picked up by the distros. In retrospect the proper fix is to make the PlaylistItem dtor take care of all of this but seeing as how I've not even compiled this I don't want to get that invasive.
*** Bug 106872 has been marked as a duplicate of this bug. ***
*** Bug 106760 has been marked as a duplicate of this bug. ***
I'm assuming the listed patch works due to lack of response --> closing.
SVN commit 933498 by mpyne: Commit potential fix for improperly deleted PlaylistItems to 3.5 branch for user testing. CCBUG:171289 M +2 -2 collectionlist.cpp M +1 -1 playlist.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=933498
Change to collectionlist.cpp @@ -472,7 +472,7 @@ it != m_children.end(); ++it) { - delete *it; + clearItem(*it); } causes build error with GCC-4.3.3 collectionlist.cpp: In destructor 'virtual CollectionListItem::~CollectionListItem()': collectionlist.cpp:475: error: 'clearItem' was not declared in this scope I presume that this always was an error, but it only showed up when I upgraded the compiler.