Seems like I had a corrupted database. Moving it out of the way fixes it. I still have the broken database, but I'm not really sure if I want to debug it. Atleast not at this moment.

<a href="https://launchpad.net/distros/ubuntu/+source/banshee/+bug/72969">
       Bug #72969</a> Duplicated!

Duplicated https://launchpad.net/distros/ubuntu/+source/banshee/+bug/72969

I am going to close this one, as I can no longer reproduce it. I assume that it was a one-time error.

The error /exist/. I'm happend for this.

can you attach a photos.db that crashes?

No, because the .banshee directory don't exist. For a reason, this be deleted. To another people too happend the same thing. :(

I'm going to close this bug then. If you (or someone else) manage to find a corrupt banshee.db (not photos.db, that's f-spot, ooops :-)), please reopen this bug, I'll have a look at it then.

Created attachment 79152 [details]
Corrupt Banshee Database

Here is a copy of the corrupt database file.

I compile Banshee from the SVN and i have the same problem. Exactly the same. :/ I think this is a critical bug. :(

*** Bug 397861 has been marked as a duplicate of this bug. ***

Created attachment 80591 [details]
bad banshee db

Assigning, raising priority, going to have a good look at this, cause I want to it fixed. Before 0.12 if possible...

Ok, here's what I found is wrong:

There are entries in the PlaylistEntries table with an invalid TrackID. This might've been caused by deleting a track without deleting the entries in the PlaylistEntries table.

Two steps needed in fixing this:
 1) Make sure this never ever happens again. For real, we don't want a corrupt database, so all code paths involving deleting a track should be checked to be correct. Will do that first.
 2) Since the corruption isn't anything that fatal, we can safely detect this at runtime and drop the invalid data. This way users with a broken database will be able to use banshee, without deleting their database (the bug was just automagically fixed after upgrading banshee).

Starting with step 1...

Aaron: There's a lot of duplicated code because of the definition of LibraryTrackRemovedArgs. Currently it's defined like this:

public class LibraryTrackRemovedArgs : EventArgs {
    public LibraryTrackInfo Track;
    public ICollection Tracks;
}

Which means we have to handle the case for both Track and Tracks in every implementation that uses this class, else things might go wrong. Is there a special reason why this is like this? Also, I'd like to propose a patch that removes all this duplication, basically removing all the double code. The only difference that might cause would be the case with only one LibraryTrackInfo, but iterating over a collection with only one element isn't that much slower (if we're firing of _a lot_ of these events, we want to group them in one event anyway). It does however make it a lot harder for us to screw up things, as we don't have to handle both cases exactly the same way every time we use LibraryTrackRemovedArgs.

Created attachment 82300 [details] [review]
banshee-cleanup-librarytrackremovedargs.patch

Here's the proposed cleanup:

Clean up LibraryTrackRemovedArgs.

This patch changes the definition of LibraryTrackRemovedArgs from
    { LibraryTrackInfo Track, ICollection Tracks }
to
    { ICollection<LibraryTrackInfo> Tracks }

This causes a couple of things:

The first goal was to simplify all methods handling LibraryTrackRemovedArgs.
Now they only have to handle the single Tracks attribute. This removes a lot of
duplicated code. Each method handling the TrackRemoved signal basically had to
implement itself twice, this has now been reduced to once.

While working on this, I changed Tracks to be a generic class of
LibraryTrackInfo objects. This improves type safety, with the current code, it
was possible to have both LibraryTrackInfo objects and SafeUri objects in the
Tracks attribute. Luckily, the possibility to use SafeUris isn't used anywhere,
as no code implements functionality to handle this.

 Core/Banshee.Base/Banshee.SmartPlaylist/SmartPlaylistSource.cs |   10 -
 Core/Banshee.Base/Library.cs                                   |   42 +----
 Core/Banshee.Base/Sources/LibrarySource.cs                     |    4 
 Core/Banshee.Base/Sources/PlaylistSource.cs                    |   16 --
 Plugins/Banshee.Plugins.Podcast/PodcastLibrary.cs              |   78 ++--------
 5 files changed, 39 insertions(+), 111 deletions(-)

I just encountered this error, and figured out myself that it was a problem with the playlists (i couldn't get this bug to display for some reason..)

I had imported a collection of around 2000 songs.. then i had created a playlist with a few hundred songs, then i re-imported the original 2000 songs (because i was afraid there were some new ones). Banshee displayed most of these songs in the Error log showing that they were duplicate songs. I then right clicked on the error log and clicked Close (or hide, whatever it shows). This caused banshee to hang.. so after a while i killed it, and when i tried to restart, i had the broken database file (that is, the db was NOT corrupt, it just had bad data in the playlist table).

Hope that might help..

Setting patch status to committed as it is in my branch (which should go to trunk soon).

Quasar: I will try that soon, hopefully I can reproduce it too, thanks for the hint, it would be an awesome step forward if that is what causes it.

*** Bug 403365 has been marked as a duplicate of this bug. ***

Ruben, has your branch been merged in so we can close this now?

Duplicate bug #494036 indicates that this didn't make it into 0.13.1. Can the target be updated and that bug marked as a duplicate?

*** Bug 494036 has been marked as a duplicate of this bug. ***

*** Bug 419717 has been marked as a duplicate of this bug. ***

*** Bug 426361 has been marked as a duplicate of this bug. ***

*** Bug 477235 has been marked as a duplicate of this bug. ***

(In reply to comment #20)
> Ruben, has your branch been merged in so we can close this now?

And if not, can we get it merged ASAP?

It won't get merged, as we have totally rewritten that part in trunk. Note that the patch doesn't fix the issue yet, it just prevents the corruption from occurring again.

It might be the case that this has already been fixed in a different way (and won't occur again).

Setting bug version to 0.13.x, as it has nothing to do with trunk (and shouldn't happen there).