Will look into it.. Probably an issue with the JS libs. Is the data stored incorrectly in the .csv files stores in the /webui/ folder? edit: bug fixed on latest
CSV files (mainnet) are sorted low -> high. I tried to quickly look, but did not find the problem in webui.go neither javascript, it seems like you have the latest versions (did not try github). Unfortunately I have to leave now. I noticed in examples on their web page they use "tsv" but that really should not be a problem.
Using csv versus tsv shouldn't be an issue, but I found out you could load tsvs from remote hosts but not csvs (wtf?). Spent almost 3 hours debugging that one. The issue was that dimple had to have a sort function added on the axis, with that added it and the strings converted to ints before running the sort function it works fine.
I have not seen any recent commits in cjepson neither decred dcrticketbuyer repo. Any update please ?
It was squashed into the PR before the merge. The graphs should be sorted normally on master, commit 471c747f656e30e951463bbca3bafbf5ecfd572f : https://github.com/decred/dcrticketbuyer
This one probably ? https://github.com/decred/dcrticketbuyer/commit/471c747f656e30e951463bbca3bafbf5ecfd572f But javascripts are the same as before, are you sure ?
Yes, that has the right js. The x axis needed a rule order to print sorted. Dimple is strange. https://github.com/decred/dcrticketbuyer/blob/master/webui.go#L303-L305
@chappjc Discovered a bug in ticketfeeinfo. The median amount doesn't work correctly. For now, only the mean should be used for fees. Should be fixed on master soon.
@ceejep I think something is going wrong with the fees in general when ticket price changes. Here's where the ticket price adjustment happened: 15:52:46 2016-05-29 [INF] DCRD: Block height 32399 connected 15:53:06 2016-05-29 [DBG] TKBY: Mean fee for the last blocks or window period was 0.003331982727272727; this was scaled to 0.031 ... 15:57:48 2016-05-29 [INF] DCRD: Block height 32400 connected 15:58:10 2016-05-29 [DBG] TKBY: Mean fee for the last blocks or window period was 0; this was scaled to 0.031 I had my min fee set to 0.031. But here's whet ticketfeeinfo had to say: > dcrctl --wallet ticketfeeinfo { "feeinfomempool": { "number": 413, "min": 0.01010101, "max": 0.4054054, "mean": 0.08320176, "median": 0.16835016, "stddev": 0.07106043 }, "feeinfoblocks": null, "feeinfowindows": null } The fees are way higher than dcrticketbuyer indicated. Perhaps it is just because the price changed at 32399. But by 32400 the mean fee surely wasn't 0. I have a bunch of tickets that won't get mined. Gotta wait for expiry.
Thanks, probably a bug in this code: https://github.com/cjepson/dcrticketbuyer/blob/master/feeest.go#L33-L85 It's supposed to find the fees for the last, most comparable window to the current ticket price, but it might be broken. I'll see if I can refactor it to make it testable tomorrow, then fix it.
Just a PSA: if you are running the HTTP server, please make sure you bind it to localhost in your configuration file. Code: httpsvrbind=localhost By default it opens on all interfaces right now. The default was changed in a pull request: https://github.com/decred/dcrticketbuyer/pull/3
Added a PR for ability to better choose which price indicator to use for calculating the average price https://github.com/decred/dcrticketbuyer/pull/6
Lots of PRs were merged today, fixing a large number of bugs. Please update your dcrticketbuyers. https://github.com/decred/dcrticketbuyer
I noticed that the ticket price has become much more stable recently. Is this likely to be a consequence of many users switching to Dcrticketbuyer? If so - I'm surprised (and happy!) to see it have such an impact.
I realised there could be another potential cause - the lauching of 7 new stake pools. These two things may be closely related if the stake pool code makes use of dcrticketbuyer...