JKSV works fineWell I'll be. That works. I wonder why 1.1.12 works on Atmosphere 0.19.0 but 1.1.13 doesn't. Definitely odd. Now if I could find a save manager that works on AMS 0.19.0 Id be set
JKSV works fineWell I'll be. That works. I wonder why 1.1.12 works on Atmosphere 0.19.0 but 1.1.13 doesn't. Definitely odd. Now if I could find a save manager that works on AMS 0.19.0 Id be set
Certificates for cartridge dumps are actually useless if you install them instead of mounting them. The reason being is that certificates are meant to be used with raw .XCI files which are supposed to be mounted. When you install an .XCI file, you are actually converting it to an .NSP file then installing it. .NSP files do not use certificates but instead they use tickets which are not interchangeable with one another. So if you install an .XCI file with the certificate, it will be lost during the installation.I'm a new user here, but I have a question.
When dumping a game through NXdumptool (so I can play it without needing to insert the gamecard all the time), is it necessary (or a danger) to keep the certificate?
I plan to install through Awoo Installer.
I understand that sharing the game with the certificate is dangerous, but for personal use, do I need it to access cloud saves/online play/download updates from Nintendo servers etc? If I attempt to do the above without the certificate, will it get me banned?
Likewise, is there a risk of doing anything online without a certificate? (access cloud saves/online play/download updates).
Any help would be much appreciated!
Certificates for cartridge dumps are actually useless if you install them instead of mounting them. The reason being is that certificates are meant to be used with raw .XCI files which are supposed to be mounted. When you install an .XCI file, you are actually converting it to an .NSP file then installing it. .NSP files do not use certificates but instead they use tickets which are not interchangeable with one another. So if you install an .XCI file with the certificate, it will be lost during the installation.
Mounting may be theoretically safer but not only is it only possible with one CFW that is on the verge of becoming irrelevant but people have already been banned just for mounting .XCI files. Also going online with a hacked console is never a good idea regardless if you installed an .NSP file or not.I see... I thought the certificate was used to verify legitimate copies. So I thought it would be a good idea to keep it.
So I assume mounting is safer than installing then as the certificate will be applied to it?
So if I installed an .NSP file, that means I can't go online at all for anything then since Nintendo would detect it I assume.
Alright, thank you very much for the help.Mounting may be theoretically safer but not only is it only possible with one CFW that is on the verge of becoming irrelevant but people have already been banned just for mounting .XCI files. Also going online with a hacked console is never a good idea regardless if you installed an .NSP file or not.
Certificates for cartridge dumps are actually useless if you install them instead of mounting them. The reason being is that certificates are meant to be used with raw .XCI files which are supposed to be mounted. When you install an .XCI file, you are actually converting it to an .NSP file then installing it. .NSP files do not use certificates but instead they use tickets which are not interchangeable with one another. So if you install an .XCI file with the certificate, it will be lost during the installation.
This is known as a title takeover or application override. It gives homebrew applications access to a ~3.5 GiB memory pool - and yes, even though some people may disagree, it's always the better practice when it comes to homebrew launching on the Switch.
Running homebrew apps under applet mode only provides them with access to a ~300-something MiB memory pool. Depending on what you want to do, it may not be desirable.
But that is only doable on SX OS which less and less people are running nowadays due to TX not pushing an update to support the higher firmware versions in 6 months so mounting is also becoming less relevant.XCI Explorer allows you to remove or insert them into a xci which you could mount them
@DarkMatterCore what speed of dumping do you achieve via USB?
DBI dumps NSP through MTP without any soft/drivers on PC side ~130-150 MB/sec on USB3 from NAND.
I wonder, if there is a possibility to speed up if using own protocol (add thiis to dbibackend).
@DarkMatterCore where will batch mode be? Any changes there?
What overhead are you talking about? Maybe for small files it does matter, but for big ones there are no overhead: there is short request packet from PC side with command GET_OBJECT, small packet with responce on switch side and after that raw stream of file data switch->PC without any headers/waiting/etc until all file data is sent.which usually adds overhead on its own even on Android phones
It adds overhead because MTP depends on additional OS drivers/components to work, which aren't needed when you're using a custom USB protocol - in other words, data comes straight from the USB driver. The MTP implementation found within Windows isn't exactly speedy, for example, and it can easily freeze for some seconds before starting a data transfer stage (in my experience).What overhead are you talking about? Maybe for small files it does matter, but for big ones there are no overhead: there is short request packet from PC side with command GET_OBJECT, small packet with responce on switch side and after that raw stream of file data switch->PC without any headers/waiting/etc until all file data is sent.
Speed in DBI calculated as ((total sent bytes) >>20)/(total passed seconds)
Raw read from NAND is about 150-170 MB/sec (via ncmContentStorageReadContentIdFile)
Read + hash calculating is about 120-130 MB/sec
I found out that read/write speed (nand and usb) highly depends on buffer size. Right now DBI uses 128K chunks for USB operations and 4MB for NAND read/write.
I'll change the chunk sizes I'm currently using and check if any of my testers reports back any meaningful improvements, then. I'm already using multiple threads as well.I have no experience with Windows implementation of MTP. I only using Linux with gvfs over libmtp.
I do not get what is wrong with dividing total sent data by total spent time?
Just verified measurement via "time gvfs-copy "mtp://[usb:001:104]/4: Installed games/Disgaea 4 Complete+ [B+U131072].nsp" ."
It gives the same result. Of course it is average speed for the whole file.
8Mib chunks is not a good idea - on tests I got worst performance on this size.
I do agree that on small files MTP sucks - depends on file size it can greatly increase transferred data.
Of course DBI's data transfer is multithreaded: reading from system and sending to USB are done in separate threads. Before this speed was almost twice lower.
Are you sure they're typical RIFF-encoded WAVs? File extensions mean nothing at all.Why is it when I extract music (.wavs) from the DQ classic games, they don't play after opening them in a media player?