Open mmozeiko opened 7 years ago
Just a thought but why not piggyback DownloadEnabler.surpx? Once that is installed (or better yet, prepackage it into pkgi) you click on the game you want to download in pkgi and it will launch the native browser and being downloading the game. This will allow background downloading and queuing up games to download. Once the user gets notified that the file is done downloading (screenshot), they open up pkgi again and installation takes place. The only thing the user would really have to do is press the "save" button in the bottom right hand corner of the popup dialogue that is seen in the browser (unless you can automate that somehow) and then switches back to pkgi with some instructions such as "you may now close the app" or something along those lines.
It's not the cleanest implementation but maybe it's an option? I just tried this myself by going directly to the 'zeus' links and downloading two games in the background and it worked very well and with great speeds. Could be a temporary workaround till something else comes along.
Will that unpack pkg while downloading? Or download whole pkg and then I'll need to unpack it? Because having 2x space for downloading and then unpacking is not cool.
You're right in the sense it does download the whole pkg then you'd have to unpack. Didn't realize pkgi was doing this simultaneously. How are you doing this? If that's the case, it would require 2x the space then and that is indeed not cool.
I was thinking if you're able to find out where the game is being downloaded to (while it's downloading it is not in ux0/download/) then maybe you can still perform the unpacking while it's downloading? Not sure. It just depends on how the unpacking is working which I havent really looked at the code to see whats going on.
Edit:
Just quickly digging through Download Enabler the temporary files are being stored here
sceClibSnprintf(bgdl_path, sizeof(bgdl_path)-1, "ux0:bgdl/t/%08x/%s", num, file_name);
I can see the partially downloaded pkg
Its pretty easy - you read data from network, you decrypt it and then write to file. There's not much to it. It doesn't make sense to do it separately, it would be actually more work - read from network, write to file, wait until it finishes, then read from file, decrypt and write to file. No idea why to do it like that ...
Using partially written files will be a lot of pain. There will be so many synchronization issues to handle. And at the end all that effort will be wasted, because it won't be reusable for real background download code that I intend to write.
If downloading and unpacking is simultaneous then I don't really know how you're going to accomplish this without being a system app. There are no homebrews that allow to background downloading afaik. As soon as you open another app it will prompt you to close PKGI. I'm curious if/how you'll accomplish this.
If you did use a fully downloaded pkg, then started decrypting it (instead of a using partial download), couldnt you delete files within the pkg that have been decrypted? potentially not having to use twice the space? decrypt icon.png...delete icon.png from pkg, move to next file...etc.
I don't really know how you're going to accomplish this without being a system app.
Afaik kernel plugin can do work in background.
couldnt you delete files within the pkg that have been decrypted?
That's not how files work. Not on Vita, not on your PC. You cannot erase some part of it (unless its right at the end) and file size reduces. Erasing part of it (to reduce total size) requires reading everything that is after it and writing it back.
I think a kernel plugin is the best option. This would allow you to use the Notification Center in the vita too!
"I think a kernel plugin is the best option. This would allow you to use the Notification Center in the vita too!" False it is handled by userland. bgdl are handled either by SceShell or by one of its modules. So it would be a user plugin under main* that would call SceShell' sub function, or directly a call to a SceShellSvc exported functions.
Oh. Thanks. For correcting me xD
Download should happen in background. This requires #2 to be implemented first.