Print

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

[roseway]

As you can see from the QLN text file, the router is reporting values all the way up to tone 4095 (although the last few tones report illegal values), so I think DSLstats is showing it correctly in the graph.

I can't explain the third bitloading graph, but I do recall that when the new blob was released for the HG612 it was noticed that the bitloading data didn't get refreshed between re-syncs, so it may possibly be an artifact of that.

[ryant704]

As you can see from the QLN text file, the router is reporting values all the way up to tone 4095 (although the last few tones report illegal values), so I think DSLstats is showing it correctly in the graph.

Is that normal for a connection? I don't think it is? Every time I've looked at it before I cannot remember it being that long...

I can't explain the third bitloading graph, but I do recall that when the new blob was released for the HG612 it was noticed that the bitloading data didn't get refreshed between re-syncs, so it may possibly be an artifact of that.

I will attempt a manual re-sync later, just waiting for some questions to be answered from BT.

[roseway]

Sorry, I missed this.

Is that normal for a connection? I don't think it is? Every time I've looked at it before I cannot remember it being that long...

I don't have a VDSL2 connection, so I really don't know.

Thinking more about the odd bitloading graph, it occurs to me that the fact it's all green means that the band plan wasn't being detected properly. If your band plan has been changed, DSLstats may have failed to read this properly, but I would hope that a restart of DSLstats would fix this.

[Bald_Eagle1]

Ok! I have a question, I'm pretty sure it's a bug but I might just be being stupid!

On the QLN graph you can see it's showing all the way up to tone 4083. Now, If i was able to use band D3 I would expect it to be doing it's job correctly. Though I can't access band D3, not even close in fact... In the BitLoading graph you can see I'm using up to tone 1417 from D2.

FWIW, my lowish speed connection shows QLN data right through the bands, but Bitloading, Hlog & SNR graphs only report what my connection is able to use due to attenuation over 1100m or so of line length

[snadge]

Ive noticed that the newer versions dont save QLN or HLOG graphs automatically...is that right? is there any chance we could get this back on? especially QLN.. if not what is the latest version I can jump back to so I can get it?

thanks

[roseway]

I'll get back to you on this.

[Later] I don't think the QLN and HLog graphs were ever autosaved. The reason is that they are only refreshed at the time of a re-sync, so you would end up with a lot of identical graph snapshots. If you really want to retain the data you can autosave the text versions (the output of the QLN and HLog CLI commands).

[snadge]

I'll get back to you on this.

[Later] I don't think the QLN and HLog graphs were ever autosaved. The reason is that they are only refreshed at the time of a re-sync, so you would end up with a lot of identical graph snapshots. If you really want to retain the data you can autosave the text versions (the output of the QLN and HLog CLI commands).

I have screenshots of QLN that have been autosaved before? although not many - also a couple of INVALID IMAGES of the QLN and HLOG

I think it would be important to have it save QLN (and Hlog) graphs, for instance today I have noticed a potential fault on my line (probably water getting in to JB) and the QLN was iffy - so I scatted around my DSL Stats folders looking for previous screenshots so I could use as evidence as "before and after" to sky (if it got worse) but there were none...luckily I found one in folder dated 2.Oct.

I suppose I could always keep one but what if its changing over time? it would be easier to have it autosave so i can have screenshots of them all

as for the text outputs I dont know how to render them into graphs, It would make sense to have them incorporated into the program to have it all automated?

Im sure they used to be autosaved....but you should know as you created the program lol...

[burakkucat]

I regret to have to report a 'peculiarity' with the latest version of DSLstats. 

I have the utility configured to take a snapshot of all the active graphs upon exit. I have noticed that a Bitswaps (xml) file is now being created, along with the active graphs, upon exit. 

[roseway]

I have screenshots of QLN that have been autosaved before?

Don't you think it's more likely that you saved those snapshots manually, by clicking the "Take snapshot" button which is found under every graph?

I could certainly add those graphs to the autosave list if you really want them.

[roseway]

I regret to have to report a 'peculiarity' with the latest version of DSLstats. 

I have the utility configured to take a snapshot of all the active graphs upon exit. I have noticed that a Bitswaps (xml) file is now being created, along with the active graphs, upon exit. 

Yes, you're right. I see them among my own snapshots too. I'll correct this shortly.

[burakkucat]

Many thanks Eric. As long as you know and have it on your ever-lengthening ToDo list, then all is well. 

[snadge]

sorry i saw the XML files too but thought they were supposed to be there...sorry..

I dont think ive ever pressed "Take Snapshot" button, and its got them in 2 days folders, I dont use 'snaphot' buttons because ive been thinking they autosave, and when i want instant screens I use Share-X (F6 and its captured, uploaded and URL in clipboard) its quicker for me.. strange?

yeah I would very much like that option if you could please?

thanks

[kitz]

Thanks for that suggestion. It's effectively what the Linux versions do (each user has a home directory where user configuration files are kept), but I'm not so familiar with Windows and I wasn't sure what directory to use. However I've now found a standard FreePascal call which does the job:

GetAppConfigDir returns the name of a directory in which the application should store its configuration files on the current OS.

So I'll incorporate this in the next release.

Anyone know where this is installed please?   When I update I normally just transfer the relevant files into my folder leaving the config file in place so I can just fire up dslstats immediately without having to redo all my settings.

However Ive just done the update and I saw the config file immediately disappear as soon as dslstats started running.

I cant see anything under
C:\Users\kitz\AppData\Roaming

I HATE anything being put under root c:\ , but I cant see it there

Win7 onwards doesnt have
c:\documents&settings\username\applicationdata\progdirname

Ive even done a search which has come up with zilch.

Wheres it gone? 

[kitz]

Ok think Ive solved this dslstats.cfg now becomes dslstats.ini which is why it didnt come up when I searched.

A new dslstats folder is created in

C:\Users\kitz\AppData\Local\dslstats

This means the dslstats is no longer 'stand alone' and if the user uninstalls the program, they will have to manually delete that folder.   

Eric Im not sure if you want to add a note to this effect on your site for windows users, as they may like me have been lookin under app roaming. 
The problem is though its likely to be different for XP  
Likely c:\documents&settings\username\applicationdata\dslstats.  Can an XP user confirm this please.   

[broadstairs]

You have to do this in Linux as well if you remove a program, however the files are stored under your personal home directory so they dont clog up system partitions. Usually on Windows a program supplies an uninstall script which can remove these files if required.

Stuart