Cable does not run when gsettings are invalid

[Auroral Xylon]

Latest branch of cable compiles successfully, but fails to run. This is the full error message:

[_LOG_LEVEL_INFO 17:41:16.140327] Application.vala:77: Cable version: 0.1
[_LOG_LEVEL_INFO 17:41:16.140468] Application.vala:79: Kernel version: 3.2.0-45-generic
[_LOG_LEVEL_DEBUG 17:41:16.142344] [Gtk] Connecting to session manager
[_LOG_LEVEL_DEBUG 17:41:16.168604] Settings.vala:158: Loading settings from schema 'org.pantheon.cable'
[_LOG_LEVEL_FATAL 17:41:16.169586] [GLib] g_variant_get_string: assertion `g_variant_is_of_type (value, G_VARIANT_TYPE_STRING) || g_variant_is_of_type (value, G_VARIANT_TYPE_OBJECT_PATH) || g_variant_is_of_type (value, G_VARIANT_TYPE_SIGNATURE)' failed
[_LOG_LEVEL_FATAL 17:41:16.169677] Cable will not function properly.
[_LOG_LEVEL_FATAL 17:41:16.169794] [GLib] g_variant_get_string: assertion `g_variant_is_of_type (value, G_VARIANT_TYPE_STRING) || g_variant_is_of_type (value, G_VARIANT_TYPE_OBJECT_PATH) || g_variant_is_of_type (value, G_VARIANT_TYPE_SIGNATURE)' failed
[_LOG_LEVEL_FATAL 17:41:16.169834] Cable will not function properly.

Any ideas?

[Julien Spautz (julien-spautz)]

I get the same terminal output, but cable runs nevertheless.

[Julien Spautz (julien-spautz)]

What revision are you using?

[Julien Spautz (julien-spautz)]

Resetting dconf key fixed this issue.

[982c80311320c1b (alexander-wilms)]

The dconf values seem to become corrupted during using Cable

[982c80311320c1b (alexander-wilms)]

You could try to detect invalid settings and reset them

[982c80311320c1b (alexander-wilms)]

An example how the dconf values look when Cable refuses to start:

channels: ['irc.freenode.net:alexanderW3:#elementary-de', 'irc.freenode.net:alexanderW:#elementary']

favorites: []
indentities: ['alexander:Alexander Wilms:Bye.', 'alexanderW3:alexanderW3:Auf Wiedersehen.', 'alexanderW:alexanderW:Auf Wiedersehen.']
networks: ['irc.freenode.net:Freenode:', 'irc.gimp.org:GimpNet:', 'irc.fu-berlin.de:IRCnet:', 'irc.quakenet.org:QuakeNet:', 'irc.efnet.nl:EFnet:', 'undernet.org:Undernet:', 'irc.rizon.net:Rizon:', 'c.ustream.tv:Ustream:']

Maybe the overlapping identitities are the cause