Page 1 of 4

Statistics for plugin usage

PostPosted: Mon Feb 13, 2012 6:25 am
by mad_ady
I know this topic has been discussed before (but for the life of me I can't find the old thread).

I wanted to raise the question again - how can we add reliable plugin usage stats for the devs, so that they can know where to invest more effort?

Recently I saw that noname has added statistics support in his plugins (downloading a 1x1 gif), but the stats are only available to him.

The idea looks good and reliable, and we can add it to all plugins - question is - where should the logging go to so that the stats are open to everyone (top plugins)?

Can we add such a feature on the (or server and build weekly/monthly stats automatically based on hits?

noname's solution:
Code: Select all
// Stats

How about a simple cgi script which gets passed the plugin id and coupled with the query's ip makes a hash and increments a counter in the database?
I can start to build something if it can be hosted in the public part of the site/wiki.

Maybe we should couple this with the CENSUS option to give users an opt-out option...

Edit: Added poll for the CENSUS option.
Edit: Removed poll results. 70% want stats with no regard to privacy, 30% want privacy first. There were 10 voters.
Edit: Added new poll - should we use the CENSUS option and ask the users to opt-in, or should we use a new UMSP_CENSUS option and allow users to opt-out?

Re: Statistics for plugin usage

PostPosted: Mon Feb 13, 2012 10:30 pm
by mad_ady
I had a better idea. Instead of using HTTP (which uses TCP and the three-way handshake) let's use UDP instead. A simple UDP server listening on an arbitrary port and all the plugins would use netcat to send the plugin id to the server.
The communication is lightweight, best effort and one-way. Also reduces network overhead by a lot and doesn't introduce additional points of failure (should the statistics server be down).

Hopefully I will start having more free time in a week or so and I will begin writing it (for the fun of it) :)

Re: Statistics for plugin usage

PostPosted: Sun Feb 19, 2012 12:30 pm
by metoo
Hi, mad_ady, I agree with you. It would be very nice having statistics of plugin usage. I read the other post about this, when RMerlin said:

We (the WDLXTV devs) already have stats for app.bins download. The reason I didn't implement it for UMSP is because those plugins gets re-downloaded every time a WDTV is rebooted, therefore it makes those stats useless.

Its true, but the idea is making the statistics of the usage, not the downloads. So we can use www histats com for this purpose. For those who want to try, the service is free. You make an account, add an url (ficticious or not), then add a counter, and finally put this code in the main menu of the plugin:

Code: Select all

This way, you will count each time someone enters the plugin. Then you have the choice to make stats public or private. You can have a look to my stats (guess which is the most used ;) ):


Anyway, it would be better if we had our own service, where we could compare all plugins, top ratings, etc. And for the privacity, we could use the hash of the users IP.

Re: Statistics for plugin usage

PostPosted: Sun Feb 19, 2012 11:36 pm
by mad_ady
I hope to free my schedule in a month or so and start working on a standard way to share these stats (unless we all vote on the histats approach). At least the histats approach would save some bandwidth on the wdlxtv servers...

Re: Statistics for plugin usage

PostPosted: Tue Apr 17, 2012 12:08 pm
by mad_ady
I've recently done some changes to the UMSP base code, and though about the plugin stats some more.
It would be possible and relatively easily implemented for UMSP to trigger an action when the user enters a plugin's main menu.

My idea is for UMSP to send a UDP packet (by using netcat or a UDP socket) to a known server (how about and inside the packet to put the plugin id and an md5 hash of the WDTV_SN config variable. The action would be done only if CENSUS='ON', to respect the user's privacy.

On the server would run a UDP server that would add the data to an internal database (sqlite/mysql). A public web interface would show usage stats per month.

I need to check with the server maintainer if this would be acceptable for him, and then to make the code.

The advantage would be this would get created only once (inside UMSP) and any plugin (official or not) would benefit.

What do you think?

Re: Statistics for plugin usage

PostPosted: Tue Apr 17, 2012 2:13 pm
by KAD
I like the trigger idea,

this would give acurate usage results


Re: Statistics for plugin usage

PostPosted: Tue Apr 17, 2012 3:46 pm
by Gui
i thanks it's a Great idea.

Re: Statistics for plugin usage

PostPosted: Tue Apr 24, 2012 7:34 am
by mad_ady
I'm wondering what we should do about the CENSUS option when collecting the stats data.

I've talked with the server admin and traffic would not be an issue - so we could process data regardless of the CENSUS option. The question is - should we honor CENSUS and only send usage data if CENSUS=ON (and thus have less accuracy)?, or should we send data independent of CENSUS and get the whole picture?

The data we would get does not reveal personal details, just the pugin name and a md5 hash of the WDTV_SN (to remove duplicate counting).

I started a poll on this thread and I'd like to hear your opinion on this.

Re: Statistics for plugin usage

PostPosted: Tue Apr 24, 2012 7:46 am
by KAD
ok, I'm on the fence, but I voted to collect the data regardless

on 1 hand you have the privacy issue


last I heard it was a small percentage of users that actually have census enabled, maybe 20%
with such a small percentage, I feel it would make the data far too inaccurate to be worth while


Re: Statistics for plugin usage

PostPosted: Tue Apr 24, 2012 9:37 am
by recliq
I'm sorry but I have to vote for privacy by all means!

Privacy is a big problem these days and we're losing more and more every day. I don't want to be part of this in any way and certainly not for some stas ;)
May sound harsh but you asked for my opinion, didn't you? :mrgreen:

Opt-In is the only way to go I think.