On an offchance (thinking of 525178), can you try disabling the Podcasting extension to see if it helps?

If not, any reproducible steps? Can you provide some more details about which tracks you're playing?

I don't think it's related to bug 525178. It looks like you have a bad value for the "last_cover_art_scan" configuration key in your database.

Could you please paste the result of the following command :

sqlite3 ~/.config/banshee-1/banshee.db "select * from CoreConfiguration;"

As you wish:
1|DatabaseVersion|11
2|MetadataVersion|1
3|CoreTracks.ModelVersion|1
4|Database.Version|1
5|CoreArtists.ModelVersion|1
6|CoreAlbums.ModelVersion|1
7|HaveCreatedSmartPlaylists.MusicLibrarySource-Library|True
8|HaveCreatedSmartPlaylists.VideoLibrarySource-VideoLibrary|True
9|SmartPlaylistVersion|1
10|Podcast.Version|3
11|last_cover_art_scan|14/06/2008 13:37:51


Perhaps one important thing to nice is:
I'm running a cloned banshee on this machine. Which means I copy the .config/banshee-1 and Music content to this machine from another one (the primary one - where banshee is working quite normally). This has been working great in the past but perhaps banshee 1 got a little picky here?

I think I got it : aren't your two machines using different locale settings (date format, etc.) ?
Check the value of the LC_ALL environment variable.

I was able to reproduce the crash by changing its value on my machine. The value for the last_cover_art_scan key is a date stored as a string that is locale dependent. When we try to parse it in a different locale, we fail and crash.

As a workaround for you, you can delete the offending value by running :

sqlite3 ~/.config/banshee-1/banshee.db "delete from CoreConfiguration where key='last_cover_art_scan';"

The entry will be recreated the next time banshee is run.

To properly fix this, we should probably change the format used to store last_cover_art_scan.

Your totally right - that fixed it - thanks. Come by and grab a cookie :)

Created attachment 113063 [details] [review]
Reset the value of last_cover_art_scan if it is malformed

With this patch, banshee will reset the value of last_cover_art_scan to DateTime.MinValue if there's anything wrong with it.
It's a bit crude, but at worst it will trigger an unnecessary covert art fetch, instead of a crash.

That's more a workaround. I mean it's fine since for whatever reasons this can happen - but the basic problem is calling ToString() in DatabaseConfigurationClient's Set method.

I'd say for DateTime the stringify should be changed from .ToString() to .ToString("u")

Yeah, should be calling ToString with the System.Globalization.DateTimeFormatInfo.InvariantInfo

I must be missing something, or my generics knowledge is even worse than I thought, but I can't figure out how to do this in DatabaseConfigurationClient.Set <T>.

How am I supposed to cast a T into a DateTime ? "as" or regular cast don't work.

Well the sad thing is that constraints are not negateable - because then I'd say you could write:

<SetMethodDeclaration> where T !: DateTime
{
//use .ToString()
}

<SetMethodDeclaration> where T : DateTime
{
//use .ToString(System.Globalization.DateTimeFormatInfo.InvariantInfo);
}

and I have never tried whether overloading for specific types works:

<SetMethodDeclaration> where T : DateTime

<SetMethodDeclaration> //no constraint

But something tells me it doesn't.

So the thing you could do is
if(ref is DateTime)
  string = ref.ToString(System.Globalization.DateTimeFormatInfo.InvariantInfo);
else if(ref is float || ref is double)
  string = ref.ToString("0.0"); //a similar problem arises here
else
  string = ref.ToString();

But on the other end - the reading method also has to understand the formats!

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

So, the issue is that DatabaseConfigurationClient doesn't use the Hyena.Data.Sqlite utilities for converting values to/from database-stored values.  I'm trying to get my unit tests working again to make sure we don't mess anything up w/ this change.

OK, sorry, should have done this a while ago - I committed Bertrand's workaround since the proper fix hasn't gotten done and this is definitely not worth crashing b/c of.  No where else do we use the db config client for dates, so we're safe besides this.