-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash when obtaining EDSM logs #2544
Comments
Thanks for the report. It looks like your logs probably include at least one very old EDSM record without a SystemAddress property. We want to have that as a key field but we'll need to make it a little more forgiving again for EDSM. |
I'm still getting errors, and am unable to complete the EDSM sync. EDDI isn't crashing like it did before, but the sync is just failing to complete. |
The next release should help with this. |
This may still be an issue on version 4.0.3-b4. EDDI no longer crashes, however, after clicking the "Obtain EDSM log" button, the logs are quickly fetched to about half-way (roughly 7000/15000), then it becomes extremely slow. It's obtained only 1800 log entries (total 8800/15000) in the past 30 minutes. Is this a EDSM rate limit? |
It sounds like you're hitting the EDSM rate limit. |
Hmm, I don't think it's the EDSM rate limit. I've just gone back to EDDI 4.0.2 to test it, and I obtained all 12680 logs in less than 2 minutes with no slowdowns at all, apart from a half-second pause every now and again. I tried the other day with beta 3, and it slowed down around half way through, and never finished. I ended up closing EDDI down after about 5-10 minutes. I don't know how long it was exactly, as I didn't time it, but it was a long time. I'll wait an hour or two to make sure I'm not going to hit any limit after just trying with 4.0.2, and I'll give beta 4 a try and see what happens. |
It's been 5 hours and I'm at 14000/15000 log entries fetched. It's still running. |
There are two stages to the update process. Obtaining your logs and saving them to star system entries. If the local database already contains star system entries then it can move through those quickly and fill in any missing flight log data. If it needs to obtain data from EDSM to create those entries then obtaining the star system details is the thing that can cause you to hit your rate limit. If we create star systems without those additional EDSM details then the process will go much quicker but the data stored in your local database will be less complete. The more I think about it the more I think that is a worthwhile trade-off. I can probably keep those systems marked as stale so that if you need data about a specific star system EDDI can still fetch the details you need for that specific star system. |
Well, I've just tried 4.0.3-b4, and it started to really slow down at around 10100 (out of 12680), then stopped at 11400 after about 8 minutes, and hasn't moved since. It's now more than 25 minuted since I started, and is still on 11400. So, 4.0.2 works fine and fast, completing in less than 2 minutes, but 4.0.3 fails. There has to be something different between 4.0.2 and 4.0.3 that's causing it to slow then stop. |
I never disputed that. My goal was simply to explain (to the best of my recollection during a work break and in fairly general terms) how the code functions and offer a possible optimization. Now that I've had a chance to go back and review the code in more detail, it looks like I introduced a change early last month that had the opposite of the intended effect and (as it turns out moved away from the more optimized state I had described above). Change reverted. Edit: With this change, my test sync of almost 20,000 log entries took almost exactly 15 minutes. |
…rload the EDSM API during a sync. Resolves #2544 concerns raised after release of 4.0.3-b4.
Apologies, I didn't mean to sound rude. I had already composed my reply before you posted yours, as I was just waiting to see if it would change from 11400, but then I dozed off. When I woke up, it hadn't changed, so I put in the time and posted, without realising you had answered in the mean time. Again, I'm sorry if I sounded rude, that was never my intention. |
What's Wrong (please be as specific as possible)
EDDI process is crashing when obtaining EDSM logs.
Expected
EDDI fetches all EDSM logs and does not crash.
Observed
When clicking the "Obtain EDSM log" button, EDDI crashes after fetching 2800 log entries. The UI disappears and the
EDDI.exe
process is no longer running.Steps to reproduce
Configuration
My Investigation
Investigation Notes
I enabled verbose logging and observed an exception being thrown in the logs immediately prior to the crash.
I tried resetting my FDev cAPI connection and even changed my EDSM API key to no avail.
EDDI Logs
Player journals
Can provide if needed.
The text was updated successfully, but these errors were encountered: