GNOME Bugzilla – Bug 325968
Banshee freezes when switching back to Music Library
Last modified: 2006-12-08 00:54:03 UTC
Please describe the problem: Displaying a Playlist, sorting this list and then switching back to the Music Library makes Banshee freeze Steps to reproduce: 1. Create a Playlist and drop some songs 2. Select Playlist 3. Sort Playlist 4. Switch back to Music Library Actual results: Banshee keeps playing but the interface freezes Expected results: The Music Library is displayed Does this happen every time? Yes Other information:
This does not happen for me, switching back to the music library works fine, and is sorted the same way that the playlist was. Here's what I did: Created an empty playlist Dragged a selection of songs onto that playlist (from the library) Selected the playlist Sorted by artist selected the library
Still freezes. Banshee tries to acquire all CPU it can get, but as no Library is shown after some minutes I guess this is not just "slow" but "broken". Is there any chance to debug what Banshee is doing with my CPU?
How many songs in the library? How fast is your CPU? You can trace Banshee like this, but please don't paste it here unless you narrow down the exact code path and can cut it down (the trace output may be many MB in size): mono --trace /usr/lib/banshee/banshee.exe
Closing due to no response on the NEEDINFO. Much has changed in the sources area of Banshee since this report. Please reopen if necessary.
The problem still exists. However I can't "--trace" Banshee, I had to stop it after having created a >10gb trace file (and still "Loading..."). Is there another way to track down this problem?
Mind answering my questions above? You can filter down the trace by namespaces: Probably concerned with Banshee, Banshee.Base, Banshee.Gui
Sorry. My Library holds about 13000 songs, my CPU is a P4/2.8GHz. Thanks for the namespace hint, I can create a trace now (200mb after startup). After switching to a playlist, sorting it by a different column and switching back to the library, the GUI does not react anymore and the trace file grows constantly. The latest few hundered mb's look like this (with different 0x* addresses): . . . . . . . . . ENTER: Banshee.PlaylistView:PlayCountTreeIterCompareFunc (Gtk.TreeModel,Gtk.TreeIter,Gtk.TreeIter)(this:0x59e10[Banshee.PlaylistView banshee.exe], [Banshee.PlaylistModel:0x1a2f60], [61,98,c7,45,a0,6d,f9,08,88,6c,f9,08,4c,ca,85,bf,], [61,98,c7,45,88,6c,f9,08,10,ce,73,08,3c,ca,85,bf,], ) . . . . . . . . . . ENTER: Banshee.PlaylistModel:IterTrackInfo (Gtk.TreeIter)(this:0x1a2f60[Banshee.PlaylistModel banshee.exe], [61,98,c7,45,a0,6d,f9,08,88,6c,f9,08,4c,ca,85,bf,], ) . . . . . . . . . . LEAVE: Banshee.PlaylistModel:IterTrackInfo (Gtk.TreeIter)[Banshee.Base.LibraryTrackInfo:0xf287e8] . . . . . . . . . . ENTER: Banshee.Base.TrackInfo:get_PlayCount ()(this:0xf287e8[Banshee.Base.LibraryTrackInfo banshee.exe], ) . . . . . . . . . . LEAVE: Banshee.Base.TrackInfo:get_PlayCount ()result=1 . . . . . . . . . . ENTER: Banshee.PlaylistModel:IterTrackInfo (Gtk.TreeIter)(this:0x1a2f60[Banshee.PlaylistModel banshee.exe], [61,98,c7,45,88,6c,f9,08,10,ce,73,08,3c,ca,85,bf,], ) . . . . . . . . . . LEAVE: Banshee.PlaylistModel:IterTrackInfo (Gtk.TreeIter)[Banshee.Base.LibraryTrackInfo:0xe6eb80] . . . . . . . . . . ENTER: Banshee.Base.TrackInfo:get_PlayCount ()(this:0xe6eb80[Banshee.Base.LibraryTrackInfo banshee.exe], ) . . . . . . . . . . LEAVE: Banshee.Base.TrackInfo:get_PlayCount ()result=0 . . . . . . . . . . ENTER: Banshee.PlaylistView:LongFieldCompare (long,long)(this:0x59e10[Banshee.PlaylistView banshee.exe], 0x0000000000000001, 0x0000000000000000, ) . . . . . . . . . . LEAVE: Banshee.PlaylistView:LongFieldCompare (long,long)result=1 . . . . . . . . . LEAVE: Banshee.PlaylistView:PlayCountTreeIterCompareFunc (Gtk.TreeModel,Gtk.TreeIter,Gtk.TreeIter)result=1 I killed the process after some minutes (sorting in the library normally takes about 2-4 seconds so I don't expect it to take more than 2 minutes after switching views). Is there anything more I can help with? If you want I'll send you the 1gb logfile (gzipped to ~20mb) or provide you a vnc session.
Nico, Is the interface get frozen for the rest of the session or just a period of time? I mean, If banshee is playing songs and I create an empty playing list, selected it and the delete it; the interface looks frozen. But if I wait more or less 40 seconds interface is drawn again. I noticed that the time with the interface frozen is almost the same time when banshee loads the first time (loading the play list). My play list only have 1697 songs. Probably with more songs it is slower. Hmm... it also happen if I do not delete the play list. It is the time the treeview gets painted. May you try it with a reduced amount of songs?
I find the banshee playlist switching to be incredibly slow as compared to the likes of Rhythmbox and Muine. I currently have approximately 2400 songs in my music library and it takes 5-7 seconds just to switch from a small playlist of about 30 songs to the full library. Rhythmbox and Muine load their lists almost instantly. I just installed a new dual core processor and the load speed has gone down dramatically but it is still lagging behind other library based music players. Please help.
Bug 336664 appears to be a duplicate of this bug.
*** Bug 336664 has been marked as a duplicate of this bug. ***
Merging info from duplicate: Opened by Max Powers 2006-03-30 20:14 UTC > Please describe the problem: > Having a large music database (4500+ songs) causes Banshee to constantly > freeze and spike to 100% CPU usage when moving in between Music Library and > either playlists or devices (such as an iPod). > > Steps to reproduce: > 1. Drag a song from Music Library (main database) and create a new playlist > (OR) > enter a song in the search field. > 2. Go back to the Music Library > 3. Banshee now freezes and CPU spikes too 100% for a few minutes. Banshee then> finally loads the Music Library > > > Actual results: > Banshee freezes > > Expected results: > Banshee should not freeze. > > Does this happen every time? > Yes > > Other information: > Perhaps a better (or robust) way of caching files is needed for people with > quite large music libraries? Banshee is really crippled due to this type of > behaviour. Comment #1 from Paul Cutler 2006-04-06 01:14 UTC > I can't confirm this using Banshee 0.10.9 on Ubuntu Dapper Drake with 24,000 > songs in my database. > > I tried to reproduce by dragging a song from the music library to an existing > playlist, and a second time by dragging to a new playlist. > > What are your PC specs, including CPU speed and memory? Comment #2 from Paul Cutler 2006-04-06 01:39 UTC > This also appears to be a duplicate of Bug 325968 Comment #3 from Max Powers 2006-04-06 03:43 UTC > Paul, my specs are AMD64 3000+ and 1GB of RAM.
Isn't this affected by Oscar Forero's normalisation work?
Moving to the User Interface component.
I have a similar problem, running latest CVS on ubuntu edgy with 9000 tracks in the collection. This is on a fairly fast computer. I tried to make a trace, to check that it is the same problem, but after a while, banshee had still not displayed the list of songs and the output file filled more than 1.8G, against 200M after startup for the reporter (the UI had been here for about one minute, and a normal startup usually takes less than 5s!). I am thus not sure it is the same problem, any hint to help tracking it down ? I can provide parts of the trace file if required. On a related note, the wiki quotes an incoming rework of the list model, is this only planned or has the developpement started ? I would happily test if it solves my problem!
I just committed a fix for bug #357743 that will at least help with this problem. If you are running Banshee from CVS (or 0.11.1 when that comes out) please report how much if any better things are running. There are still issues with Banshee's datamodel, but at least we're not reloading it three times on each switch now! More details here: http://gburt.blogspot.com/2006/09/wild-banshee.html
I have noticed that Banshee is terribly slow in switching between playlists and the library if I have Assistive Technologies turned on.
*** Bug 360824 has been marked as a duplicate of this bug. ***
*** Bug 363206 has been marked as a duplicate of this bug. ***
(In reply to comment #16) > I just committed a fix for bug #357743 that will at least help with this > problem. If you are running Banshee from CVS (or 0.11.1 when that comes out) > please report how much if any better things are running. Just upgraded to 0.11.1. It's still a bit slow, but it's a matter of a minute compared with around 5 before. Significant improvement; nice work! :)
*** Bug 358133 has been marked as a duplicate of this bug. ***
Created attachment 77202 [details] [review] Patch to greatly speed up switching speed The problem is that each time you switch between sources, Banshee clears the TreeView's model and fills it with the new source's tracks. If you are sorting by a column, then as it fills in each track from the new source, it sorts the entire model. This patch fixes this by temporarily setting the sort function back to the default while reloading a source, then restoring the ordering after so the sorting is only done once, at the end. It also adds handles the case where you send a collection of tracks in the TrackAdded and TrackRemoved events, and if there are enough tracks in such an event, it does the same sorting protection to make the changes fast. This is used in Smart Playlists to refresh its contents, for instance. This patch works very well for me, with the large exception of a spurious fatal error (see below). If people can please test and confirm and if possible, debug, that would be much appreciated so we can get this in ASAP. Gtk-ERROR **: file gtksequence.c: line 597 (_gtk_sequence_node_rotate): assertion failed: (node->parent != node) aborting... ================================================================= Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= Stacktrace: at (wrapper managed-to-native) Gtk.ListStore.gtk_tree_sortable_set_sort_column_id (intptr,int,int) <0x00004> at (wrapper managed-to-native) Gtk.ListStore.gtk_tree_sortable_set_sort_column_id (intptr,int,int) <0xffffffff> at Gtk.ListStore.SetSortColumnId (int,Gtk.SortType) <0x00020> at Banshee.PlaylistModel.RestoreSortOrder () [0x00000] in /home/gabe/Code/banshee/src/PlaylistModel.cs:143 at Banshee.PlayerUI.OnSourceTrackAdded (object,Banshee.Sources.TrackEventArgs) [0x000dd] in /home/gabe/Code/banshee/src/PlayerInterface.cs:1055
I reverted my patch on my local copy and reran Banshee, and got the same crasher as above...so it seems its not introduced by my changes. Can anybody else reproduce it?
Fixed in CVS. New release coming out soon.
*** Bug 383551 has been marked as a duplicate of this bug. ***