It was not like the screenshot. The top Assets box was checked yet below a dozen subitems were unchecked.
Thanks, I have to debug it, but, I’m not sure I will have time to finish it before tomorrows release.
Otherwise I will release a fix as soon as I find the problem.
As always, thank you for your bug report. 
2 Likes
It occurs that this could explain the behavior that @Grayclay was seeing. This problem affected enough of the jEveAssets users in my coalition that we joked about needing to redo our census.
jEveAssets 5.5.0 released
Bug Fixes:
-New logic to ensure uniqueness of Journal and Transactions
-Possible fix for tracker problems
-Don’t try to update active ship via EveKit for corporations
Changed:
-Removed support for the now dead XmlAPI
-Increased the amount of times ESI retries from 1 to 3
-Update error message from “Not allowed yet” to “Waiting for cache to expire”
-Added warning when EveKit accounts have invalid ESI auth
-Workaround for 9e18 locations
Code:
-Updated eve-esi to 2.1.8
-Updated EveKit to 2.4.0.2
2 Likes
Thanks for the update to 5.5.0
Thanks for the reporting of the Tracker filter bug. I checked mine and I too had unchecked stations. Never knew this feature existed so I definitely did not uncheck them. As a positive note there is an option to uncheck all those Unknown Location reports caused by ESI bug on lost items from ship kills. But it has not had an immediate effect on their reporting in the Overview or Tree tabs. Maybe on next Update?
@Yenna_Zambooruk
Thank you for your feedback.
The problem with the destroyed assets from jEveAssets point of view, is that it’s impossible to know if they’re just in a structure that can’t be resolved or destroyed items. So, sadly It’s not possible to fix from my side.
But, there is great news: The assets bug with destroyed items are being worked on right now.
I don’t know how long it will take to fix the bug for the ESI team, but, I do expect it to be fixed very soon.
The bug with 9e18 locations have also been fixed in ESI (it was already fixed in jEveAssets in the last release).
1 Like
Great work
I am a new user and have a problem with stockpiles
The buy order doesnt appear in the report
Thanks
Do you have buy orders included?
1 Like
You are a genius
@Elenoire_Doissetep
I admit I’m not very good at creating easy to use user interfaces.
It’s not exactly obvious you need to include them like that.
@Johann_Hemphill
Thank you for providing support for your fellow jEveAssets users
1 Like
I have noticed several very large files (over 200 MB each) in my C:\Users[My Username].jeveassets\profiles folder, named #Default_5.5.0.backup and so on. Overall they are taking over 3 GB of drive space. Can I delete them?
@Luscius_Uta
Yes, but, it may be a good idea to keep the latest one of them. You can zip them to reduce the size a lot.
Extra Info:
Every time a new version of jEveAssets is released, it will make a backup of your profiles and settings, in case, I did something really bad with the code, that will corrupt the settings or profiles.
1 Like
and in the data directory there a bunch of similarly huge backups.
Yerh, It may be an idea, for me to do the backups in a zipped format, to reduce the size
Edit: Added to the ToDo list
Edit2:
This work is now done and will be included in the next release.
It will be limited to new backups (it will not zip the old backups).
it will increase the time it takes to make the backup by a factor of 10 (From ~600ms to ~6 seconds for a 300mb profile) and decreases the size by a factor of 10 (from 300mb to ~30mb).
Edit3:
I also experimented with compressing all the non-backup xml files, but, it would complicate editing the files by a fair bit as you would have to unzip them to edit them and then zip them again to use them. Additionally it also increase the CPU usage and the time it takes to save and load each file. I specifically chose xml to keep the files easy to edit and I decided to stay with that, even though 300mb is a lot. Feedback on that decision is very welcome…
2 Likes
jEveAssets already has a pretty heavy memory and CPU footprint when dealing with my 20+ characters and corps. The Java process balloons to 7.5 GB of memory (from 1 GB idle) and chews aways at max CPU (on one core) and max disk usage for 2-3 minutes on every update. Recommend not compressing the non-backup xml files. Disk space is plentiful.
1 Like
Rookie question. I’ve recently restarted using JEveAssets since the ESI switchover, and it’s been working great. However, about a week ago, 2 of my altcorps stopped being able to read contract items. I get a 404 error code whenever I attempt to refresh contracts, but only for these 2 accounts:
I have 5 altcorps registered, and the other 3 work fine. Removing and re-adding the account doesn’t change anything. Any suggestions?
(Currently running v5.5.0)
@Auran_Glimmer
Thank you for your bug report.
I will need a little more info to debug it. Since It may require private information to fix, I’m going to ask you to email me (my email is on the wiki)
I will look into it as soon as I get your email.
1 Like
You have 300mb of xml files…? The directories i’ve found are:
jEA Installation_path + %USERPROFILE%.jeveassets
What i found there are a ton of duplicate .jar files in the \lib-dir all with different version numbers, are those really neccessary or can i delete the old ones? and if so plz create a routine that cleans up the installation after every update if that’s possible.
regarding Edit2:
before updating, create a compressed backup of the current version, delete older ones, update. Like that? sounds great
regarding Edit3:
My main concern about disk usage in general is if programs put lots of data on my system partition (in this case %USERPROFILE%\.jeveassets). I prefer this (small SSD) partition to be slick for fast and small backups without programs and unneccessary big program data.
I have no ideo how often and how many xml-files you need to open after startup but if every account with up to 3 chars is adding more and more data, then this can get a lot bigger then 300mb.
But if this would slow you down in development, or if jEA requires a lot of (de-)compression and writing of xml-files and also creating more cpu load while in use, well then do more important stuff. My user directory has only 82MB of data, so i don’t care but i don’t know which dimensions this can become for heavy users.
-tldr- Performance is more important then disk usage unless performance loss would only be marginal vs. 90% less disk usage
@Jin_Rot_hani
Re Data Directory:
Yes, the very large profiles and settings files only affect people with a lot of characters and a lot of history (tracker data, wallet journal etc.). The decision have been made to zip backups and keep everything else unzipped. Someone was so kind to borrow me their 300mb profile and 600mb settings files (I have been using them to optimize jEveAssets, with great results so far) and zipping files that big is not going to work, it simply takes too long to load and save.
Re Lib Directory:
Yes, you can delete the old library files. Simply delete the entire lib directory and run jEveAssets and press OK when asked to download the missing files.
And you’re right, this should be corrected. However, I have not come up with a good way to do it, yet.
The problem is that I do not want to delete anything the user put into the jEveAssets directory.
Only old library files should be deleted, nothing else. That will require a fair amount of work on the jUpdate project. But, I have added it to the ToDo list, so hopefully I will get the time to do it soon’ish.
1 Like
Sounds great, deleting the lib and restart jEA worked fine so don’t waste time thinking about this.
Maybe you could in the future simply remove the version numbers from the filenames and therefor overwriting them with every program update, unless you need those numbers to reduce download bandwidth or something, then leave it as it is i guess.
The Data-Dir was the main issue and you found a solution for that, so good job, as always