The above video goes away if you are a member and logged in, so log in now!
Wire shark for r359 random stuter Dark Aliance
Wire shark for r359 random stuter Dark Aliance –
Don't know if this will help fix the problem but created a mini wireshark of SLUS_200.35.dark alliance.iso stuttering.
Smb mode windows xp
Last edited by RandQalan; 09-14-2010 at 04:55 AM.
This is not the kind of result I get myself, and I have lots of games installed just by storing their ISO files in the "CD" or "DVD" subfolders of my "PS2SMB" fileshare. And my SMB game listing includes games of all three kinds. (The "CD" folder, the "DVD" folder, and the games in USBA-format in the main fileshare folder.)
Originally Posted by bateleve
I wonder if your problem is somehow related to not using the proper form of the ISO filenames. You should realize that you can't just put games in those folders using whatever filenames you'd use outside an OPL installation. Each of the files MUST have a prefix string in the same format as the game product code, as used for the filename of the boot elf of that game disc.
For example, here are some of the names I use in my own CD and DVD subfolders.
SLES_524.58.+NI Disgaea 1 (Eu) CD ISO.iso
SCUS_974.90.Rouge Galaxy (US) DL.ISO
SLPM_667.50.+Sq FF12 Eng ZJS v0.18.iso
SLUS_204.69.Xenosaga Ep1 DWZM (US) DL.ISO
In each of these filenames the first 12 characters are MANDATORY. If the string does not have that format, then the ISO file is not accepted as valid, and if any of the first 11 characters in that string do not match the boot elf of the game, then any attempt to launch this game will crash. The final four characters are of course also required for recognition of an ISO file, and the characters in between are simply what will be used for the game title in the game listing of OPL.
Possibly you already use correct ISO filenames, but since you gave no examples at all, I had to mention this possibility.
That certainly looks odd, with "failed sanity" and negative space etc, but I can't evaluate what that really means.
Samba log displays the following error:
[2010/06/25 20:40:42.322497, 1] smbd/service.c:1069(make_connection_snum)
192.168.100.110 (192.168.100.110) connect to service PS2SMB initially as user www-data (uid=33, gid=33) (pid 812)
[2010/06/25 20:40:42.353113, 0] smbd/trans2.c:813(send_trans2_replies)
send_trans2_replies failed sanity useable_space = -62!!!192.168.100.110 (192.168.100.110) closed connection to service PS2SMB
[2010/06/25 20:40:42.368446, 1] smbd/server.c:267(remove_child_pid)
Scheduled cleanup of brl and lock database after unclean shutdown
I suppose this could have some other way of dealing with fileshare subfolders, but to my knowledge Jimmi himself uses Linux in all his own testing, so that shouldn't be a problem, unless it is something unique to your Linux dialect or even your specific setup.
I'm using a WD MyBook WII NAS running Linux.
Best regards: dlanor
@dlanor. Thanks for replying.
I also have USBA-format files and was trying to test some CD and DVD ISO files.
You're right, I forgot to paste some filename examples into my post - sorry for that . I named them accordingly to an explanation you gave to another member a few days ago and that you kindly repeated in your response. One of the files is SLUS_200.66.(ISO) Half-Life.iso
My latest test was done with this file and only with the CD folder and the pre-existing USBA-format games.
I had a few problems setting up this NAS to work with OPL and specially with SMS, which I solved by hacking it and upgrading SAMBA to the latest version available at the time, which was the 3.5.2. After setting up SAMBA and add/modify a few parameters all has been working well ever since. I wonder if there is a need to add/modify some parameters...
Here is an excerpt of my smb.conf file:
socket options = TCP_NODELAY IPTOS_LOWDELAY
#read raw = No *** SMS HANGS!!! ***
use sendfile = Yes
deadtime = 15
getwd cache = Yes
max xmit = 131072
keepalive = 0
locking = No
I'll look if there are other parameters that could cause the error.
Meanwhile, any help would be appreciated.
I looked at samba server code and found it had to do with "max xmit" parameter. After I commented that line in smb.conf it begun to work! Everywhere in the web everybody suggests assigning this parameter to the maximum possible value, for performance reasons, but I guess in this case it is better to leave it with the default value.
Originally Posted by bateleve
I'll try to test some more games (and also SMS...) in the weekend.
Thank you again.
Been running some tests on r359 for a few hours and I've come across some great improvements. Red Dead Revolver (SLUS_205.00) via SMB had no audio during cut scenes before but now works and Rumble Racing (SLUS_201.74) via HDD is finally working.
But I did come across a problem with the SingStar games via HDD. I tried Amped (SCUS_976.11), Pop 2 (SCUS_976.27), and 90s (SCUS_976.26) and they all end up the same way. When you go to the song selection, it immediately prompts me to "Please insert a SingStar disc." All games worked fine with OPL v0.7 so I went back and tested some of the other revisions I've compiled. Now I haven't compiled each and every revision but the last rev that these games worked fine on was r340. The next rev that I was able to compile was r347 and this problem occurred in that one too.
I haven't tried all possible compatibility mode combinations yet but just thought I'd mention this in case it was something that couldn't be fixed via compatibility modes. Of course I will edit this post if I make any progress.
i have done everything step by step defrag usb and files coverted the usb to fat32 used usblt 2.0 to convert the isos for usb use.
This has probably been considered and discarded somewhere, but i didn't see it so i just thought i would offer an idea...
With the new .iso reading and having to rename and such, how difficult would it be to use a file similar to the ul.cfg in function, that would identify for OPL what games were in the directory/s and build the game list that way? Possibly even remove the need to rename all one's iso files in the process? Since the file structure of the iso files isn't being changed, perhaps configure the "smbiso.cfg" (just something to call it, not saying that should be the name) like
FILEPATH: "smbsharedir/game1.iso =SLUS.xxx.xx" NAME: "game1"
FILEPATH: "smbsharedir/game2.iso =SLUS.xxx.xx" NAME: "game2"
That's just an example, I am sure someone more familiar with just how OPL queries the SMB fileshare could come up with something much more elegant.
That might even make possible making a simple PC-side app similar to usbutil that you can load an iso file or even a directory with iso files in it, have it pull the game id from each and build the cfg file accordingly.
Might be worth looking at anyways.
Thank you for reporting it, r360 should fix again those games requiring disc to be inserted.
Originally Posted by sk8rping
One of the advantages of using directly the iso filenames instead of ul.cfg, is that you are not dependant of it. How many desperate people came to the forum asking how to rebuild a corrupted ul.cfg, and how many just re-formated and re-installed every games ...
Originally Posted by aginor37
Without this dependency, you remove a source of stress
Now, for the renaming of the files, "iso2opl" have been modified to automatically rename your iso file in the correct format. Run it from your CD/DVD folder with the single parameter "SCAN"
> cd PS2SMB
> iso2opl SCAN
./SLES_537.7./SLES_533.45.Shadow of the Colossus.iso seems to be correctly named
./POP - The Two Thrones.iso renamed to: ./SLES_537.77.POP - The Two Thrones.iso
I am strongly opposed to any requirement that the user must list ISO files in any file at all.
Originally Posted by aginor37
The main point of this kind of game installation, is that the installed state of each such game relies ONLY on the presence of a properly named ISO file in its proper folder.
As soon as any collective list file is introduced, this raises the possibility of conflicting usage, with listed contents not matching ISO files present. And to no good purpose. This new dependency would not bring ANY new benefits at all.
Because I do not see the removal of the product ID string from the ISO filenames as a benefit...
In fact I think it would be a serious mistake to remove that requirement, as it is always a good thing to have game ISOs that are positively and uniquely identified.
I didn't see your post before making this one, or I might have skipped it, since you say partly the same things I did, though differently phrased. I definitely agree with you on this issue.
Best regards: dlanor