It's quite likely that the "commonality" is false- you noticed it because you were trying to update the data. It didn't fail because it "knew" that you updated the data, it randomly failed on that and you noticed because you updated it.Originally Posted by Tromador(Source)
Ok good. I'm glad you said that because I thought logic was on the blink again.Originally Posted by eyeonus
As to random - I don't buy it. I sent updates for the same station several times. If it were random, then surely one (or more) of those updates would have gone through, even if not all.
Now - if you wanted to suggest some random mechanism selected that station for failure, but once selected it stayed borked - possibly for a finite length of time, possibly forever - I'd buy it. However, spending much time sitting at a single station and testing all over the shop, I can say with confidence that a given station stayed borked for at least an hour, possibly longer.
It's not simply random updates that get discarded, once a station has been picked on, all the updates for that station get chucked.
Yep, that fixed it. Thanks Tromador.Originally Posted by Tromador
Sorry about that, copies of my tdh.ini and tdhelper.db files were accidentally included in the release. I have updated the release without these files so that should sort this out.
That's what I meant. Random as to station, not as to message.Originally Posted by Tromador
I wonder if we need to start trying to gather some data for this then and see if there is a pattern which isn't immediately obvious. The only (immediately obvious) common feature of my examples is that they were planetary.Originally Posted by eyeonus
It wouldn't be a bad idea. I can't see anything in the code that would account for it. I know there isn't any kind of error happening- it would show that.Originally Posted by Tromador
How hard would it be to write an audit app?
I am thinking
Run listener and log messages to a file, say for an hour (possibly longer if need be).
Run an app which reads the log, checks the database timestamps on the recent systems and gives a list of all those where the timestamp hasn't been updated.
That is likely the best way to gather a meaningful amount of data quickly.
I don't think it should be too difficult. I can sort of see the pseudocode in my head, but it's been a while since I programmed much of anything.
No, it wouldn't be that difficult. I was thinking about doing something similar, i.e., having the listener print out what the information is supposed to be (the values from the message) versus the values it is (using a sql SELECT) immediately after doing the UPDATE, if they differ.
That said, right now my life is pretty much work,sleep,work,sleep, so I won't really have the time to do either until at least Friday. Hooray for days off.
@Tromador - Sorry for the delay in getting back to you with the python installation instructions for the Mac, I got side tracked by TD Helper. The instructions are very simple as follows:
*****
Mac OS and Python
As of 10.9, OS X ships with Python 2.7.6. DO NOT "upgrade" your system to the latest version (3.7 at the time of writing) instead download the latest python installer for MacOs from https://www.python.org/downloads/. Once it has downloaded run the installer by locating the downloded file in the Filer and double-clicking the .pkg file or right-click on the file and choose 'Open'
Click on the 'Continue' button and the 'Agree' button where necessary until the last screen is reached where you press the 'Install' button and python will be installed. You will be asked to enter your admin password once the installation has started.
Checking it works
Open a terminal window and cd to the directory that contains the "trade.py" file from the source. Once you've found it, verify that it works by typing:
It should respond with basic usage instructions.Code:$ python3.7 trade.py help
If you have installed a different verison simply change the 3.7 to the version that you just installed.
Proceed to the "Getting Started" section below
*****
I do have some screen shots if you need them. Send me a PM with an email and I'll bung them over.
I don't think it's urgent, so I'll leave it and let you do it. If I did it, it would be in PERL (I need my curly braces dammit!) and take 10 times as long whilst I retrain myself in the how and why of simple scripting.Originally Posted by eyeonus
No problem making me wait. It's all stuff that needs doing before release, but we aren't exactly in a screaming rush, with different ling bugs/new features still to work on.Originally Posted by MarkAusten
PM (about to be) sent. Thanks for helping out
Is it worth updating the Trade Dangerous page on ED Codex and adding a new page for the EDDBlink stuff?
I've added a page for TD Helper.
That's the plan, but we're holding off on that until the kinks get worked out.Originally Posted by MarkAusten
That said, the only real issues right now are with the listener, so I guess it'd be alright to do that now.
Maybe let me finish sorting out the documentation first. I've made some headway with it, but finding the time when I'mOriginally Posted by eyeonus
a: Not at a hospital appointment for any one of my unique collection of chronic ailments.
b: Feeling well enough to do some work (on account of the aforementioned collection).
is hard at the moment. It doesn't help that the docs are (or were) an unholy mess with lots of what (imho) should have been separated out sections all being shoved into excessively long documents covering multiple topics.
Gimme a week or so and I'll have it done.
Although the only problem is with the listener, as we are labelling EDDBlink that out as the officially supported data source and that in turn relies on the listener (either via my server, or a local instance), I wonder if the current big problem with the listener picking stations to ignore shouldn't be fixed before we go to an official re-release of the tool.
Possibly. Revisit when documentation is finished, my vote.Originally Posted by Tromador
