- Joined
- Jul 19, 2011
- Messages
- 1,560
- Trophies
- 2
- Location
- Emerald Coast
- Website
- web.archive.org
- XP
- 6,173
- Country
No need to update, “if it ain’t broke, don’t fix it”
For me... If it ain't broke, fix it till it is.
The way I see it App2USB risks database corruption, the new extended storage doesn't have that but you lose the ability to access the disk from Windows/MacOS/Linux etc (at least for now).
I don't use an external hard drive, but if I decided to start then I wouldn't use App2USB.
Last edited by smf,
the way you see it is incorrect.
the database issue is due to the fact the ps4 rebuild does not include pkgs signed with debug keys in the rebuild so even using the ps4 external drive if your ps4 crashes and rebuilds you will lose the tables from the db for every fpkg installed.
the same thing goes if you are using nothing but the internal drive.
don't be complacent with thinking the external format would stop the database being wiped out, keep regular database backups as you install games
even if we had a patch to include the fpkg files in the rebuild it would need to be injected when the console boots and we don't have access to that yet.
How would we back up the database file? Any info would be appreciated!!!the way you see it is incorrect.
the database issue is due to the fact the ps4 rebuild does not include pkgs signed with debug keys in the rebuild so even using the ps4 external drive if your ps4 crashes and rebuilds you will lose the tables from the db for every fpkg installed.
the same thing goes if you are using nothing but the internal drive.
don't be complacent with thinking the external format would stop the database being wiped out, keep regular database backups as you install games
even if we had a patch to include the fpkg files in the rebuild it would need to be injected when the console boots and we don't have access to that yet.
extended storage has it's own database, it must do or this would be impossible:
Therefore if you have a problem then you can unplug the drive before it rebuilds. You can't do that with app2usb because the games are in the internal database and without the drive plugged in then it will detect an error.
If the database on the external drive is actually corrupt then it's a problem, unless you can plug it in after running the exploit and then make it rebuild.
Last edited by smf,
you need to understand how the console works instead of guessing.
the external drive does not have an external database on the physical drive or somewhere in the console.
the same database that is used for the internal drive is the same one that's used for the external drive.
that is the app.db and it is located in /system_data/priv/mms/ and if your system is rebuilding the app.db you can unplug that drive like you are barry allen and it does not matter if you are the fastest man alive you will not stop the system wiping out the fpkg tables because the database is not on the ext drive.
apptousb does not interface with the database in any way so it does not "risk" corruption any more than running any other payload would.
there is a difference between checking storage and rebuilding database.
checking the storage does not wipe out the game tables because its not checking the database.
when the database corrupts you will get rebuilding database and this is where the problem is, this action will delete the tables for the fpkg files.
feel free to test it...
according to you when the database rebuilds if you remove the ext drive the "database" on the ext drive would not be changed because its not connected and you cant do this with apptousb.
so install some fpkg games to the ext hdd and then shut down the console then unplug the ext drive, boot the console into safe mode then select rebuild database, this is the same function that is performed when corruption occurs.
let it rebuild and then boot into the system and connect the ext hdd and you will find every fpkg game missing.
repeat the process with the ext hdd connected just incase it needed the drive connected and the result will be the same.
the same will happen for the internal drive and apptousb drive because it has nothing to do with the drive.
it is the app.db and there is only one for all drives and it will only wipe out fpkg games, all the legit games will be restored.
I hope this clears up the confusion and like I said before to correct the corruption problem you backup the app.db and if it rebuilds/corrupts you take that backup and ftp into the console and place it in /system_data/priv/mms/ and reboot the console straight away and the tables should be back and working for all drive types.
edit: I forgot to address the video...
what he has done in the video is he has installed the same game to the ext hdd on 2 different consoles and he is just moving the ext drive between the 2 because the app.db on the internal drive will have the same path on both consoles.
the path in the app.db for the game would be something like this /mnt/ext0/user/app/CUSA00009 so on both consoles they will look in the same location.
the license files are still on the internal drive and in our fpkg case they would be in /user/license.
you cant just take the ext hdd full of games and plug it into any ps4 and have the games because if we could do that sony would have failed big time allowing people to just make a diskimage of the ext drive and allow any game to be shared.
so the game needs to be installed on each ps4 which sets up the lic files and the app.db with the paths needed to access the ext hdd.
the same thing can be done with apptousb, install the games on 2 consoles and link them on 2 consoles using the same drive and move the hdd between consoles
the external drive does not have an external database on the physical drive or somewhere in the console.
the same database that is used for the internal drive is the same one that's used for the external drive.
that is the app.db and it is located in /system_data/priv/mms/ and if your system is rebuilding the app.db you can unplug that drive like you are barry allen and it does not matter if you are the fastest man alive you will not stop the system wiping out the fpkg tables because the database is not on the ext drive.
apptousb does not interface with the database in any way so it does not "risk" corruption any more than running any other payload would.
there is a difference between checking storage and rebuilding database.
checking the storage does not wipe out the game tables because its not checking the database.
when the database corrupts you will get rebuilding database and this is where the problem is, this action will delete the tables for the fpkg files.
feel free to test it...
according to you when the database rebuilds if you remove the ext drive the "database" on the ext drive would not be changed because its not connected and you cant do this with apptousb.
so install some fpkg games to the ext hdd and then shut down the console then unplug the ext drive, boot the console into safe mode then select rebuild database, this is the same function that is performed when corruption occurs.
let it rebuild and then boot into the system and connect the ext hdd and you will find every fpkg game missing.
repeat the process with the ext hdd connected just incase it needed the drive connected and the result will be the same.
the same will happen for the internal drive and apptousb drive because it has nothing to do with the drive.
it is the app.db and there is only one for all drives and it will only wipe out fpkg games, all the legit games will be restored.
I hope this clears up the confusion and like I said before to correct the corruption problem you backup the app.db and if it rebuilds/corrupts you take that backup and ftp into the console and place it in /system_data/priv/mms/ and reboot the console straight away and the tables should be back and working for all drive types.
edit: I forgot to address the video...
what he has done in the video is he has installed the same game to the ext hdd on 2 different consoles and he is just moving the ext drive between the 2 because the app.db on the internal drive will have the same path on both consoles.
the path in the app.db for the game would be something like this /mnt/ext0/user/app/CUSA00009 so on both consoles they will look in the same location.
the license files are still on the internal drive and in our fpkg case they would be in /user/license.
you cant just take the ext hdd full of games and plug it into any ps4 and have the games because if we could do that sony would have failed big time allowing people to just make a diskimage of the ext drive and allow any game to be shared.
so the game needs to be installed on each ps4 which sets up the lic files and the app.db with the paths needed to access the ext hdd.
the same thing can be done with apptousb, install the games on 2 consoles and link them on 2 consoles using the same drive and move the hdd between consoles
Last edited by stooged,
A little new at this - in that link... which exactly is the payload? Like is this something I should be hosting on my computer if possible? Or do you put all of the files on the root of a usb stick? thanks.
Other people have said you can move drives and the games appear without without having to do that, are you saying they are all lying?
Another video
It even gets upset if you plug it into a console that has the game installed internally,
http://www.playstationlifestyle.net/2017/02/11/ps4-external-hdd-used-on-multiple-units/
There must be something more going on than you're suggesting.
Last edited by smf,
Similar threads
- No one is chatting at the moment.
-
-
-
-
@
RedColoredStars:
Never even seen a tiger crust pizza in any stores around here. Walmart, Cub, or otherwise. -
-
-
@
RedColoredStars:
Last thing I told her is how much I love her, and that Im not leaving her there forever and I promise to come back and take her back home with me.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
