Problem: The command "import -P eddblink -O listings" generates an error

[nepomuk16321]

Problem: The command "import -P eddblink -O listings" MUST be executed twice for me at the moment.
The first execution generates an error (see screenshot). On the second execution, the command is accepted and processed
("runs smoothly"). I didn't want to open an issue for this now, because it works after the second start of the "import" command.
But something seems to be wrong.
First run:

Second run:

[eyeonus]

The problem is being caused by a station that moves: #Selected station: ZENDE/THE CONDUIT, ID=-1 This was determined by running the command with -w and looking at the resulting error report, so thanks to @kfsone for adding the rich format error output, it was very useful in this case.

The station is a "Mega ship" (internal type_id of 13)

The old data (i.e., the previous days' nightly dump,) says that station is in 'Synuefe EN-H d11-96'. It is apparent that the ship has moved in between the last dump and the most recent one, and since the prices file was built using the old data (and uses {system name}\{station name} rather than the station's unique id), that's where the problem comes from.

Developer communiqué:

The easy solution to this particular problem would be to delete the TradeDangerous.prices file whenever the plugin determines that a new Station.csv has been acquired from the server. This 'solution' has two caveats:

1. It wouldn't fix the underlying problem, so while it would make this problem stop occurring when doing an eddblink import, it would still happen if someone tried to import, say, a prices file created by EDMC for example, that had the same root cause.
2. We don't currently check if the server's tables have been updated since the previous dump (because we don't currently have a way to track that) and so we always export the tables during every dump.

The source of this problem is that the changeStation() method was written before E:D added stations which could move to the game. It needs to be modified to take into account that some stations can now move: https://github.com/eyeonus/Trade-Dangerous/blob/02ac0c6eada715c127555837fde7dd9df2213539/tradedangerous/cache.py#L457C1-L462C22

(Also, I noticed this while trying to find the cause of this problem: systemID = systemByName.get(systemName, -1) # why -1 and not None? From the commit history, the person who originally wrote that line was @kfsone, and the person who added that comment was also @kfsone. I can see that the next line is if systemID < 0:, so my guess as to why -1 and not None is, at the time of writing the method, this was for some reason better than doing if not systemID:)

[nepomuk16321]

Hello @eyeonus , thank you very much for the detailed explanation !!!
It's not a problem for me. I can live with it ;-).

[kfsone]

That part was so early it's probably safer to assume I just didn't understand None very well :)

[nepomuk16321]

Sorry, maybe @kfsone wants to say something else, so open again.

[rmb4253]

It is strange that I have a problem on first trying to update my database but it doesn’t present as an error. Mine tells me that there are two instances of Rescue ship Arc’s Faith and then shows import complete. Re-running the exact command again completes the whole update with no problem.

Presumably, the rescue ship is another example of a movable station but nepomuk gets a python error, where I get a jump to the end! Odd!

I’m glad there seems to be reason for it - I was seriously considering going to find this rescue ship and attack it!! 🫢

[kfsone]

@eyeonus I don't know anything about the carriers work, except apparently that they appear in the data somehow as stations. Want to make a discussion/ticket for this to soundboard / spitball solutions?

[eyeonus]

Sure #175