webMAN-MOD
webMAN-MOD copied to clipboard
aldostools
"Corrupted Data" every game ps3netsrv / UnRaid issue
I'm kinda at a loss as to what remedies I can try and how I can provide a log dump to better debug this issue...
All my games are stored in folder format and not .iso and ps3netsrv was working mostly fine for a large % of the games I have. However, recently every last game I try (even previously working games) to launch via webMAN results in the game being mounted and showing as "Corrupted Data" in the XMB. When I copy the folder to the internal hdd, the game launches fine...
This happens on both PS3's (slim & phat) running the same CFW listed below.
webMAN-MOD: 1.47.27 ps3netsrv build: 20170310 CFW: REBUG 4.86.1 Ubuntu 18.04
I too have this issue. I'm not sure when it first arose but I've been keeping up with the latest REBUG releases and latest webMAN-MOD releases and at some point in the past year or so the folder format games being served by ps3netsrv have all started failing with the "Corrupted Data" indication in the the XMB. Doesn't matter if I mount via webMAN-MOD or mmCM - always results in "Corrupted Data".
Most of my games are in ISO format and still working just fine so I didn't notice the problem until a couple of months ago. I've verified that the games in question do work properly when being played from the internal drive on the console. I've also tried converting a couple of the folder format games to ISO format which results in them working fine via ps3netsrv.
Today I to tried to resolve this issue by completely removing webMAN-MOD and mmCM from my system and reinstalling each of them. The resulting behavior was the same - "Corrupted Data" for folder format games whether mounted via webMAN-MOD or mmCM. Except now I've also run into the problems described in issue #328 and ISO files (PS3ISO, PSXISO) are not scanned if there are any items within the GAMES folder.
webMAN-MOD: 1.47.27 ps3netsrv build: 20190630 (via Shawly's Docker container - not sure how to get latest build) CFW: REBUG 4.86.1 LITE PS3 Model: slim
@GreedyCop I just updated my Docker image to version 20200520, might wanna try again.
Hey @shawly Thanks for the updated Docker image; and thanks for the response! If you weren't aware, a user called bashNinja has very recently added the image to the UnRAID Community Applications repository, which will make it much more accessible for many users.
I installed the updated image but the 20200520 build of ps3netsrv did not fix the "Corrupted Data" issue we've been facing while mounting folder-format games over the network. The good news is that after upgrading, my problem relating to issue #328 has been resolved, and all folders are scanned as expected once again.
Let me know if there is any other software combination that you'd like me to test out and I'd be happy to try and help isolate the problem.
EDIT: Just read your posts on the page for your docker container. I agree that this may indeed be an issue specifically between REBUG 4.86.1 and ps3netsrv. If nobody else is willing to test it out I may be able to try a different CFW to verify. Probably will be at least a few days before I can get to that though.
Hey @shawly Thanks for the updated Docker image; and thanks for the response! If you weren't aware, a user called bashNinja has very recently added the image to the UnRAID Community Applications repository, which will make it much more accessible for many users.
Oh cool, didn't know that, thanks for the heads up! This means I shouldn't push any breaking changes anymore like last time where I stupidly changed the whole Dockerfile which screwed up permissions.
I will fire up my PS3 right now, it's below 4.86 so if it's a firmware related issue, then it should technically work without any problems for me.
Edit: Alright, so I just fired up my system and mounted games and they started without any issue, though I'm still on REBUG 4.81.2 which may be why it works.
Edit: Updated to REBUG 4.84.2 and it's still working for me, I also just updated my Docker image to 20200521 btw. @BenDaMAN303 downgraded to 4.84.2 as well but he didn't have any success, so maybe this is UnRAID related?
Since I got nothing better to do with my quarantine time, I guess I'll setup an UnRAID guest on my ESXi and try this out as well.
Alrighty, I finally got UnRAID to work in a virtualized environment, installed the ps3netsrv moved a single game over and mounted it. And to my surprise, it's corrupted.
So now we definitely know that it seems to be an UnRAID related issue and definitely not a firmware related issue. Next thing to figure out is why this happens.
Edit: Now look at this: https://imgur.com/a/P2Ob91E Seems like the PS3_GAME folder is somehow seen as file or being reported as file by ps3netsrv under UnRAID, interesting. Maybe it has something to do with permissions or it's related to the XFS filesystem. I'll test some more, I think I can figure this out. Ok the PS3_GAME folder is reported as folder by ps3netsrv when browsing through the file manager, so this behavior only happens when the game is actually mounted.
Edit2: Alright at last I found the cause for the issue, the problem seems to lie in UnRAIDs mounting behavior as it merges the contents of multiple disks into one mount under /mnt/user, when mounting the game it seems ps3netsrv can't or won't distinguish between files & folders anymore.
Edit3: I also found a workaround for now, I set the Split level of my ps3 share to Manual so it won't split the game folder over multiple disks, then I moved all game files from disk2 to disk1 as well. After that my game didn't show as corrupted and I could successfully start it without any issues. I will play with the split levels around and see which level is safe enough.
Edit4: For now you guys have to make sure that your game folder files are located on a single disk, it's no problem to have two games on two disks, but it's important that the files are not split between the disks.
Edit5: Ok so I played around with split levels a bit, but according to the description and assuming we got a specific share for ps3 with the GAMES folder as first level subdirectory, split level 1 (Automatically split only the top level directory as required) seems to be safe to set.
So the exact workaround is to create a share in UnRAID with a split level set to 1 or manual, that way UnRAID will create a game folder per game per disk ensuring that the folders are not split so ps3netsrv or rather the PS3 itself won't have any issues reading that folder.
Effectively I cannot provide any fix for this behavior as it's ps3netsrv + UnRAID specific and not related to my Docker image. Maybe @aldostools wants to take a look at this, but with the workaround I wouldn't see it as high priority, as setting the split level to 1 doesn't really have a downside (at least none that I can think of).
@shawly Wow! You are awesome. I would never have expected this issue to be related to UnRAID. Thank you so much for taking the time to test it out. I suppose I should have gone ahead and tested ps3netsrv on my desktop machine to try and rule out any weird filesystem issues. This is a very workable workaround for me but I probably do not have time to fiddle with it today. Once I fix my PS3 share I will report back to verify your findings.
Hopefully we hear something back from @anpaulin to determine whether their issue is caused by the same.
Thanks again!
Some more research. This works for everything from UnRAID from 6.7.2 and lower. Version 6.8.0 and up have this problem.
I have also tested the binary directly on the UnRAID server. The issue still occurs. This is not an issue with @shawly's container.
It's something with Unraid and webMAN-MOD
A little more. When running directly on the Unraid Server (no docker) and trying to download a file over FTP after mounting, this is the output I get:
root@Tower:~# ./ps3netsrv_linuxX86_64 /mnt/user/games/
ps3netsrv build 20200520 (mod by aldostools)
Path: /mnt/user/games
Waiting for client...
[0] Connection from 192.168.0.12
building virtual iso...
open /GAMES/BLUS31606
VISO: read_file failed on /mnt/user/games/GAMES/BLUS31606/PS3_GAME
Unfortunately it seems I'm facing a different issue than @GreedyCop. I'm running a dead simple setup of an external NTFS drive and a Ubuntu desktop. I'm not running @shawly 's docker image... Just tried again and I seem to be facing the same "Corrupted Data" issue...
Edit: I can confirm that webMAN-MOD is seeing my PS3_GAME folders as folders and not files as @shawly was describing above.
Effectively I cannot provide any fix for this behavior as it's ps3netsrv + UnRAID specific and not related to my Docker image. Maybe @aldostools wants to take a look at this, but with the workaround I wouldn't see it as high priority, as setting the split level to 1 doesn't really have a downside (at least none that I can think of).
One of the recent feature of ps3netsrv allows to merge multiple paths in a single folder without have to use external tools. Just create an INI file with the name of the folder, and list the paths that you want listed in that folder (one path per line). e.g. ./PS3ISO.INI
The build 20200520 is still being used. A more recent commit is available for 20200521: https://github.com/aldostools/webMAN-MOD/commit/24834d84049304e561a1aafc2636a77e679c4756
Also have this test build that is newer: https://github.com/aldostools/webMAN-MOD/files/4672013/ps3netsrv_20200523.zip
I tested them using Cygwin 3.1.4 and gcc 9.3 on Windows 10. Cygwin provides functionality similar to a Linux distribution on Windows.
If the problem persists with these builds, a possible workaround is to replace VisoFile.c/VisoFile.h with the original files from one of these archives: https://github.com/aldostools/webMAN-MOD/blob/master/Projects/ps3netsrv/bins/old/ps3netsrv-src-deank.7z https://github.com/aldostools/webMAN-MOD/blob/master/Projects/ps3netsrv/bins/old/ps3netsrv-src-cobra.7z
Here's the latest build, same issue:
root@Tower:~# ./ps3netsrv /mnt/user/games/
ps3netsrv build 20200523 (mod by aldostools)
Path: /mnt/user/games
Server IP #1: 198.168.0.16:38008
Server IP #2: 172.17.0.1:38008
Server IP #3: 192.168.122.1:38008
Waiting for client...
[0] Connection from 198.168.0.12
open dir /mnt/user/games/GAMES
building virtual iso...
open /GAMES/BLUS31606
VISO: read on file /mnt/user/games/GAMES/BLUS31606/PS3_GAME returned less data than expected (file modified?)
Here it is with the old VisoFile.c/VisoFile.h pulled from ps3netsrv-src-deank.7z
root@Tower:~# ./ps3netsrv-old /mnt/user/games/
ps3netsrv build 20200523 (mod by aldostools)
Path: /mnt/user/games
Server IP #1: 198.168.0.16:38008
Server IP #2: 172.17.0.1:38008
Server IP #3: 192.168.122.1:38008
Waiting for client...
[0] Connection from 198.168.0.12
building virtual iso...
open /GAMES/BLUS31606
VISO: read_file failed on /mnt/user/games/GAMES/BLUS31606/PS3_GAME
VISO is saying it's trying to do read_file on the folder PS3_GAME.
The merge feature is interesting, but won't work very well with unraid. You never really know which disk it's saved on so you don't have the path. The short story is, it'll be quite hard to know the path of the files (and docker probably won't have access to them).
Thanks @shawly for your time and work on this. I really appreciate it!!
I have messaged bashNinja on the unraid forums. I have asked them to add a note to the template overview, explaining that split level 1 (Automatically split only the top level directory as required) should be used for the ps3netsrv share. I would imagine that most people using unraid will be adding it to their server using his template, so hopefully that will help out others.
@BenDaMAN303 That's actually me. I don't really think that creating a unique share for ps3netsrv and using specific split levels is a real solution. There's something going on here and I'm trying to get to the root cause.
As I've been digging into it, scandir( isn't reporting any directories back. I'm not sure why, still trying to figure that out.
Some more research. This works for everything from UnRAID from 6.7.2 and lower. Version 6.8.0 and up have this problem.
That's good to know. They updated the shfs with UnRAID 6.8.0, (Release Notes)
User Share File System (shfs) changes:
- Integrated FUSE-3 - This should increase the performance of the User Share File System.
- Fixed a bug with hard link support. Previously a 'stat' on two directory entries referring to the same file would return different i-node numbers, thus making it look like two independent files. This has been fixed, however there is a config setting on Settings/Global Share Settings called "Tunable (support hard links)". The default is Yes, but with certain very old media and DVD players which access shares via NFS, you may need to set this to No.
- Note: if you have custom config/extra.cfg file, get rid of any lines specifying additional FUSE options unless you know they are compatible with FUSE-3.
So I guess this change is causing issues here.
It says that they upgraded to FUSE-3 and NTFS-3G is also using FUSE, so might there be any correlation between the latest FUSE library since @anpaulin also has issues with an external NTFS drive?
Ok, after some more digging, I found a weird issue with select_directories in VIsoFile.cpp
https://github.com/aldostools/webMAN-MOD/blob/master/Projects/ps3netsrv/src/VIsoFile.cpp#L422-L425
On the old versions of UnRaid, it returns with DT_DIR and works great.
On UnRaid 6.8.0 and higher, it returns DT_UNKNOWN, which is super weird.
This is for both files & directories.
I added this little logging to select_directories:
printf("select_directories path: %s, ", entry->d_name);
switch(entry->d_type) {
case DT_DIR:
printf("d_type: DT_DIR\n");
break;
case DT_UNKNOWN:
printf("d_type: DT_UNKNOWN\n");
break;
case DT_LNK:
printf("d_type: DT_LNK\n");
break;
case DT_FIFO:
printf("d_type: DT_FIFO\n");
break;
case DT_REG:
printf("d_type: DT_REG\n");
break;
default:
printf("d_type: other\n");
}
UnRaid 6.7.2 (good) returns:
select_directories path: ., d_type: DT_DIR
select_directories path: .., d_type: DT_DIR
select_directories path: PS3_DISC.SFB, d_type: DT_REG
select_directories path: PS3_GAME, d_type: DT_DIR
select_directories path: PS3_UPDATE, d_type: DT_DIR
UnRaid 6.8.0 (bad) returns:
select_directories path: ., d_type: DT_UNKNOWN
select_directories path: .., d_type: DT_UNKNOWN
select_directories path: PS3_DISC.SFB, d_type: DT_UNKNOWN
select_directories path: PS3_GAME, d_type: DT_UNKNOWN
select_directories path: PS3_UPDATE, d_type: DT_UNKNOWN
The manpage for dirent says:
DT_UNKNOWN The type is unknown. Only some filesystems have full support to return the type of the file, others might always return this value.
I'm going to take this to the UnRAID Devs and see what's up.
Here's a link to my bug report topic with UnRAID: https://forums.unraid.net/bug-reports/stable-releases/680-to-683-scandir-d_type-and-stat-errors-r942/
I created small .cpp files that make this easily re-createable:
https://gist.github.com/miketweaver/92c61293f16ef3016f9a57472fff1ff3
@anpaulin
Can you compile those .cpp files and see if you get the same error I described in the UnRAID bug report? That would let us know if your NTFS mount is having the same issue. Make sure to edit the .cpp files to have the path to one of your games.
g++ stat.cpp -o stat.o
g++ scandir.cpp -o scandir.o
./stat.o
./scandir.o
Not sure how helpful this info will be, but I just spent some time fiddling with the PS3 share on my UnRAID server. It seems that the workaround that @shawly mentioned above did not resolve the issue for me. I've tried setting split level 1 and split level manual before copying a game to the share - verified that the entire game folder resides on a single drive, but I still get "Corrupted Data" on XMB. Also the PS3_GAME folder in /dev_bdvd appears as a file, just like the image in that imgur link.
I'm on UnRAID 6.8.3
Setting split level 1 & split level manual also didn't work for me. I have verified that the entire game folder is on a single drive. I ended up rolling back to UnRAID 6.7.2 in order to get it working for now.
Has @miketweaver or any others seen the response from unraid devs here: https://forums.unraid.net/bug-reports/stable-releases/680-to-683-scandir-d_type-and-stat-errors-r942/?do=findComment&comment=10544
Is there any avenue for a solution here?
For those of you who changed the split level setting and it isn't working is probably because you changed that setting with a share with data (or games) already inside. Changing the split level setting doesn't move the files in any way, it only change the way the files are split from that point on. A way to fix it is to change your split level then ssh your unraid server and move all your games to the same disk. Finally in the docker change /mnt/user/yourShare to /mnt/diskX/yourShare and you should be good to go.
@VinnyVynce Thanks for dropping in and adding this.
That's what I ended up doing as well. Although It's not ideal for people who have ps3 collections too large to fit on a single drive in their array. With 8TB drives in my array, that hasn't been an issue for me.
I actually wouldn't recommend using the split level setting for a ps3netsrv docker share, since even setting a split level 1 could still lead to games being spread across multiple disks in the array. See here for more info: https://wiki.unraid.net/Un-Official_UnRAID_Manual#Split_Level_.3D_1_Example
Instead, I would recommend setting the "Included disk(s):" setting for the share, to just a single disk in the array. Then referencing that disk using /mnt/diskX/yourShare as you suggested. Data may still need to be moved around as you pointed out.
Although It's not ideal for people who have ps3 collections too large to fit on a single drive in their array. With 8TB drives in my array, that hasn't been an issue for me.
One could just create two or more instances of ps3netsrv on different ports and add multiple servers to WebMAN-MOD, that way one can have multiple shares for ps3 games in UnRAID if the disks are too small for big collections. Though I find it quite strange that the UnRAID devs disregard this issue completely even though it worked with previous versions.
The unraid devs have come back and said it was an issue with the programming and not their problem. You can read their response here: https://forums.unraid.net/bug-reports/stable-releases/680-to-683-scandir-d_type-and-stat-errors-r942/
I currently don't have the will to look at this anymore.
LOL It's an easy to close the issue without offer a real solution.
Here is a test build that checks the entries in scandir.c that return d_type == DT_UNKNOWN ps3netsrv_test.zip
I think the code could be improved...
Since I got some time on my hands I just went and created a new docker image with your test archive.
Though sadly, this change didn't help and the mounted games are still shown as "Corrupted Data", so the suggested change from the UnRAID devs didn't help at all as it seems.
If anyone stumbles into this, I got it working in unraid 6.9.2, to do this use the 'unassigned devices' plugin to share a disk that is not in your array.
Thank you @bshep for your feedback.
It would be very cool if you could post a screenshot of the settings that made it work. Thanks again.
Thank you @bshep for your feedback.
It would be very cool if you could post a screenshot of the settings that made it work. Thanks again.
-
Go to 'Apps' tab and search for 'unassigned devices' install the plugin.
-
Connect a new hard drive to unraid ( it must be a drive not assigned to your array )
-
Then go to your 'Main' tab and you will see the following (drive names will be different):
-
You would click on 'Format' and select a filesystem ( it doesnt matter which one its internal to unraid and not seen by the ps3, i chose xfs ), click next, type 'Yes' (case must be exact, capital Y), click next
-
Click the name of the volume, in this photo i have formatted Dev1 and its been given a label of 'WD-WCC7K5RDFPJ1', change it to whatever you wish. If you see Dev 2 i have name it PS3BACKUPS
-
Click on the blue gear icon to the right of the name and turn on 'Share'
-
go to the docker settings and set your games folder to: /mnt/disks/PS3BACKUPS/ ( or whatever you named the mount point)
That it, it should work like a regular share on the network. Just be aware this drive is NOT part of the array so it is not backed up