Or simply something like awstats that parses webserver config for downloads.openwrt.org.
With that it would also be possible to count downloads of snapshot images.
I mean only parse the the requested files and no ip´s, user agents or something else...
@mbo20, Regarding their use, this is just "data". The way you choose to analyze data creates "information" which can then be used to make decisions.
@hnyman, The current content is not very useful data, indeed it is incomplete data (truncated file names) and not readily exported for analysis. There is very limited drill down (ie section only) and one should be able to go to a prior month (after the month is complete) to see it's complete picture. I can only see the incomplete current month (as best I can tell).
I submit these "stats" are pretty much useless for analytical purposes as they are presented.
This data should be broken into snapshots and release (with version or build), and within each, firmware and packages, (which I am not clear are in the stats) and maybe a few others like packages.gz and failogs seperatly. One should then be able to export this data, with a press of a button, to excel, by period, with each folder level in it's own column.
This is the minimum dissection to retrieve what I consider any useful "information", but I expect that the ability to analyze the full detail of each request will tell more, like why in April, Italy accounted for 80+% of the page requests and hits and 70+% of the consumed bandwidth. OUCH!
I have to admit that stats are not my field of expertise, but especially getting stats about the snapshot releases seems to me “difficult” to analyze. I don’t think people are updating their snapshot on a daily basis so to see “how popular” a specific snapshot was to give a “confidence level” for other users will probably give false information.
Using it for the most popular devices/targets might be good so developers can focus on those, but that also means we will be leaving behind the less popular (or after a cross check, maybe the more expensive devices).
How do you suggest to get good stats with the right interpretation (without spending days on getting that data)?
It could be helpful in the sense that if your downloading a snapshot and the download count is extremely low, you may choose to play it safe before flashing your device if your not experienced in un-bricking a device.
Obviously stats are just data, it is up to the user to make sense of it, or maybe others can explain if they ask.
Currently there isn't any data at all, that is obvious and easy to find by the casual user.
In my experience, before flashing my first device with LEDE 17.01.04 I asked many questions here, which now seem silly to me in hindsight. But at the time I asked the questions because I read a few posts on here about my device with a number of issues, which people had neglected to mark as solved. Secondly not realising at the time the device was reasonably popular and there was no need to be overly concerned.
With regards to snapshots, the stats could be both for the current snapshot and a running total for the past month for example.
Using snapshots one should always play it safe, but snapshots are “daily” builds. Let’s take this time of the year: FIFA 2018. A lot of people will use their free time to watch the games. That means they will not be downloading/installing etc a snapshot. That doesn’t mean there is anything wrong with the build or that “confidence” is low. It simply means people have different priorities in life. Same goes around special days or holidays. Some have extra time to “play” with their device/setup others are spending it outside with family or ...
The point is, all the stats would show a different picture compared to what you are trying to achieve: get a “score” on snapshot stability, which is only “current” that day (24-48?) hours. After that a new “snapshot” is available and how many users will flash on a daily basis??
Stats on the stable build might be interesting cause that could show the popular devices which usually means better support from the user base.
By all means try to get the statistics, I’m certainly no against the “project”. It’s more about how people interpret the resulting data.
Realistically I think it’s very complicated to get a
good “score system” implemented.
This type of project is aimed at people wanting to get more (the most) out of their hardware. Some want their “20 bucks” home grade device to do tricks that even some commercial grade devices need some expertise to setup properly. Have a look at the general type of questions asked. And don’t get me wrong: I’m not trying to be negative about the so-called “noobs”, but not everyone of those makes it past the initial learning curve. For those that don’t, they revert back to “stock” or maybe to something more intermediate like DD-WRT. Again, nothing negative about reverting back to stock: it’s usually easier to setup and then it just works. DDWRT is a bit in between (my opinion) in the sense that it comes preloaded with what those developers think is good to have (needed). That entire group will not give a “thumbs up” even if the build was running without any problem. Then there is the group that will be too lazy to come back and “rate” their setup.
It’s peoples nature to complain, so very likely the negative will get more “scores”. And people are likely to give a negative score because something doesn’t work as they thought it would (which in most cases is not understanding how to use/setup a package or ...)
Statistics about how many users in this forum, how many “active” and how many downloads from a stable build seem more interesting to me. It shows ovetall popularity of the project. But those should be most interesting to our developers: it shows that their hard work (blood, sweat tears) is making 10, 1000 or millions of people in this world happy running “their” software as a choice over the OEM/stock firmware.
And that number should give enough “confidence score” to the end user to give this firmware a try or to update their existing build to the latest (stable) version.
The level of confidence that an image is not going to brick the device.
Anything else the user can try out and test on and hopefully report on issues they find.
This would be useful if you want to test a device but don't have the resources or skill to un-brick a device. It would be helpful to know before hand.
Obviously advanced users can look at change logs and awstats when they start working again.
Currently all you can really do is ask on here first and mist probably get a response "nothing is certain and you may have to recover your device etc" which is all fair but discourages users from trying snapshots and reporting issues. Z
First it's important to understand that the stat "downloads" comunicates nothing more than someone has downloaded the firmware. It does not commnuicate the firmware was installed or how well it works. I see no systemic way to tie problem reports back into these statistics. For this you will need to read the bug and mail lists.
Stats for snapshots indicate little more than the product is being tested. For snapshots it's probaly relevant to include IP; this would better indicate how many unique users are actualy testing the firmware, which is proably important to the release process.
Stats for snapshot builds should be expected to be low. I would be surprised if most run into double digits for any individual build. Many will be "0" I suspect. You should infer nothing from a stat for snapshots other than some one downloaded it.
Release products can be inferred to "work", but the download total volume is little more than an indicator of device use\popularity, not quality. We do not have a rating system. With hundreds of builds, it's conceivable that some devices will make it into production and never be tested (Ok so some value to knowing what devices never had a snapshot downloaded) and you could brick it, though not likely. More likely just some hard to validate bugs.
I realize your new here, so it's worth clarifying some of the wiki.
If your device is a production device and is supported in release, use a release version.
If your device is a production device and not supported in release, use the snapshot with "respect" and download all the packages for your build. Kernel packages may not be available tomorrow. Luci is not in snapshot builds.
You should really only use snapshots for test and play in non-production environments, in which case stats are mute.
Ah...but that changes from “doing statistics” to, can we add to our hardware table a field indication how easy it is to recovery from a bad flash.
Like: recovery methods
No need to open device:
Uboot will provide webpage recovery on “reset”
Uboot will provide TFTP recovery “on reset”
Need to open device:
Need serial cable for first flash and recovery
Need JTAG cable
Need SPi flash tools.
Those could be “graded” with 5 to 1 Star, or what ever icon seems more suitable. Green - orange - red...
However for most devices this is already included in the Wiki for the specific model (series).
As for the snapshots...sometimes things get broken (in code). And feedback is needed to
fix the problem. (New) users should understand that risk. There are differences between a Stable and a Snapshot build. Especially if something is changes on a SoC (driver) level. It happened a few weeks ago. Not one device, but a whole series of models and devices had the same problem. The patch was re-evaluated and actually reverted until a better solution is found.
Most non-cable users usually don't have static IPs - and flashing a new firmware version is quite likely to result in them getting a new IP assigned (if they aren't getting a new one every 24h anyways). This is usually different for cable contracts (where you tend to keep your old IP unless you stay offline for an extended amount of time/ or change your WAN MAC address), but the IP address isn't a valid metric for "unique visits" in large parts of europe.
while I will not disagree that this info would be good to have, if you go back to the old TOH project threads you will unfortunately learn that users do not contribute to these pages in a volume that will make the data valuable, accurate and useful.
Even getting these stats reconfigured in a useful manner is unlikely to happen
Basically my point. The easy to flash units will not get the positive attention because nobody cares to update this info “cause it was easy”. The difficult to flash might get negative feedback which could be mistake for bad feedback about the firmware and not about the OEM making it more difficult to flash.
The same with hardware updates in the wiki. Only the “popular” devices get updates. But it says nothing about all other supported devices.
This is likely the reason why any previous attempts failed.