Qt variant crashes while loading MAL list

[alsoGAMER]

Traceback (most recent call last):
File "/usr/lib/python3.10/site-packages/trackma/ui/qt/workers.py", line 185, in run
ret = self.function(*self.args, **self.kwargs)
File "/usr/lib/python3.10/site-packages/trackma/ui/qt/workers.py", line 161, in _start
self.engine.start()
File "/usr/lib/python3.10/site-packages/trackma/engine.py", line 249, in start
(self.api_info, self.mediainfo) = self.data_handler.start()
File "/usr/lib/python3.10/site-packages/trackma/data.py", line 168, in start
self.process_queue()
File "/usr/lib/python3.10/site-packages/trackma/data.py", line 370, in process_queue
self._load_cache()
File "/usr/lib/python3.10/site-packages/trackma/data.py", line 506, in _load_cache
self.showlist = utils.load_data(self.cache_file)
File "/usr/lib/python3.10/site-packages/trackma/utils.py", line 228, in load_data
return pickle.load(datafile, encoding='bytes')
EOFError: Ran out of input

Trackma version: 0.8.4.r199.ge132db0-1

GTK variant also throws but doesn't crash, instead it fails to load the list entirely.

[z411]

Your list got corrupted apparently? Try clearing the list cache (deleting the ~/.local/share/trackma directory).

[alsoGAMER]

I also had to re-add the account cause after deleting its directory (username.mal) it would error out with an http 400. Though I think that the qt build is a little too prone to crashes (compared to the gtk (and the others) one).

[z411]

Indeed Qt isn't as good as handling errors. But these errors shouldn't be happening in the first place. A pickle EOFError means something is wrong with the list cache, and a 400 with the MAL API would mean the token is wrong (and it shouldn't) so it's better to fix the underlying bugs instead.

[alsoGAMER]

Could the list corruption be caused from using git versions?

[z411]

It shouldn't. Does it happen all the time?

[alsoGAMER]

Nope, first time.

[FichteFoll]

It can happen when your disk is full, for example, which isn't exactly recoverable from trackma's POV outside of writing to a different file first and then replacing the old one.

That said, throwing the cache away if it cannot be read is something that trackma could do by itself to remedy the situation.

[z411]

I never tried to get Trackma to drop the cache if it couldn't be read because that means data was lost, something that shouldn't have happened in the first place. This is bad for people who don't sync often, or worse, if we ever plan to implement a 100% local list as suggested in another issue.

Maybe we could switch to a more reliable method for saving the cache. I was thinking SQLite but a simpler but reliable alternative would be welcome.

[z411]

Another idea could be to always keep a backup of the cache (maybe after each update in the list) and load it if the cache is corrupted. That would mean the last unsynced change would be lost at worst, which is much better than dropping them all.

[kzdixon]

Adding the cache removal solution to the error message might be helpful at least. Ran into this problem just recently and thankfully found this issue. Disk wasn't full or anything, it just randomly corrupted after I accidentally clicked something in the UI in the List dropdown iirc.