Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[tbailey2]

That's a relief, thanks for confirming it.

The change I made was in the detection of the prompt after issuing the various stats retrieval commands - previously I was checking for the prompt character as either the last character of the output or the next to last. Now I look for it in the last 20 characters (or anywhere in the string for commands returning short outputs).

Hi

You may have noticed that MyDSLWebStats is not displaying many of your graphs. Reason is that, and you are in Italy I believe, the equipment you are using to upload has European formatting for decimal points and hence the uploaded  data has commas wherever they occur. This stops graphs displaying that use float values and totally screws up the Hlog and QLN graphs as well. The facility was really only designed for UK users as it warns on the Registration screen although you are welcome to use it of course.

If you can change the formatting to use periods instead of commas, it will work okay. You are also an hour ahead of the UK which may make the timeline a little odd. I imagine there are also bandplan differences that may affect some of the tone-related displays.

I'll  fix the comma problem  longer term so the formatting doesn't need changing.

[Axel Foley]

Tony,

thanks a lot for the prompt advice. When I tested this version, I took a quick look at mydslwebstats and noticed that some graphs were not displaying, but it was too late to debug.

Thanks for letting me know about the issue. You say I can fix the formatting, but I can't find the option in DSLstats, or is it on the server side?

[Axel Foley]

That's a relief, thanks for confirming it.

The change I made was in the detection of the prompt after issuing the various stats retrieval commands - previously I was checking for the prompt character as either the last character of the output or the next to last. Now I look for it in the last 20 characters (or anywhere in the string for commands returning short outputs).

My pleasure, and thank you very much for the prompt support. I think your solution should be good for any possible prompt style now. Eventually, if I'm allowed to make a suggestion, consider a debug tab in the telnet section where you output what you send/receive. Not all users can sniff the network and give you details about what's happening on the communication side.

Now I have to think about running the software on my NAS (Synology DS1812+), so I don't need to keep the notebook turned on h24. I saw the raspberry version, but it's not quite what I need. Anyway, you made an amazing work.

Happy holidays...

[roseway]

Thanks for your kind remarks.

Eventually, if I'm allowed to make a suggestion, consider a debug tab in the telnet section where you output what you send/receive. Not all users can sniff the network and give you details about what's happening on the communication side.

That sounds like a good idea. It was certainly your network sniffing which led to the solution here.

I think the decimal character issue is probably down to me. As far as I know, DSLstats displays its own graphs properly, taking into account the different forms of the decimal divider, but the MDWS uploads make use of a float-to-string conversion which observes the standards of the locale. I should be able to use a different type of float-to-string conversion which always uses a full stop for the decimal divider.

[Axel Foley]

That sounds like a good idea. It was certainly your network sniffing which led to the solution here.

I suspected the prompt since the beginning, also because I saw an inconsistent behaviour with special login, but I thought it was the ansi codes in the prompt. Anyway, I'm glad to have been helpful for this improvement.

I think the decimal character issue is probably down to me. As far as I know, DSLstats displays its own graphs properly, taking into account the different forms of the decimal divider, but the MDWS uploads make use of a float-to-string conversion which observes the standards of the locale. I should be able to use a different type of float-to-string conversion which always uses a full stop for the decimal divider.

One of the things I learned when I was a young developer is that one important rule is to never trust the user input. So while I agree you could address the issue, I think that the best solution would be on the server side. Which, when receiving data, converts it appropriately. From what I saw, the server side can work with other software too, so the rule applies there, it shouldn't "trust" what the applications send.

Is there an API to communicate with mydslwebstats or you just agreed on a data format and you send files?

[tbailey2]

Tony,

thanks a lot for the prompt advice. When I tested this version, I took a quick look at mydslwebstats and noticed that some graphs were not displaying, but it was too late to debug.

Thanks for letting me know about the issue. You say I can fix the formatting, but I can't find the option in DSLstats, or is it on the server side?

Local OS ...

[Axel Foley]

That would have an impact on too many things Tony.

But thanks a lot, you've been very kind to alert me on this issue.

If my data creates problem on the server side please let me know and I'll disable the upload until this issue will be resolved.

[tbailey2]

That would have an impact on too many things Tony.

But thanks a lot, you've been very kind to alert me on this issue.

If my data creates problem on the server side please let me know and I'll disable the upload until this issue will be resolved.

It's not a problem on the server as  such other than the data stored now for you has commas in where they exist which won't currently display graphs.

I'm unfortunately short of time to today to do much and I'm going to be away for a while but I've adjusted things so that for the moment, at least the SNRM graph will now display properly using existing uploaded data along with any others that don't have floating point data in! I'll see if I can fix some more tomorrow.

I said the Local OS as user morphium who is in Switzerland had the same problem but has resolved it as he's uploading with periods rather than commas, by changing the local OS settings I assumed. 

Longer term it can get fixed by modifying the uploaded data but needs some experimentation/testing first. If roseway can do something with DSLStats that would be a lot easier but it's also more work for him that I suspect he doesn't need at the moment 

[Axel Foley]

Yes he said that the function used uses OS localisation, so the problem lies there, but I also wrote that imho, the best solution, since the server side could also receive data from other apps, is that a check on data be done at that level.

Is there an API to communicate with the server or it's just a datafile transmission and it's then parsed on the server?

[tbailey2]

Yes he said that the function used uses OS localisation, so the problem lies there, but I also wrote that imho, the best solution, since the server side could also receive data from other apps, is that a check on data be done at that level.

Is there an API to communicate with the server or it's just a datafile transmission and it's then parsed on the server?

All the data is uploaded preformatted to the server by both of the apps that can upload.

I have also fixed a few other graphs plus HLog, SNR/Tone and QLN.

[Axel Foley]

That's very kind of you Tony...but enjoy your holidays, this is stuff that can wait...no priority.

This forum is very nice, I found very kind and competent people.

So data should come from the clients with a predefined format, including decimal and thousands separators. I understand, thanks for the info.

[Axel Foley]

Yes he said that the function used uses OS localisation, so the problem lies there, but I also wrote that imho, the best solution, since the server side could also receive data from other apps, is that a check on data be done at that level.

Is there an API to communicate with the server or it's just a datafile transmission and it's then parsed on the server?

All the data is uploaded preformatted to the server by both of the apps that can upload.

I have also fixed a few other graphs plus HLog, SNR/Tone and QLN.

Tony, I noticed most of the graphs are working fine now...there are a total of 6-7 out of all that don't work but I don't even know what they are.

One question: could you also address the timing issue by asking clients to upload data universally in GMT time then allowing users to configure mysdslwebstats to configure the proper timezone? Or ask clients to put the timezone into the uploaded data?

Thanks a lot for your work.

Thank you very much for this.

[Axel Foley]

Tony, in 5.3.1 Eric also fixed the locale issue. Can you tell me if everything's fine now? I started using last 5.3.1 version some hours ago.

Thanks.

[tbailey2]

Tony, in 5.3.1 Eric also fixed the locale issue. Can you tell me if everything's fine now? I started using last 5.3.1 version some hours ago.

Thanks.

Shouldn't really see any difference and I can't here, all looks fine. Maybe there are other graphs working now that were not before though?

[tbailey2]

One question: could you also address the timing issue by asking clients to upload data universally in GMT time then allowing users to configure mysdslwebstats to configure the proper timezone? Or ask clients to put the timezone into the uploaded data?
Thanks a lot for your work.

Thank you very much for this.

Looking at the graphs with a timezone an hour ahead on a laptop, there doesn't seem to be much of a problem - the main criteria is that your own graphs show the time correctly along with data up to that time and other users have theirs correctly shown also. There are a couple of places where the time is GMT and should be an hour ahead or vice-versa but I guess these are not a deal breaking problem. 

The work involved in trying to fix this both for the local client and the server is not something I can attempt at the moment or in the foreseeable future though I'm afraid due to other 'real' work commitments.