Thanks. I also saw that awstats has a SkipFiles configuration option that seems to do the same thing. http://www.awstats.org/docs/awstats_config.html
I have been looking at the data from this page and trying to strip out just the firmware. I noticed:
1 - There are a lot of download entries for /snapshots/faillogs. I am not sure why any one would download these files. I do not think these are relevant for download statistics.
2 - There are files called kernel-debug. I do not know what they are or if we need to track them.
3 - I do not see any downloads of image (ImageBuilder) Hopefully this is wrong. Not sure how to check.
The column that says "206 hits" are incomplete downloads.
Operating systems are also tallied, however there is a very large number (60.5%) under Others=>Unknown which makes the data much less valuable in my mind. Apparently Windows XP lives on as does the Commodore 64.
I am not seeing a way to view anything but the current month's history. I would expect we can navigate to history and YTD.
Anyone (myself included) looking for build failures on the buildbots and trying to fix things which worked on a limited test or platform and is failing in normal builds. The downloads are the console output from the package build - compile.txt. However, they could be excluded if they are too distracting.
I looked at the faillog folders and see how cumbersome it is to navigate through to see the fail logs, but these are statistics of how many of the failogs have been downloaded, not the fail logs themselves. If the log is not downloaded there is no entry. I guess if someone downloads the entire folder there would be an entry for each fail.
I think better would be to have 3 reports, one for each of the folders under snapshots, but there still would be packages under targets..
This is a windows product that I use every once and a while to run through my music folders to build a catalog.
https://directory-list-print-pro.en.softonic.com/ I do have to do a few things with excel to get it how I like it, but if you have access to folders you can get it to give a list of all the fails so you don't need to hunt. Not sure you can generate a link to the file.
I think that
-
targets and packages reports could maybe be combined. They are similar "end-user" stuff. People who download the firmware and possible add-on packages.
-
faillogs are for developers who try to evaluate how the latest changes work or what has broken things. Those directories are more about monitoring for any new item popping up there (and then looking at the new failed compile log) than about downloading the same reports regularly. (There are perma-broken packages, so much of the faillogs list remains constant over time.) Faillogs has a quite different user profile than targets & packages, and the download volumes will always be much smaller. I don't think that statistics about that will have much value.
EDIT: I need to add something here to make the bullets visible in the final message. Otherwise they are visible in preview, but not in final. Bullets can't be the last item in a message?
I think a bullet list must be preceded by a blank line. Tests:
No blank line, no bullets
- sdfasdf
- asdfasdf
Blank line - has bullets
- sdfasdf
- asdfasdf
UPDATE:You're right. I did have to add this final line to make the bullets appear in the real message.
UPDATE:You're right. I did have to add this final line to make the bullets appear in the real message
Strange limitation. I wonder if that is from Discourse itself, or from our stylesheet/config/whatever
Sounds like a bug to me, maybe we should raise it upstream
Testing, 1, 2, 3...
Blank line before bullets
- Bullet Line 1
- Bullet Line 2 - no CRLF on this line
Update: The considered wisdom over there (from Jeff Atwood, no less) is that we have a "CSS problem". From this I draw a few conclusions:
- I don't have time/skill to look into this now
- This isn't crippling, so let's put this in a list of low-priority curiosities...
- ... unless someone has the urge to tackle it now
Thanks.
The list formatting issue should be solved, it was indeed caused by one of my local CSS modifications.
- List test
@jow Can we have awstats also show screensize / windowsize? I would be interested in this information to see how our readers see the wiki.
how to: http://www.awstats.org/docs/awstats_faq.html#SCREENSIZE
@tmomas - sadly no, awstat purely analyzes server side access log files, there is no client capability info available there.
I know that awstats relies on server logs - what is not in there can not be shown, and usually screensize is not included in those logs.
That's why I linked to http://www.awstats.org/docs/awstats_faq.html#SCREENSIZE. This page describes what needs to be done to enable awstats to show stats about screensize.
In short:
- place small js on homepage
- place js inside a js directory stored in your web root
- check if js does it's job by checking webserver logfiles: they should include now screensize (for sample output, see above link)
- In the awstats configuration, change parameter "ShowMiscStats" to "ShowMiscStats=anjdfrqwp"
Sounds simple enough to try it out. What do you think?
Ah, now I got you. Sure, I can give it a spin.
Any idea, how quickly the new stats should get visible?
At least so far there has been no indication about screen size stats at https://wiki.lede-project.org/stats/
I forgot to enable the actual rendering of the reports in the awstats config, I think I got it all now.
You got it 
1366x768 21.3 %
1920x1080 19.6 %
1600x900 7.4 %
1920x1200 6.3 %
1440x900 5 %
Others 40.1 %