ps2homebrew
[ISSUE] Game freezing with Samba after a while [SMB]
Hello,
I use OPL from https://github.com/Jay-Jay-OPL/OPL-Daily-Builds, latest version to date. I load games over my home network using Samba Version 4.5.12-Debian on a Linux serveur 4.9.0-4-amd64 1 SMP Debian 4.9.51-1 (2017-09-28) x86_64 GNU/Linux.
I can play games just fine but when I leave the PS2 to idle for a while (45mn-1h), without touching anything, the game will freeze the next time it tries to load something. I tested this with multiple games.
Has anyone experienced this?
Could there be some settings on the Samba side that I need to adjust?
Here is my smb.conf file. Nothing fancy there.
[global]
netbios name = Partage
workgroup = USERS
ntlm auth = Yes
security = user
hosts allow = 192.168.1.
[PS2SMB]
path = /srv/PS2SMB
force user = ps2
hosts allow = 192.168.1.6
read only = No
valid users = ps2
Best,
OPL Daily Builds is a very misleading name. It's a fork of OPL, maintained by @Jay-Jay-OPL. You can report the issue there or at ps2-home.com.
Or you can try the latest OPL beta (download link), and see if the issue is there as well?
The guys over at samba told me to edit my config file. I edited according to what they said. I will report here if I get it working.
I will be sure to try the latest OPL beta, as it looks like there isn't much difference in Jay-Jay's version.
@Antoine-H I have the same "problem". My guess is that the server closes the connection after a while and the PS2 doesn't reconnect. Bad answer but an easy workaround is to not leave your game idle for long periods of time.
@RobertSmits I would guess the same. Yep, it looks like if the PS2 keeps loading stuff, it won't freeze :).
From what I have seen with Wireshark (I'm not an expert) it looks like the server closes the connection 'cause of inactivity. And when you need to load extra stuff the PS2 tries to continue to use the old connection instead of opening a new connection.
Guys, try this experimental workaround: http://www.ps2-home.com/forum/viewtopic.php?f=83&t=1758 -- it's called the PS2-PINGER -- basically your PC that has the SMB shared folder will continuously be pinging the PS2 unit -- in order to avoid freeze ups and etc.
Might be the solution to your issue. Though it's original intent was for a member that perhaps has a malfunctioning home network, or perhaps his home network is too busy doing other things while trying to play PS2 games.
But yes, try not to keep the game in idle for too long. C'mon 45 min to an hour? What the hell do you expect? It be an issue if it were only 2 or 10 mins, but that is not happening here.
Or you could just fix the problem like this sticky says on this post http://psx-scene.com/forums/f150/games-freezing-randomly-when-playing-over-network-104125/#post980499
I am not using Windows. I am actually using Samba on a Linux machine. I will look into setting a lower keepalive value, which should do what you guys described. See https://www.samba.org/samba/docs/using_samba/ch11.html
As of now, there is no code for reconnecting when the connection is lost. The code for establishing the connection is discarded once the connection is made, to save IOP RAM.
It's crazy, that i.e. 348 Byte(!!!) can make 10 games not load via SMB! Well, let's hope that we could have a 're-connention'-support (in-game) AND a bit smaller lib (lwip seems to have a few things, which probably can be removed... The other stuff seems to be quite adapted to the PS2!), so we can enjoy all our games via SMB as well!
This has become an issue in our house as well, where our timeouts appear to be much shorter (games freeze after a couple of minutes if they even load to actual gameplay at all).
We are trying to serve backups using a linux-based Drobo NAS where manual configuration of samba is nontrivial. There is also a gigabit switch and the router interposed but this doesn't cause issues on any other devices. Switching to a windows-hosted share folder isn't a viable solution in our use case.
Some solution to the keepalive problem that lives within OPL on the PS2, without requiring special configuration on the server side, would be ideal if it is possible.
games freeze after a couple of minutes if they even load to actual gameplay at all
What version are you using? I've had similar issues since 19 May, but they where related to slow network speeds, not timeouts. This issue should be fixed in the latest version (1082).
Please take a look at this thread and try the 'dirty-builds'!
--> http://www.ps2-home.com/forum/viewtopic.php?t=1758&view=unread#unread
If it indeed works, I hope you can post a reply here (and possibly on that site as well)!
All pages at ps2-home.com have been coming up dead for me all day long. It has made troubleshooting a pain so far, haha. I'll see what I can pull up from google cache...
Yes, it seems to be down currently. If google-cache doesn't help, maybe that thread recently got backed up on the web-archive.
Or just wait a bit, until it is up again.
Those dirty-builds have an increased ARP-Table-size, so some games might not start anymore (due to limited IOP-RAM). However, the size-increase is less than a KB, so there are probably not many games out of the giant PS2-Game-Library of games, who possibly become incompatible.
No joy on the wayback machine. Apparently ps2-home.com deliberately disabled crawlers (facepalm.jpg).
I'll come and report back my findings once I eventually get on the forums and figure out which build(s) to try. Thanks for the directions so far.
Yes, I've just seen it...
Well...Maybe @Jay-Jay-OPL comes around and can link it here, or the forum hopefully will soon be running again.
The issue however seems to be EXACTLY, what was mentioned/discussed at the end of the thread. I suppose you have more than 2 devices connected?!
Okay I just read the first 70 posts in that thread... Wow. I REALLY wish that forum's server hadn't been dead 18 hours ago when I was first struggling with this. Discussion there is very enlightening, I'm still reading through.
Already I can say I think you're right, ARP table overflow smells like it's the problem here. I can tell you I'm currently using OPL v0.9.3 and I don't know off-hand what APR value was compiled in that version, but yes, at any given moment I'm running between 8 and 30 connected devices in my network at once, so.
This would also explain why it worked flawlessly, longest yet, for an uninterrupted 10 minutes one time only -- right after a hard router reboot, I had the PS2 and NAS configured static, and started the game immediately before other devices had a chance to re-identify and start screaming at each other. And of course, once they did that's when it failed again.
I will test a couple of the 'dirty' builds posted in that forum later today when my girlfriend is done playing PS4 so I can get the TV, and report back.
Okay - @rickgaiser @TnA-Plastic Not going to lie, I kind of feel like I've just emerged from a hurricane of confusing nonsense, but I think I'm 100% up to speed now. Part of the problem is (having no access to ps2-home when it was down yesterday) I was never clear until tonight which of you @Jay-Jay-OPL @ifcaro devs was whom, and who had forked off whose repo, when, or for what reasons (I'm still a little unclear on the last point). It's especially difficult to follow given that Jay Jay seems to have split the discussion topic apart into a half a dozen separate threads for some reason (!?), and that at some point this was a bitbucket repo and not a git repo... Yikes.
So in any event, I deeply apologize if this is the wrong place to even be discussing this, it's not my intent to offend, insult or annoy anyone... Nevertheless, here are my diagnostic results FWIW:
I thought best to do 50/50 on the "dirty" builds from @Jay-Jay-OPL so I ran 1st and 6th (last). For clarity, these are the versions I tested:
"dirty (v1)" OPL_1062_DB-TA-DIRTY_all-03304e0-2018-06-23 "dirty (v6)" OPL_1064_DB-TA-DIRTY_v6_all-7be92c8-2018-07-02
BOTH versions completely and utterly fixed the problem. Totally resolved. We had uninterrupted gameplay on a variety of titles for more than an hour on each version, and in all that time we only saw one minor, tiny instance of very slight stutter on one pre-rendered FMV in one title.
I'm 99% certain the meat of the issue I had before with the official release was the ARP-table flooding problem which is solved in Jay-Jay's "dirty" betas... However just from looking at the betas running in the tests, it's clear there are a lot of other unrelated changes in the codebase between the fork and the parent. If I were to stick with this codebase here, I'd have to apply my own ARP patch equivalent to the one established in the other thread.
So my question has to be, what's the appropriate way for me to proceed? Is this repo still being maintained? Is Jay Jay just doing new beta feature dev, or is his fork more-or-less the only current main dev channel for OPL? Is there some philosophical difference or disagreement keeping pull requests from happening or the ARP patch from being done to the main release?
Please forgive me my ignorance and have mercy in your replies, thanks.
P.S. Just to maintain my sanity I'm about to test the latest official 0.9.3 beta to see whether this issue is resolved.
Yeah on my network it's still fucked on OPL r1082 from the 0.9.3 Betas package.
Okay I found the relevant PR and relevant recent comments and I'm waiting with bated breath. Maybe I should have some tea. #101 Sorry I almost lost my mind, I've been up wrestling with this issue since last night.
The @ifcaro -repo is the original project and you can see which one is the fork, by looking under the 'fork-string', where it mentions, where it is forked from.
Ifcaro does not have this... Ergo --> The official project.
You can also take a look at the Readme of both forks!
Yes, it (ifcaro-repo) was a bitbucket-repo a while ago!
Yes, he (@Jay-Jay-OPL) probably splitted it to keep the topics a bit more structured. He however ever references to the new threads, so they are still connected to each other and those who are interested in it, should still find all informations easily. ;)
The reasons for the Jay-Jay-OPL-fork are, that he wanted to implement some things (other visuals a tighter integration of POPStarter and some other things) and some of his ideas just do not match either some developers wishes (especially in POPStarter's and OPL's case) or the 'idea of implementation' it should have (i.e. the second Apps-Page is programmed in a VERY REDUNDANT way... It is doubled code, which is one of the main-things you should avoid in a program!!! Avoiding redundancy belongs to the 10...naaahh...4 basic rules of development/programming!)
The place is alright, but it might/would be appreciated if you don't post 4 replies, but rather less (at least within ~24hours). You can edit your comments as well! ;)
Allllllllright! So that fixed your problem! That's great to know, indeed! THX for your confirmation! I think we have ~4-5 Testers now, so I think this issue (not only THAT, but WHY the ARP-Table still overflows, or why it 'kicks out' the ARP-Entry of the connection we need to have [to the SMB-Server/PC/NAS/etc.] in the first place) can be tracked down quite fast.
Btw.: Might it be possible to just 'keep' the ARP-Entry to the desired SMB-Host/Server and ignore any further incoming ARPs for other devices, once 'in-game'...? Then we would not even need to increase the ARP-Table-size.
BOTH repositories are still under continuous maintenance! Look at the number of forks and sub-branches (I am referring to all branches of all forks of OPL here) the ifcaro-repo has! ;) You can BET on it, that there will be new releases for a while as well!
The Jay-Jay-OPL-fork is also continuously maintained! All ifcaro-fork-patches/updates get included! It is developed in conjunction with 'OPL Manager' (by @danielb ), which supports both repos and the/some additional features of OPL-DB (OPL 'Daily Builds' is the Jay-Jay-OPL-fork).
Well, the guys on the ifcaro-fork/branch/... rather want to be consistent in properly coding the features... The OPL-DB focuses more on features, even if the code might not be as good or still 'WIP'. Increasing the ARP-Table just seems like a workaround, to just not trigger the bug. However... It would still be present and the guys here on the ifcaro-repo want a proper implementation, which includes fixing a bug rather than working around it!
If there is no better way to fix it, then this probably will be adapted!
Thanks, that's very helpful and you've given me everything I need to learn more. I appreciate it! @TnA-Plastic
Now that a related patch has been suggested, tested and merged, I recommend that this issue ticket be closed if there are no further comments.
I have just tried with OPL available from https://akuhak.github.io/test_build/ (build time: 2018-07-18_12:09:23 commit: 45c9a78) and I still experience the same problem.
I am using Samba version 4.5.12-Debian and my /etc/samba/smb.conf file hasn't changed since my first post.
To test it out, I launched a game, then died, then waited on the screen that offers to try again for like an hour. When I hit the try again button, I was able to play once then it froze.
@sp193 Thank you very much for the patch you provided. Could you explain how you tested it? I'll see if I can reproduce the steps :). Maybe something else is wrong with my setup. I can provide you with some Samba logs if you want.
I only just tried to see if it booted any games. I came, I heard and I found problems that were not addressed. But they might not have been the only problems with the system.
I heard that the Samba users were also having issues with the Samba server closing the connection after a period of inactivity. That will kill the connection permanently because the in-game driver cannot ever reconnect. For this issue, it is an exercise for the OPL developer(s) to solve. :')
I have just tried setting deadtime = 0 in Samba so that it wouldn't close the connection (if I understood correctly), then waited for some time and it freezes again.
@sp193 All right. Thanks again :).