Re: [Banshee-List] anonymous usage data



On Fri, Feb 12, 2010 at 11:33 AM, David Nielsen <gnomeuser gmail com> wrote:
>
>
> 2010/2/12 Gabriel Burt <gabriel burt gmail com>
>>
>> On Fri, Feb 12, 2010 at 10:54 AM, David Nielsen <gnomeuser gmail com>
>> wrote:
>> >
>> >
>> > 2010/2/12 Gabriel Burt <gabriel burt gmail com>
>> >>
>> >> On Fri, Feb 12, 2010 at 12:16 AM, Alexander Kojevnikov
>> >> <alexander kojevnikov com> wrote:
>> >> > On 12 February 2010 19:11, David Nielsen <gnomeuser gmail com> wrote:
>> >> >> If one was to run with --debug-sql could we also report frequent
>> >> >> long
>> >> >> sql
>> >> >> queries perhaps. I've noticed a lot of users complaining about
>> >> >> Banshee's
>> >> >> performance and while digging through logs I've noticed that it is
>> >> >> possible
>> >> >> to get queries lasting several seconds. It would be nice to see just
>> >> >> how
>> >> >> frequent this happens to users.
>> >> >
>> >> > I was sceptical about the whole idea until I saw this. I could
>> >> > definitely make use of this information.
>> >>
>> >> Yeah, it's a good one.  We can do it without requiring --debug, too.
>> >>
>> >> I have a rough first pass at this whole usage data/metrics work in
>> >> master now.  You can opt-in to it via Preferences.  It doesn't
>> >> actually send the data anywhere yet, but it will collect it.  So far I
>> >> have it collecting info on:
>> >>
>> >> * What assemblies are loaded/what versions
>> >> * Basic distro/os/.NET version info
>> >> * How long/frequently Banshee is run
>> >> * What source is active (and when it changes)
>> >> * What CultureInfo/locale we're in
>> >> * Track counts for libraries, podcasts, radio, etc
>> >> * Total play count / skip count
>> >> * How many tracks are rated
>> >> * Timestamp of when the app starts, exits (and duration)
>> >>
>> >> You can see an example Json dump of the collected data here:
>> >> http://banshee-project.org/~gburt/tmp/usage-data.txt
>> >>
>> >> Anybody should feel free to help out adding other interesting metrics!
>> >
>> > How about collecting data on which columns are enabled in which views
>> > and
>> > the order in which they are placed. To help us spot where the users
>> > frequently alter the Banshee defaults and thus indicating that we are
>> > doing
>> > it wrong(tm).
>>
>> Great idea, I'm adding it to my personal todo list.
>
> I forgot to add, we should probably also collect the browser setting (top
> vs. left), if we can justify it it might also be nice to know the screen
> data to that we can get an idea of which sizes we should optimize for. E.g.
> standard Banshee does extremely poorly on my netbook and the long awaited
> Cubano frontend hasn't yet arrived. I could also imagine that this could be
> used to figure out how many tracks we should load additionally to those
> displayed (my understanding is that we currently do something like displayed
> +/- 10 tracks).
> We could perhaps also gather some data on the database itself to see how
> many revisions it has gone through, I suspect this would reveal any
> potential problems where we are not migrating correctly from none linear
> versions upgrades or from things like the daily ppa snapshots. This could be
> useful for distribution upgrades to ensure that the shipped version is known
> to upgrade nicely when the distro issues major upgrades.
> Another nutty idea would be to collect the theme being used so that we might
> test that Banshee looks as it is expected to as part of the release process.
> Finally we could collect data on which devices are routinely connected to
> Banshee, their storage capacity, transfer protocol. This would let us see
> which devices are most important to hit during release testing and a sudden
> dip in these metrics would also indicate that something broke. Likewise we
> should collect some data on the errors we see transferring to such devices.

Great ideas, again.  I've just added support for capturing a whole
bunch of (whitelisted) config options:
http://git.gnome.org/browse/banshee/tree/src/Core/Banshee.Services/Banshee.Metrics/Configuration.cs#n64

Thanks for the ideas,

Gabriel


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]