GNOME Bugzilla – Bug 440172
Unable to load Podcast DB
Last modified: 2008-01-01 02:10:11 UTC
Please describe the problem: Once I started Banshee did not start. I then restarted it from terminal and got the output below. Steps to reproduce: Actual results: May podcasts are lost. Expected results: They should be there. Does this happen every time? Other information: $ banshee Debug: [05/21/2007 14:48:37] (Loading audio profiles) - /usr/share/banshee/audio-profiles Debug: [05/21/2007 14:48:38] (Default player engine) - GStreamer 0.10 Debug: [05/21/2007 14:48:39] (Audio CD Core Initialized) - Debug: [05/21/2007 14:48:39] (Audioscrobbler starting protocol engine) - Unable to load Podcast DB System.FormatException: String was not recognized as a valid DateTime. at System.DateTime.Parse (System.String s, IFormatProvider fp, DateTimeStyles styles) [0x00000] at System.DateTime.Parse (System.String s, IFormatProvider fp) [0x00000] at System.DateTime.Parse (System.String s) [0x00000] at Mono.Data.SqliteClient.SqliteDataReader.ReadpVm (IntPtr pVm, Int32 version, Mono.Data.SqliteClient.SqliteCommand cmd) [0x00000] at Mono.Data.SqliteClient.SqliteDataReader..ctor (Mono.Data.SqliteClient.SqliteCommand cmd, IntPtr pVm, Int32 version) [0x00000] at (wrapper remoting-invoke-with-check) Mono.Data.SqliteClient.SqliteDataReader:.ctor (Mono.Data.SqliteClient.SqliteCommand,intptr,int) at Mono.Data.SqliteClient.SqliteCommand.ExecuteReader (CommandBehavior behavior, Boolean want_results, System.Int32& rows_affected) [0x00000] at Mono.Data.SqliteClient.SqliteCommand.ExecuteReader (CommandBehavior behavior) [0x00000] at Mono.Data.SqliteClient.SqliteCommand.ExecuteReader () [0x00000] at Banshee.Database.QueuedSqliteCommand.Execute () [0x00000] Setting IO Backend to Banshee.IO.Unix.IOConfig (unix)
*** Bug 440170 has been marked as a duplicate of this bug. ***
Mono version: mono=1.2.4-0.1-1
Could you post a copy of your db file? ~Mike
Which would be $HOME/.gnome2/banshee/banshee.db ?
Yes, unless you're using SVN, then it would be $HOME/.config/banshee/banshee.db.
I also have this fault. Banshee 0.12.1, mono 1.2.4. It started a few days ago when I booted no podcasts listed. Running with banshee --debug reports: Unable to load Podcast DB System.FormatException: String was not recognized as a valid DateTime. at System.DateTime.Parse (System.String s, IFormatProvider fp, DateTimeStyles styles) [0x00000] at System.DateTime.Parse (System.String s, IFormatProvider fp) [0x00000] at System.DateTime.Parse (System.String s) [0x00000] at Mono.Data.SqliteClient.SqliteDataReader.ReadpVm (IntPtr pVm, Int32 version, Mono.Data.SqliteClient.SqliteCommand cmd) [0x00000] at Mono.Data.SqliteClient.SqliteDataReader..ctor (Mono.Data.SqliteClient.SqliteCommand cmd, IntPtr pVm, Int32 version) [0x00000] at (wrapper remoting-invoke-with-check) Mono.Data.SqliteClient.SqliteDataReader:.ctor (Mono.Data.SqliteClient.SqliteCommand,intptr,int) at Mono.Data.SqliteClient.SqliteCommand.ExecuteReader (CommandBehavior behavior, Boolean want_results, System.Int32& rows_affected) [0x00000] at Mono.Data.SqliteClient.SqliteCommand.ExecuteReader (CommandBehavior behavior) [0x00000] at Mono.Data.SqliteClient.SqliteCommand.ExecuteReader () [0x00000] at Banshee.Database.QueuedSqliteCommand.Execute () [0x00034] in /home/jms/working/banshee-0.12.1+dfsg/src/Core/Banshee.Base/QueuedSqliteDatabase.cs:207
Created attachment 90714 [details] my banshee.db
Phew - thanks for the comments here it helped me find the problem. The publication date "PubDate" on the Podcasts table were all in UK format, e.g. 18/06/2007 except for one that was in US format, i.e. 06/18/2007. After switching the first two fields around with SQL (update Podcasts set PubDate = "18/06/2007 18:00:00" where PubDate = "06/18/2007 18:00:00") I can start banshee and see my podcasts.
It seems this issue can occur when working with different locales (with different time formats), updating or downloading podcasts can then break your database for another locale (this problem exists for at least sv-SE and C). Inspired by <http://www.codeproject.com/csharp/cultureinvariantdatetime.asp>, I've drummed up a patch that seems to fix it for me (but this is my first time doing anything in C# so I just might have managed to do something crazy although it's a minimal patch, please review before applying :)
Created attachment 93167 [details] [review] podcast datetime fix
That's about the same conclusion that I came to this weekend. SQLite will happily accept just about anything for a date/time field, only upon read will errors become evident. As pontus mentioned, the problem crops up when an invalid datetime is put into the db with one locale and then read with another. Using ISO-8601 formatted date-times [0], which are independent of the current culture and supported by both the DateTime structure and SQLite, should solve this issue. The fix is simple, patch attached. Pontus, where did you post your patch? Side note to a seemingly international corwd: Does anyone know of a good place to learn about general i18n? [0]: * http://msdn2.microsoft.com/en-us/library/az4se3k1.aspx - the 's' format * http://msdn2.microsoft.com/en-us/library/system.globalization.datetimeformatinfo.sortabledatetimepattern.aspx *http://www.somacon.com/p370.php
Created attachment 93188 [details] [review] Patch for src/Plugins/Banshee.Plugins.Podcast/PodcastDBManager.cs in banshee Weird, I'm quite sure I really did attach this to the bug (and even felt guilty about doing the comment before attaching the patch, causing two mails to those watching). Anyway, naturally, what I did was roughly the same although I thought one might as well go all the distance and store it in UTC (and mark it so). Not a big issue, but should be nice for those changing time zones when travelling.
Although when looking more closely the patch in comment 11 doesn't fix the case for LastUpdated for PodcastFeeds, which needs fixing as well.
And now I see that I managed to attach to 440738 first. Oh well.
Yeah, you're right about the patch, I must have diff'd before I saved.
*** Bug 462652 has been marked as a duplicate of this bug. ***
Is there any hope we might get this fixed for the next stable release - I'm getting somewhat fed up with having to force banshee to run using LANG=C to have podcast support. Adding Gabriel to CC, hopefully he'll be able to check in a magic quick fix for Banshee will be useful to non-us people while we wait for real life to spit Mike back out.
I'll fix this today
Fixed in stable rev. 2936.