Emulator Issues #10485
ES content file handling is unnecessarily complicated and wrong
Because of the direct WAD launch hack, ES ends up having to rely on NANDContentLoader for accessing NAND contents. This is normally not an issue; it's just slightly annoying to find out that ES's ReadContent just does an IOS_Read from the NAND, while Dolphin has to go through all those hoops.
But it turns out there are several problems caused by this approach:
The FS logic ends up being re-implemented in ES, whereas it should just be in FS for obvious reasons. Actually, right now, I wouldn't be capable of saying whether ES_ReadContent and ES_SeekContent handle all the edge cases properly and like FS.
Because NANDContentLoader is used from outside of IOS, any changes and fixes to it might have unexpected effects on ES and result in different behaviour.
For example, since 5.0-2642, all content info comes from the TMD -- as they should. However, this caused a regression: the content file functions now use the TMD instead of the file metadata for content sizes, which causes issues in case of mismatch. This is known to cause the system menu to fail to load if Priiloader is installed.
When using a WAD, content files end up having to be decrypted every time they're used. And they're kept in memory the whole time. This is a waste of resources when they could just be imported to the NAND and decrypted once at that moment.
To properly fix this issue, usages of NANDContentLoader should be removed from ES code completely. (There are more reasons for not using it at all in ES, but they are not listed here as they're unrelated to content handling.)