Cache Save Images to the Cache Folder

[Dark Akuma]

This would of course allow loading the save tab to go MUCH quicker. The only reason I did not do it before was because I lacked data on the images to know when the cache file needs to be updated.

But that is no longer the case with the System Save object available. The timestamps can be read from that, saved with the cached images, and compared to as needed.

Maybe I can even use the DBInfo file to save the timestamps for comparison, if setting the file names seems a bit much, or setting the files normal timestamps does not work, or just accessing either of those en mass is too slow.

[Dark Akuma]

We do kind of cache save images already. It’s just that they are skipped based on Exists() checks. Not timestamps/changes.

I think it's the device FileExists() check that's slow. I guess I was more prepared than I thought, as I thought we just downloaded the images every time, and that was why things were so slow.

Currently we:

SwitchSDcardDevice.EnumerateDirectories();
foreach (string directory in directories)
{
  SwitchSDcardDevice.FileExists( SRAM );
  SwitchSDcardDevice.GetFileInfo( SRAM ) // if it exists.
  SwitchSDcardDevice.FileExists( SaveStatePath x 0-4 )
  {  
    !File.Exists( CachedImagePath x 0-4 )
    {
      SwitchSDcardDevice.DownloadFile( To CachedImagePath );
    }    
  }  
}

That's the stuff that can/does contribute to the slowness. Any SwitchSDcardDevice call that can be avoided, should be. That would eliminate the most slowdown.

SystemSave.SaveSlot.Timestamps;
SwitchSDcardDevice.EnumerateDirectories();
foreach (string directory in directories)
{
  SwitchSDcardDevice.FileExists( SRAM );
  SwitchSDcardDevice.GetFileInfo( SRAM ) // if it exists.
  !File.Exists( CachedImagePath x 0-4) || CachedImageTimeStamp < RemoteImageTimeStamp
  {  
    SwitchSDcardDevice.DownloadFile( To CachedImagePath );
  }  
}

We would reduce the SwitchSDcardDevice calls from 5-6 per known game, to 1-2.

SRAM we check for its Size value. Maybe we could cache that value… but thats something for another time.

The only way to improve things further would be to eliminate the SwitchSDcardDevice.EnumerateDirectories() call. But that would require eliminating the need to check SRAM.

[Dark Akuma]

Added. Was not hard. It’s not lightning fast, but certainly faster. DebugLogging might be limiting the speed though.

Noticed a issue with the images not display in the saves tab, when their cache file is created in that same session though.

[Dark Akuma]

Fixed display issues. It was more than I thought. They were not loading the info at all due to a confusion with all the conditionals in the DownloadCacheImage() method.

[snucker]

Seems to load 2-3 games per second. I can’t confirm or deny if it’s faster than before, maybe you can tell from the number of titles per second?

[Dark Akuma]

I never bothered to measure and compare speed with this fix. I just know that calls to the device slow things down, and eliminating as many as I can would help in the end.

I cant eliminate all the slowdown though. The long pause after the first file is deleted (files that are being replaced/updated, have to be deleted first. So at a minimum, the titlesdb/DBINFO files) is a DBI issue I can’t address. Best I can do with that is… maybe show a message and change the progress bar while its doing that. And as mentioned, if I could replace the SRAM check, I could eliminate the only major call left. The whole point of that check is to get the sram size, for listing in the save management tab. So in theory I could maybe use the titlesdb sram option for that… but only for GBA. Only it and N64 use that sram param, and N64 does not use it accurately. I think I can also improve the sram checks a little by just not checking sram for games that have not been launched yet. Such info is available in the system save. But that would be overall minor to the slowdown, so not a priority right now.

[Tokyo Panda]

If I am understanding this. This is for the speed of loading save states (progress bar at the bottom right of CaVE) when connected through DBI MTP Responder. I tested this with my N64 database and it works just fine. It takes a few seconds to load all the save states but its not extremely slow. The progress bar helps a lot so you dont think its just frozen.

[Dark Akuma]

This really should have been confirmed more back when the change was first made. Now… you would not really be able to see a speed difference, since people would be used to the current speed now.

I left this open too, probably just in case there was any issue with this overall change. Ill consider it resolved now.