lolz..yea, i know.....i put it there silly....:p
I meant if you try to install with USBUtil, you have to fix that first or it wont even install.:chinscrat
Printable View
opps you are right i mixed up with HDD .lolQuote:
I meant if you try to install with USBUtil, you have to fix that first or it wont even install.
Seems i found another 'bug' with USBUtil 2.0.....
I have over 150 games on my HDD now and it seems USBUtil cant deal with the amount of games, as everytime i install a new one, it keeps reporting i have a bad game and to try restoring/repairing it, but all games are installed as good.
But now i find games are randomly being labled as "bad", even though they have worked fine. If i delete that 'bad' game, it installs ok again in good status, but now another game is reported as bad, even though it was good just before the new install.
These games that are labled as "Bad" will white screen in Open PS2 Loader, even though they worked OK before.
Perhaps you should use WinHex or similar tool (UltraEdit also shows binary files in hex), to compare the "ul.cfg" entries of copies of it made before and after such changes of a game from normal to "Bad" state. I'm not sure if you have any regular method for triggering such faults, but if you keep making an extra backup of ul.cfg after each new successful install, then you will be prepared for a comparison when next the program reports a game as 'Bad'.
As for the WSOD error in OPNPS2LD, I have gotten that for several games for which USBUtil did not report any errors. I'm not sure though if it doesn't mess up something else too, beyond the games it reports as 'Bad'...:crazy: That could explain it as nearly all of my installed games were already installed before some such error message.
Even so, OPNPS2LD is still in such a stage of beta development that we can't really use its results as a fair measure of the work of other applications, like USBUtil. The results are still interesting to know, but they don't have the same final validity as if OPNPS2LD itself was already a finished and long verified design.
Btw:
I believe that a WSOD coming where we normally expect a yellow/green screen really means a total access failure of some kind, though I'm not sure if it was a failure to open one of the iso part files or something inside the 'iso'. But since the middle portion of the iso part filename prefix is a CRC value, any miscalculation of the CRC algorithm could cause an access failure. And it might not necessarily be an error in the installed file's name, but could be a CRC calculation error in OPNPS2LD leading it to attempt loading a file that doesn't exist.
Such mistakes are possible since game entries in the "ul.cfg" file do not contain the CRC values, but only the other parts of the iso filename prefixes. The CRC values must be calculated by the game launcher and combined with the other name parts to form the complete pathname of the file to be accessed. So with any error in that CRC calculation the name used will be wrong and the game launch will fail.
This long digression on how a game launcher can fail may seem off-topic here, but it really is not, since a mismatch between the CRC value used for the physical file names and the value used later when a launcher tries to run those games can be caused by either the game installer (here USBUtil) or by the game launcher. The games will only work if both get the same CRC calculation results.
Best regards: dlanor
Good idea, i'll make a copy today before and after the next installs.
Sure i understand that, but all the games that have WSOD after they have already run fine in OPS2LD only WSOD after being changed by Usbutil when a new install took place. I had tested games many times over without any such WSOD since jimmilaelkael fixed the issues i had initially with any WSOD games.
So this is why im certain its a bug with USBUtil as it is the installation of a new game that it changes the status of another installed game and that changed status will WSOD when run in OPS2LD after the status change by USBUtil.
no, im not relying on OPS2LD's results as a measure for UsBUtil, only that OPS2LD is affected by the changes made by USBUtil.
jimmikaelkael also thought it could be a CRC issue due to long filenames, maybe it is the cause of the white screening, but its still being caused by changes made by USBUtil. OPS2LD might be coded to 'bypass' such errors once its figured out what is changed, but USBUtil will still be the app that is doing the changing and could benefit from being fixed from making the changed status in the first place.
If it turns out that it is in fact the long filenames, then maybe ISEKO could make it so the app cant input names longer than 32 bytes or whatever its limit might be, for any future releases.
*edit*
Well after simply opening up the ul.cfg in a text editor i can see why my game is reported as bad, but still no clue as to why it did this. The game entry for some reason has its game ID removed by USBUtil after a new game is installed. As you can see, the game Alien vs Predator is the only game reported as "BAD", but was working fine before installing another game.
http://psx-scene.com/forums/attachme...1&d=1258210112http://psx-scene.com/forums/attachme...1&d=1258212514
This game worked before, but once i deleted a game labled as bad, this is the one that had its status changed and then WSOD on me, like the others before it.
Since this is the only game like this, i can install more games without any problems of other games being changed. But if i delete this game and re-install it, thats when another game is randomly changed of its status and wont work, resulting in a WSOD in OPS2LD.
So this is my "fix" for the time being to leave this game as is, and all other games will be OK.....i hope. :p
@JNABK:
My advice to you is to get a real hex editor, or at least a text editor with a real hex editing mode (like UltraEdit has). Not only will this allow you to see exactly what has happened to a file, but also to repair it in ways that a pure text editor can't handle. If you had saved the file from that text editor you would probably have destroyed the functionality of every entry in it, as there is no way a normal text editor can deal with all those binary integer bytes.
Also, unlike a normal text editor, a real hex editor often has the ability to do handle files that a normal text editor can't even open. WinHex has no problem whatever searching through a large ISO file and patching some value in it, since it does those things without ever loading the entire file, like a normal text editor would insist on doing.
Sorry if this seems too much like 'advertising', but I just hate seeing someone work with inappropriate and inadequate tools. You lose far too much time from using such methods.
Anyway, with a hex editor you would see that each list entry is just a sequence of 64 bytes where you can then safely cut out the offending entry and resave the rest. This will leave some unused garbage files (the iso parts) but USBUtil should be able to clean those out on the next run by using its 'restore space' command.
Best regards: dlanor
I can vouch for winhex. had to use it to modify a western digital for use with my xbox 360. it is better in most ways than hex workshop.
I know a Tex editor wasnt going to fix anything......lol....but it does make finding things a little easier, rather than going right to the hex editor and trying to figure out what part is wrong section by section. I've used text editor many times and found many problem much quicker by first viewing something with it.
I know i could try fixing the errors with a hex editor, but what good would that do if the cause was uSBUtil and hadnt been fixed, i dont want to have to use a hex editor after each new install if it continued.
Anyway, i spent the day back tracking the installed games by deleting a bad game and re-installing it. What i thought was 'random' turned out to be the previous game installed of the bad one i deleted/reinstalled. So i was able to follow this 'domino' effect all the way back to the original game that started the whole bug incident. Still dont know why, but the original 'bad' game was a 4.75GB DVD that was installed as a 44MB CD and worked, but didnt show this until i realized this was the last game i deleted and reinstalled, but no more errors occured.
So i dont know what to make of this whole 'bug domino' thing, or if if will be reproduced by anyone else, but is certainly a real bug that caused the game to install as bad, then continue on to affect other games.
I.ve also since installed a few more games after checking and re-testing they all work ok, and there have been no more errors with any games now.
@JNABK:
Your experiment proves that the current USBUtil version has a weakness in propagating such errors when there is some malformed/bugged game entry. But hopefully that original malformed/buggy install entry was caused by some other installer or an older version.
Then there is good hope that it will not happen spontaneously again...
@eustolio & ISEKO:
I have also made some experiments and determined the cause of some of my own weird problems, where no error message was given though installations were faulty, missing the new entry in ul.cfg... It turns out that the causes of these problems were in part forgetfulness of myself, but in part a bug in the consistency of defaults for USBUtil, which combines with yet another bug to cause the full problem.
When you start the program, the default destination of installs will be the home folder of the program. But when you have opened an existing game list, then the folder of the opened list becomes the new default destination for installs from ISO files. But the default destination for installs from CD/DVD disc still remains the home folder of the program, and that is the inconsistency bug I mentioned above. Both defaults should be changed to use the directory/folder of the most recently opened game list.
Now if you install games from ISOs, you only have to select the source ISO and enter a game name and then start the process. This will install the new game to the existing game folder and also update the game list in that folder.
And If you install games from CD/DVD discs, and remember to change the destination to be the same as the existing game folder, then these games too will be installed the same way, with the new game files sent to the existing game folder and also updating the list there.
But if you install games from CD/DVD discs, and forget to change the destination to be the same as the existing game folder, after a game list has been opened, then the games will be incorrectly installed, with the game ISO part files being stored in the existing game folder, but with the ul.cfg list update being made in the home folder of the USBUtil program.
Such an erroneous installation ends without any error message, as the program has done both the main tasks, not aware that it did so in two unrelated folders...
This is a definite bug in the program, which should be amended in two ways (though either one of those changes should fix the current problem).
1: When the user opens a game list, the folder/directory of that list should be set as the default destination of both ISO parts files and "ul.cfg" updating both for "Install from ISO" and for "Install from CD/DVD".
2: Whenever a game is being installed, an extra check should be made to ensure that the path of the "ul.cfg" to be updated for that game is the same directory as where the ISO part files of that game were stored.
Best regards: dlanor
Unfortunately all installs were done by USBUtil 2.0 on this particular HDD, as it is my newest drive and i wanted to install many games per session, which this app allows.
Ive learned over the years that some apps dont handle installing in the exact same manner as another, so i try not to use more than one app for the same tasks.
I too have the same problem with 'default' drive as the USBUtil's source/destination folder, but luckily for me i found out by getting an error due to the games file size was more then the folder/drive had space to install it.
So as a result, i now always check the source/destination before committing to any installs.