Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: roseway on February 25, 2016, 10:58:59 AM
-
Some tidying up, and some additional data included in MDWS uploads
Changes since v5.6.2:
- fixed incorrect date display in daily traffic popup
- made some corrections to the terminology (e.g. 'router' --> 'modem')
- additional error correction and other changes which may solve the occasional
"Divide by zero" errors on the Windows version
- when the DSL uptime is not available, the AS uptime is used on the Stats page
- added extra information to MDWS uploads (stats B, M, T, etc.)
Changes between 5.6.1 and 5.6.2:
- the state of the error averages 24-hour/Modem-uptime option is now saved and restored
- corrected inability to save and restore the command prefix 'adslctl'
Changes between 5.6 and 5.6.1:
- in the Linux versions, the permissions of the mydslwebstats folder are set explicitly
- the interleave and ES/hour values on the status bar now have both up and down values
- if an upload to MDWS fails to complete, it should now time out gracefully
- corrected reversed upstream/downstream speeds with MDWS uploads using Thomson/Tecnicolor modems
http://www.s446074245.websitehome.co.uk/downloads.html
-
Many thanks for releasing this and all the work you do in maintaining the software.
Have now upgraded - the first time I have had to do so - and was pleasantly surprised that it remembered all my settings despite the unzipped folder being in a different location that the previous version.
-
Okay, thanks Eric. MDWS has now been updated to show the extra Stats discussed in the link below. I'll post detail on the MDWS thread later. They appear just left left of the Uptime stats in the Status panel at the top but only on the wide graphs. Hover over the XTR legend to see them. It will tell you that you need to upgrade if you haven't done so. HG612 Modem Stats users already have the data available. The panel will automatically show them no need to do anything if MDWS is already running.
They are being discussed in the thread below:
http://forum.kitz.co.uk/index.php/topic,17054.msg313878.html#msg313878 (http://forum.kitz.co.uk/index.php/topic,17054.msg313878.html#msg313878)
-
Just upgraded and it was a very smooth transition. Thanks for your continued help and support to all involved in developing this amazing peice of software.
-
Windows version running fine here Eric.
Only issue I had was that the old version had detected a new version and had used up nearly all my PCs memory, I had to force it off with the Task Manager and then memory use dropped like a stone and the PC recovered. Dont know if this was a one off but I will disable checking for now.
Stuart
-
Sorry to say the RPi has just had it's first invalid floating point operation in just 1 hour after installing V5.7.1
-
Thanks for the feedback, people.
@Stuart: the code in question hasn't been changed in about 18 months, so I think it's most likely that it was a one-off.
@NewtronStar: I'll set up my RPi shortly and leave it running to see if I can reproduce the problem.
-
Thanks for the feedback, people.
@Stuart: the code in question hasn't been changed in about 18 months, so I think it's most likely that it was a one-off.
@NewtronStar: I'll set up my RPi shortly and leave it running to see if I can reproduce the problem.
Just had a divide by zero on the MDWS server, first I've ever seen!
-
You really need to change the location where the updated zip file is stored when using the update link from the program
On my Win 7 machine it is in users/jim/AppData but by default that is a hidden area and I needed to change the folder view options to see it
-
You really need to change the location where the updated zip file is stored when using the update link from the program
On my Win 7 machine it is in users/jim/AppData but by default that is a hidden area and I needed to change the folder view options to see it
Jim at least on my copy (under Windows 7) the download directory for a new version is configurable by the user so you can store it anywhere you want.
Stuart
-
I hadn't spotted this option which is why I had the problem assuming that is the only place it is set
Perhaps the download location should be set to being with the other dslstats file by default and not where the config file is stored by default
Or was there something in the popup which I missed
-
Being a Linux user normally when I have the option under Windows I always choose to use the program directory and I suspect, although not checked, that it defaults to where you have the config files stored. In my case this would be the program directory. However you can make it anywhere you like....
Stuart
-
Just for information the RPi stopped uploading to MDWS for the second time again it was close to the 1 hour interval this time no invalid floating point operation just a blank GUI for DSLstats and it showed up after 20 seconds and started to upload to MDWS.
I'll keep V5.7.1 installed and see if it settles down
-
I jut got my first ever 'Invalid Floating Point Error' using the new version of DSLStats.
Not sure if its relevant/helpful, but this is on a WinXP machine and it appeared the first time I opened DSLStats (from the system tray) after XP came out of hibernation (which it accidentally fell in overnight). This never happened on v5.6.1 in the same circumstances.
-
All ok here, thanks. :)
Linux raspberrypi 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST 2015 armv7l GNU/Linux
-
Thanks again to all.
@oldjim: The location of the config files was changed some time ago in response to user requests. Because there wasn't universal agreement I included the option to choose one of two locations, both of which should be accessible to the user. I think I'm going to leave it that way.
@NewtronStar: I think your second experience may be a red herring. If an MDWS upload is delayed for any reason, such as a temporary network issue, the GUI freezes and doesn't redraw until the temporary blockage clears. I think it's most likely that this is what happened to you on that occasion.
@tbailey2: The occasional divide by zero error has been bugging me for a long time, as I've never been able to reproduce it and haven't been able to locate a cause. The best suggestion so far seems to be to set the error averages to the 24 hour setting, not the modem uptime setting, and this seems to have fixed (or at least alleviated) the issue.
-
Your decision except that as I posted the default isn't readily available to the user who is at Windows default settings as it is hidden
-
I have just had the Division by Zero and again immediately after a restart - didn't get that at all in the previous version.
Also the Errors/Averages panel is not quite tall enough - shows a scrollbar.
I've followed your suggestion and changed to 24 hour averages which it managed to save even in a corrupt state and restarted - seems OK for now.
-
@tbailey2: The occasional divide by zero error has been bugging me for a long time, as I've never been able to reproduce it and haven't been able to locate a cause. The best suggestion so far seems to be to set the error averages to the 24 hour setting, not the modem uptime setting, and this seems to have fixed (or at least alleviated) the issue.
I'm not monitoring them....
-
@tbailey2: The occasional divide by zero error has been bugging me for a long time, as I've never been able to reproduce it and haven't been able to locate a cause. The best suggestion so far seems to be to set the error averages to the 24 hour setting, not the modem uptime setting, and this seems to have fixed (or at least alleviated) the issue.
Perhaps a pain but could you wrap all divide operations in a function called nodivideerror and check for -/+ve near zero and change to 1 to stop error. Then expand with logging/exceptions to track down the line causing the issue?
-
Thanks for the suggestion, but I've already been through my own code line by line, and checked every instance of a division. In every case it's either not possible for there to be a zero divisor, or where there's doubt I've wrapped it in an error trap. So although something in my own code may be the cause of the problem, the error is actually happening in a library function. Chasing that by hand would take forever.
I do have some ideas for more investigation, but I'm rather hampered by a personal issue which is limiting my time at the PC. I'll do my best.
-
V5.7.1 looks like it has settled down on the RPi and still uploading to MDWS and I'm very grateful for your ongoing support into DSLstats. was starting to think the only version that would worked on the RPi was V5.6 and previous versions :dance:
and yep the RPi modem/router uptime averages was selected now changed it back to 24 hour averages.
-
Thanks for that, NS. :)
-
Upgraded too myself on my RPI - I'll let you know if there are any problems :)
-
Upgraded too myself on my RPI - I'll let you know if there are any problems :)
Just make sure you have selected 24 hour averages in the Errors/Averages !
-
Just had a look at the server and there's another divide by zero alert up. Could have been there all day as haven't checked today. Still uploading though, I'll leave it there for now. As I said, I don't have the error box checked, only SNR and Connection speed in that section.
-
My DSLstats fell over at 11pm last night with a Divide By Zero error. I've been unable to restart it because the error comes up within a few seconds.
I've gone back to the previous version and restored my AppData/Local/dslstats directory from yesterday's backup.
-
I recently upgraded to dslstats32W-5.7.1
Initially all was well.
Yesterday evening I started getting division by zero errors.
I have automatic start recording set so was unable to make any configuration checks or changes before the dialog box came up.
I have reverted to dslstats32W-5.6, which seems to be working.
I do have 24 hour averages set in Errors / Averages.
A possible clue.
My HG612 has been up for 51 days, with a lot of traffic going through it.
The dslstats32W-5.6 event log contains
27 Feb 2016 06:07:02 Configuration files stored in C:\Users\aw1\AppData\Local\dslstats\
27 Feb 2016 06:07:02 The configured modem/router is Huawei HG612
27 Feb 2016 06:07:02 Snapshot folder is C:\Users\aw1\AppData\Local\dslstats\
27 Feb 2016 06:07:05 Recording started
27 Feb 2016 06:07:09 Implausible up traffic value reported by modem/router
The Telnet Data display contains (recently)
ptm1 Link encap:Ethernet HWaddr F4:55:9C:77:96:6C
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:668639566 errors:0 dropped:0 overruns:0 frame:0
TX packets:1212938853 errors:0 dropped:258 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4294967295 (3.9 GiB) TX bytes:2132956719 (1.9 GiB)
Perhaps a big number / wrap around related problem?
-
R Pi new version up and running OK from 8 PM last night.
-
I've had a couple of Invalid Floating Point errors on my Rpi since upgrading to v5.7.1
-
Mine fell over again divide/zero and stopped uploads to MDWS for a while....
-
Just had an Invalid Floating Point error on DSLstats v5.7.1. Just restarted DSLstats v5.7.1 and it's uploading to MDWS again now.
-
I enabled traffic monitoring and since then .7.1 has been unstable and crashing.
-
I had it running on a Raspberry Pi for about 24 hours with no issues, and I'm currently running on a Windows 8.1 machine (8 hours so far with no issues). In both cases I enabled all the options in "Items to Monitor" and set it to upload to MDWS. All other options are at their defaults. In the case of the Windows version, I cleared out every remnant of previous installations, downloaded v5.7.1 from my website, and set it up from scratch.
I've never been able to reproduce these floating point issues and I'm running out of ideas. Over the next few days I'll try some more experiments, but this is going to take time. In the meantime, please remember that the computer running DSLstats must connect to your router via ethernet, not WiFi, and the downloaded files must be installed in a directory where you have unrestricted read/write access. The location of the configuration files must also be a directory where you have unrestricted read/write access.
-
Hi
I updated mine to 7.1 about 10am this morning and like roseway, have all monitoring options ticked, and as yet have nut seen this issue
The computer running dslstats, is Windows 7 64 bit, over wifi
The only thing I may have done differently, was to copy the whole of 5.7.1 into its own directory and not overwrite 5.6.
I hope that helps
Many thanks
John
-
Just noticing a lot of gaps on my MDWS graphs when using v5.7.1 on RPi just the one divide by zero 2 days ago all very strange ???
-
It would be interesting to know if you use the 24 hour averages or the modem/router uptime averages. Using 24 hour averages for me fixes the problem - its been months since I saw one.
Stuart
-
The PC is set to 24 hour averages the RPi was set to Modem/Router uptime averages but I changed that yesterday evening before 24 hours had lapsed, so the RPi is set to 24 hour averages.
-
Woke Win 7 computer from sleep and was notified that the program had stopped working - I have never had that before
-
No crashing overnight now that traffic monitoring is disabled again.
-
@tbailey2: The occasional divide by zero error has been bugging me for a long time, as I've never been able to reproduce it and haven't been able to locate a cause. The best suggestion so far seems to be to set the error averages to the 24 hour setting, not the modem uptime setting, and this seems to have fixed (or at least alleviated) the issue.
I'm not monitoring them....
I've looked into this, and most of the code which processes the averages is still run, even if you've disabled the display of the values. The default position is to display modem uptime averages. Therefore I suggest that you temporarily enable the averages display, set the choice to 24-hour averages, then disable the display again (if you don't want it).
-
Just happened again for me. :(
-
Therefore I suggest that you temporarily enable the averages display, set the choice to 24-hour averages, then disable the display again (if you don't want it).
There was another alert waiting from some time back so have done as you suggested and disabled it again....
Thanks
-
Have taken the step to revert back to v5.6 on the RPi to many odd gaps in my upload and DSLstats GUI freezing for 8 minute, will see how it looks after 24 hours with the older version.
-
So have I due to too many crashes
-
Guys, thanks for your continued support. But, may I ask why you released it with so many bugs?
-
William, it has no bugs on my machine.
The developer, Roseway, has tried over many months to find the cause of these div by zero errors but is unable to do so at the moment.
It is not a paid for piece of software; I'm sure if we put too much pressure on him, Roseway would just walk away from the software and not release any more updates.
Ian
-
Guys, thanks for your continued support. But, may I ask why you released it with so many bugs?
I can assure you no one releases software knowing it has bugs but there are as many different environments software can run in as there are users of the software. Also another misnomer software does not have bugs or break, it does exactly what the writer coded, the problem arises when a situation arises where something happens which the coder did not anticipate and something goes wrong because that situation was not coded for. There are loads of folks who are running Eric's software with no problem at all, you are only seeing those on here who do have an unforeseen situation as annoying as that may be. If someone writes code which never goes awry they are very lucky or it is very simple software. I know as I speak from nearly 40 years commercial experience of sorting problems in software.
So please no more simplistic comments.
Stuart
-
Hi
I agree with kitzuser, and would suggest that you realise the many different variations of systems/setups, which any number of reasons could cause the issue, which is why it has to be repeatable or reproducible, in order to resolve
Our 5.7.1 is working fine, no issues and I suspect the number of users with this issue is low, based on the number of reported users with this issue, but of course it could be that users with this issue has not reported as such.
It would be more helpful if, when users report the issue, they state their OS, exactly how they did the upgrade, any AV running etc... Which should help narrow the search to reproduce the issue
I know I moderate on a commercial forum, which is used world wide, and most when reporting issues, do not include any useful information to help, so it's magic ball time
@roseway, your upgrade works fine on our computer and thanks for the software, your efforts are appreciated
Many thanks
John
-
@broadstairs, ditto, sorry I think our posts crossed
Many thanks
Jihn
-
In no way am I criticizing Roseways DSLstats support if I could would like to help more to get the balance right across all supported OS's.
DSlstats Win32bit has no issues that I can see only since updating DSLstats on RPi from 5.6 to 5.7.1 things have started to happen on my upload it's also the reason why the later RPi v5.6.2 didn't work and had to revert back to v5.6 on RPi
All this info should help Roseway in his investigation
-
Hi newtonstar
It works fine on my Windows 7 64 bit over wifi
It would be good I think if you could fully remove from your rpi, and do a full clean install to see if it does the same
I'm sorry though, as I may have set dslstats to use the 24 hour and not modem or visa versa, as I'd need to check
I think if you could reproduce the issue in full and then let roseway know, or sometimes access to your system is really helpful, but understand reasons why this is not possible
I'm not going to post anymore as I don't think I'd be helpful now sorry, but I do hope everyone understands the complexities of software development (I know you do...)
Many thanks
John
-
It would be good I think if you could fully remove from your rpi, and do a full clean install to see if it does the same
I take it you have never had to set-up a Raspbian OS it's easy with noobs but then it becomes more difficult when setting up devices once you get it set the way you like it a clean install would become a nightmare :(
wondering if I update the RPi to:
Raspbian Jessie
Full desktop image based on Debian Jessie
Version: February 2016
Release date: 2016-02-09
Kernel version: 4.1
would that make a difference :-\
-
Guys, thanks for your continued support. But, may I ask why you released it with so many bugs?
I am 100% certain that this is not the case. If anything, I'd say Eric was more of a perfectionist when it comes to his code, and he would not knowingly release it if it had any bugs. He has always been co-operative in adding new features requested by us, and its quite often new features that can introduce bugs. Unfortunately bugs are sometimes occur no matter how much a program has been tested before release because you cant always test every single environment. Think about router manufacturers and think about with new routers how often they have to roll out new firmware after release because its only when actually in use that things sometimes come to light. I've beta tested new modem routers, Ive beta tested for ISPs too. Large companies have dedicated beta testers, yet things still get missed. Look at is like this - we here on the forum are erics beta testers and we report any bugs to him. :)
Eric puts an awful lot of unpaid hours into DSLstats - and he spends far more hours than he should at the PC. Its FREE, he even pays for hosting out of his own pocket and its one of the best programs available for monitoring stats. If I were Eric and I read that, then I'd feel extremely hurt to suggest that he would even consider doing such a thing. :(
-
Thanks for the comments, people. I won't add any more to it.
I'm continuing to look for solutions to the floating point / division by zero issues experienced by some users. It's hard going because I've never been able to reproduce them here. The approach I'm looking at now is to produce a somewhat slimmed-down version of DSLstats with some suspect sections of code either removed completely or rewritten in a simplified form (error averages for example).
-
Installed the new version on my RPI on Friday set to 24hr and not seen the error as yet come to think of it have never seen it on my RPI version. It's always the same people only complain when things go wrong as the guys give the time for free then we should try and help and support them more not give negative comments.
-
Hi
@newtonstar, yes that's more helpful thank you. At least the full distro in now known.
I apologise for my ambiguous statement over reinstall, I actually meant just dslstats but I can see why you thought a full distro reinstall, so apologies for that
@roseway, I didn't realise you paid for hosting, if it helps, I could set you up with hosting FOC, on lamp with cloudflare integration. You would have your own control panel and you look after your site, unlimited bandwidth and daily out of country backups.
Many thanks
John
-
That's very kind of you, John, but my hosting needs are very simple, and the cost isn't extortionate.
-
Just to add that although I had a few errors when I first upgraded (on my Raspberry Pi), since I changed to 24 hours averages it has been happily trundling along, error-free, for more than 48 hours now :) :fingers:
As an aside I remember (many years ago) poring for hours and hours on end over pages of assembler code trying to find the cause of an intermittent error. After several weeks I finally found the coding error, much to everyone's relief.
I believe the final inspiration was provided by a pint of Bass and a smoked mackerel baguette (although it's unclear which did the trick), so @Roseway it might be worth a try ;)
And thanks for all of your work.
-
@valleysboy: Thanks for the information, and thanks also for the helpful suggestion. I'll give it some serious thought. :drink:
-
Not sure if its relevant/helpful, but this is on a WinXP machine and it appeared the first time I opened DSLStats (from the system tray) after XP came out of hibernation (which it accidentally fell in overnight).
FWIW I have just downgraded to v5.6 again on the XP machine - with which I never had any problems.
With v5.7.1 I did receive the occasional Floating Point Error but the bigger problem was that DSLStats was not uploading any data - the icon still appeared in the system tray so I thought it as active - but disappeared when I tried to open it - and relaunching the software kept causing it to close/disappear within a few seconds.
If it helps to send any logs etc. to help id the problem please let me know
-
I've never been comfortable about how DSLstats deals with Windows hibernation. I simply don't have enough knowledge of Windows (I haven't used it for myself since 2000). All I can advise on this is to shut down DSLstats before hibernation.
-
Just installed 5.7.1 for Windows. Avast anti-virus chose to flag the main executable as a "probably unwanted program".
I've sent off their advisory to tell them otherwise.
-
Something rather odd this morning! The graphs are visibly progressing, but speeds are not showing in bottom section. the other details are. All was normal yesterday.
-
That's certainly an oddity. Nothing has changed recently in that area of the program, so hopefully it's just a one-off glitch. Just to make sure that it isn't just a redraw problem, does it look the same after minimising / restoring DSLstats?
-
For moment looks as if one off, but am having problems with Win reinstallation. I'll come back i d c if it recurs when I do a normal full system reboot and start dslstats.
-
I'm having issues with 5.7.1 also. It keeps crashing and giving errors on startup.
-
How does it crash? What are the error messages?
-
It is usually when I take the monitor out of sleep mode. I click the DSLstats icon in the windows bar which doesn't bring it up. It states DSLstats is not responding and shuts down.
As for the error at the beginning, I shall report back when it happens. Usually after a crash.
-
The error after a crash is division by zero.
-
Thanks for the information. I'm working on a possible solution to the division by zero error, although I'm unable to discover what exactly is causing it. The behaviour on coming out of hibernation is uncontrolled, and I'm afraid that all I can offer at present is either to shut down DSLstats manually when the PC is heading towards hibernation, or use a Raspberry Pi and leave it running 24/7.
-
I'll maybe revert to the older version as that did not give me this issue. Strange one.
-
DSLstats on my new RPi 3 has an odd problem - it doesn't remember the MyDSLWebStats username/validation key after a reboot; the fields are blank so there's an error message at startup. If I put them in manually it works fine - until a reboot.
It does remember the modem logon/password (which is NOT admin/admin).
It was working fine on my RPi 2 (which is now a standalone media server) with AFAIK exactly the same OS and software - very strange.
I'm sure I'm doing something silly ...
-
That's a bit strange. The MDWS values are saved in the same file as the login details. Could you check the file
/home/pi/.dslstats/dslstats.ini , and check that is has a [mydslwebstats] section near the end. It should look something like this:
[mydslwebstats]
Warning shown=1
Do webstats=0
Webstats name=<your MDWS name>
Validation key=<encrypted validation key>
ZIPUploadTime=42436.414634375
Curl path=/usr/bin/curl
Bitloading=1
SNR per tone=1
HLog=1
QLN=1
-
I'm still getting the occasional Floating Point Error on the RPi. Happy to look through any logs if it would help and you can point me in the right direction. I've had a look in various logs in /var/log but can't see anything.
-
Here v5.7.1 ist running stable on the rpi with error average set to "24 hours".
-
Oddly, Now that I have reverted back to the older version, It too keeps crashing now with the same issue.
-
Do you have selected "24 hour averages" on the Errors -> Averages tab?
-
Nope, Modem/router uptime averages.
-
I've just changed to 24hr average, will see how it goes.
-
I'm currently in the process of completely rewriting and simplifying the error averages function. I hope that this will put the issue to bed once and for all, but time will tell.
-
If I were to remove every trace of DSLstats from the computer, Where might I find other files? I can only assume I've got a conflict somewhere as it has only started happening.
-
On my Win 7 machine, the config files are in C:\Users\Dray\AppData\Local\dslstats
-
Thanks. I ended up doing a search for everything dslstats related and deleted the lot. Hopefully starting afresh will sort out the issues I've seen.
-
DSLstats on my new RPi 3 has an odd problem - it doesn't remember the MyDSLWebStats username/validation key after a reboot; the fields are blank so there's an error message at startup.
It seems to be OK now. I suspect some kind of weird timing problem with autostarts. The Pi3 is rather quicker than the Pi2 but now I've added some other things at startup, DSLStats is happy.
-
Thanks for that information. You're very possibly right about it being associated with autostarts.
-
For the record. I have now had no further issues since removing all files for DSL stats from my computer then re-extracting 5.7.1. It must have been a bad file from all the previous updates etc. Running like a dream now.
-
Thanks for that.
-
5.7.1 and 5.7.3 don't appear to save my settings - I have to enter all my details every time I start the program. I have full permissions for the dslstats.ini file but nothing gets saved in it. When I look at the file after choosing my router and a couple of other settings, the changes are there, but when I shut down and reload DSLstats it seems to revert to the default settings. I'm on Windows 10 Pro.
I also can't get it to upload to mydslwebstats - Unable to check at present.
-
Please have a look at Configuration --> Misc. There is an option "Location of config files". Whatever option it shows, change to the other option and see if it works properly after that.
-
I changed from "As advised by operating system" to "With other DSLstats files". I then quit and restarted the program but it still hadn't saved my settings. Am I missing something glaringly obvious?
At least my uploads to MyDSLWebStats is working again, although I suspect that is a separate issue an not related to my settings not being saved.
-
Just to be clear, does it fail to save the settings when you close down DSLstats, or does it fail to load the saved settings when you start up DSLstats? It's hard to see how it could save the settings when you configure DSLstats, but then delete them again when you close it down.
-
OK, I've just loaded up and configured DSLStats. If I look at the dslstats.ini file, I can see the details of my router and so on.
This is the Event Log:
13 Mar 2016 12:10:04 Configuration files stored in C:\Users\Brian\AppData\Local\dslstats\
13 Mar 2016 12:10:04 Snapshot folder is C:\Users\Brian\AppData\Local\dslstats\
13 Mar 2016 12:10:04 Average error data reset
13 Mar 2016 12:10:12 The configured modem/router is Billion 8800NL <-- this is actually the 8800AXL which works in the same way
13 Mar 2016 12:10:40 Config files moved from C:\Users\Brian\AppData\Local\dslstats\ to C:\Users\Brian\AppData\Local\DSLStats\
13 Mar 2016 12:10:45 Recording started
13 Mar 2016 12:10:47 Incorrect login name or password
An incorrect login name or password was supplied
13 Mar 2016 12:11:14 Recording stopped
13 Mar 2016 12:11:30 Recording started
13 Mar 2016 12:11:36 IP address is now [redacted]
13 Mar 2016 12:14:28 Sample rate set to 60 seconds (required value when MyDSLWebstats option is set)
13 Mar 2016 12:14:30 MyDSLWebStats validation check failed
Closed the program and it looks as though the changes are still present in the dslstats.ini file.
Restarted the program, and once again the settings have been blanked and will need to be re-entered. It looks like it is blanking the settings when I start the program. I've searched my hard drive in case it's pulling the file from elsewhere, but there is no other dslstats.ini file to be found.
The downloaded .zip file doesn't contain the .ini file, so I presume it is generated when the program is first run?
-
Config files moved from C:\Users\Brian\AppData\Local\dslstats\ to C:\Users\Brian\AppData\Local\DSLStats\
I suspect that this is the problem. Windows filenames aren't case sensitive, so those two directories are effectively the same. This will probably confuse Windows, or DSLstats, or both. I suggest that you delete both those directories and unzip the downloaded files somewhere else.
-
There is only the one folder, C:\Users\Brian\AppData\Local\dslstats. I'll try renaming it it.
Event log now looks different:
13 Mar 2016 13:44:47 Configuration files stored in C:\Users\Brian\AppData\Local\dsl_stats\
13 Mar 2016 13:44:47 The configured modem/router is Select modem/router model
13 Mar 2016 13:44:51 Snapshot folder is C:\Users\Brian\AppData\Local\dsl_stats\
13 Mar 2016 13:44:51 Average error data reset
13 Mar 2016 13:45:02 The configured modem/router is Billion 8800NL
13 Mar 2016 13:45:39 Sample rate set to 60 seconds (required value when MyDSLWebstats option is set)
13 Mar 2016 13:46:18 MyDSLWebStats validation check failed
13 Mar 2016 13:46:24 MyDSLWebStats validation check failed
13 Mar 2016 13:46:24 Recording started
13 Mar 2016 13:46:24 MyDSLWebStats validation check failed
13 Mar 2016 13:46:30 IP address is now [redacted]
Whatever that was, it seems to retain the settings OK now.
Hooray!
-
I'm pleased you got it sorted.
-
I have a Ubiquiti Edgerouter with an Echolife BTOR modem.
Would this work with this combination?
-
Yes it should do. You need to unlock the HG612 - see http://www.kitz.co.uk/routers/hg612hacking.htm
and then connect it like this: http://www.kitz.co.uk/routers/hg612unlock.htm#hg612_linestats
DSLstats or HG612_Modem_Stats can now be used to collect stats from the IP address of the HG612, which is 192.168.1.1 unless you've changed it.
-
Thanks Eric, but i have just realised my modem is an ECI ::)
I guess i will have to replace it with an HG612?
-
If you want to collect full stats, then yes, or some other Broadcom based modem.
-
I'm afraid to report the dreaded floating point error is back for me running 5.7 on pi. Happened at approx 24 hours from starting 5.7
5.6.2 did the same thing
back to 5.6 for me which has been faultless for months
Any insight Eric, do you need any logs ?
-
I'm assuming that you mean 5.7.1 (5.7 was never released). I believe this issue is fixed in 5.7.3 (see http://forum.kitz.co.uk/index.php/topic,17232.0.html ).
-
Yes 5.7.1
I wil upgrade and re-test
-
Sorry to report that I have now had "Invalid Floating point operation" error on my Raspberry Pi, about a day after upgrading from 5.6 to 5.7.1 . I've been running 5.6 for many months (since it's release) with no problems, and in fact held off trying newer releases due to reports of this error, but as it was looking more stable I thought I'd try 5.7.1
Is there anything I can provide (logs? where?) that might help?
Ian
-
You need version 5.7.3 - http://www.s446074245.websitehome.co.uk/downloads.html
-
You need version 5.7.3 - http://www.s446074245.websitehome.co.uk/downloads.html
Ah, I see! I'd just let dslstats download the new version it was offering, which was 5.7.1.
Have now downloaded 5.7.3, and started it running at 18:42BST
Ian
-
Yes, sorry for the confusion. v5.7.3 is a pre-release (beta) version, so it doesn't get an automatic upgrade notice.
-
Yes, sorry for the confusion. v5.7.3 is a pre-release (beta) version, so it doesn't get an automatic upgrade notice.
It's ok, thanks for your help and the hard work on this very useful piece of software :yay: :clap:
Ian
-
Yes 5.7.1
I wil upgrade and re-test
Been running fine now on 5.7.3 since I upgraded
-
Thank you for confirming that.
-
It would seem V5.7.3 on the RPi has fixed those uploading gaps to MDWS, would have been lucky to get a 98% online status with 5.7.1 or even 5.6.1
I am just being over cautious here and will look for any gaps during the upload over the next five days.
-
I've upgraded, too. 5.7.1 was actually working fine for me but I've gone to 5.7.3, just in case.