[Problem] Unable to scan for copy protection on UDF disc with Linux MPF.Check #664

Closed
opened 2026-01-29 16:20:15 +00:00 by claunia · 8 comments
Owner

Originally created by @JohnVeness on GitHub (Jan 2, 2024).

Originally assigned to: @mnadareski on GitHub.

Version
What version are you using?

  • Stable release (version 3.0.3)
  • WIP release (version here)

Build
What runtime version are you using?

  • .NET 6.0 running on (Linux, openSUSE Tumbleweed)
  • .NET 8.0 running on (Linux, openSUSE Tumbleweed)
    (I tried both)

Describe the issue
I'm not sure if this is a bug or that I'm using it wrong, but here we go!

I can't seem to be able to scan for copy protection using the Linux version of MPF.Check.

To Reproduce
Steps to reproduce the behavior:

  1. Dump a disc, e.g. http://redump.org/disc/32401 with redumper
  2. MPF.Check dvdrom pc -s -p /dev/sg0 -u redumper dump_231231_212910_sg0.iso

Observed behavior (in Linux version)

Extracting output information from output files...
Running copy protection scan... this might take a while!
0.00%: /dev/sg0 - Checking file
0.00%:  - 
100.00%: /dev/sg0 - 
Copy protection scan complete!
Extracting information complete!
Processing site codes...
Formatting information...
Processing complete!
Formatting complete!
Writing information to !submissionInfo.txt...
Writing complete!
Submission information process complete!

It goes from 0% to 100% instantly.

Expected behavior (in Windows)
MPF.Check dvdrom pc -s -p d: -u redumper dump_231231_212910_sg0.iso

(Had to attach as too long).
mpf.txt

Additional context
I realise this is likely a BinaryObjectScanner problem, but at the moment I'm not even sure I've got the right syntax for the MPF.Check command.

I've tried with sudo with no difference.

I've tried to pass, instead of /dev/sg0, a folder pointing to the mounted disc, e.g. MPF.Check dvdrom pc -s -p /run/media/john/FM2012 -u redumper dump_231231_212910_sg0.iso. This just outputs:

Extracting output information from output files...
Running copy protection scan... this might take a while!
0.00%:  -

and never progresses, with MPF.Check using 100% CPU.

Any ideas?

Originally created by @JohnVeness on GitHub (Jan 2, 2024). Originally assigned to: @mnadareski on GitHub. **Version** What version are you using? - [x] Stable release (version 3.0.3) - [ ] WIP release (version here) **Build** What runtime version are you using? - [x] .NET 6.0 running on (Linux, openSUSE Tumbleweed) - [x] .NET 8.0 running on (Linux, openSUSE Tumbleweed) (I tried both) **Describe the issue** I'm not sure if this is a bug or that I'm using it wrong, but here we go! I can't seem to be able to scan for copy protection using the Linux version of MPF.Check. **To Reproduce** Steps to reproduce the behavior: 1. Dump a disc, e.g. http://redump.org/disc/32401 with redumper 2. ```MPF.Check dvdrom pc -s -p /dev/sg0 -u redumper dump_231231_212910_sg0.iso``` **Observed behavior (in Linux version)** ```Gathering submission information... please wait! Extracting output information from output files... Running copy protection scan... this might take a while! 0.00%: /dev/sg0 - Checking file 0.00%: - 100.00%: /dev/sg0 - Copy protection scan complete! Extracting information complete! Processing site codes... Formatting information... Processing complete! Formatting complete! Writing information to !submissionInfo.txt... Writing complete! Submission information process complete! ``` It goes from 0% to 100% instantly. **Expected behavior (in Windows)** ```MPF.Check dvdrom pc -s -p d: -u redumper dump_231231_212910_sg0.iso``` (Had to attach as too long). [mpf.txt](https://github.com/SabreTools/MPF/files/13812533/mpf.txt) **Additional context** I realise this is likely a BinaryObjectScanner problem, but at the moment I'm not even sure I've got the right syntax for the MPF.Check command. I've tried with sudo with no difference. I've tried to pass, instead of /dev/sg0, a folder pointing to the mounted disc, e.g. ```MPF.Check dvdrom pc -s -p /run/media/john/FM2012 -u redumper dump_231231_212910_sg0.iso```. This just outputs: ```Gathering submission information... please wait! Extracting output information from output files... Running copy protection scan... this might take a while! 0.00%: - ``` and never progresses, with MPF.Check using 100% CPU. Any ideas?
claunia added the bug label 2026-01-29 16:20:15 +00:00
Author
Owner

@JohnVeness commented on GitHub (Jan 2, 2024):

After some more investigation, if I copy all the files from the DVD into a subfolder in my home folder (on an SSD), then do MPF.Check dvdrom pc -s -p /home/john/FM2012 -u redumper dump_231231_212910_sg0.iso, the protection scan proceeds as expected, e.g. like:

Gathering submission information... please wait!
Extracting output information from output files...
Running copy protection scan... this might take a while!
0.00%:  - 
0.00%: /home/john/FM2012/autorun.inf - Checking file
0.92%: /home/john/FM2012/background.png - Checking file
0.92%: /home/john/FM2012/autorun.inf - 
1.83%: /home/john/FM2012/background.png - 
1.83%: /home/john/FM2012/click.wav - Checking file
2.75%: /home/john/FM2012/click.wav - 
2.75%: /home/john/FM2012/FM_readme_Danish.txt - Checking file
3.67%: /home/john/FM2012/FM_readme_Dutch.txt - Checking file
3.67%: /home/john/FM2012/FM_readme_Danish.txt - 
4.59%: /home/john/FM2012/FM_readme_Dutch.txt - 
4.59%: /home/john/FM2012/FM_readme_English.txt - Checking file

etc.

This leads me to believe that -p is intended to point to a folder full of files, not the optical drive block device.

Also, mounting the dumped ISO and doing e.g. MPF.Check dvdrom pc -s -p /home/john/virtual-drives/1/ -u redumper dump_231231_212910_sg0.iso also works fine.

So the remaining problem is trying to run MPF.Check -s -p and passing the folder name of the "normal" mounted optical disc, the /run/media/etc folder I mentioned earlier, which appears to start at 0.00%, but hang there. I can't work out what would be different in that case.

@JohnVeness commented on GitHub (Jan 2, 2024): After some more investigation, if I copy all the files from the DVD into a subfolder in my home folder (on an SSD), then do ```MPF.Check dvdrom pc -s -p /home/john/FM2012 -u redumper dump_231231_212910_sg0.iso```, the protection scan proceeds as expected, e.g. like: ``` Gathering submission information... please wait! Extracting output information from output files... Running copy protection scan... this might take a while! 0.00%: - 0.00%: /home/john/FM2012/autorun.inf - Checking file 0.92%: /home/john/FM2012/background.png - Checking file 0.92%: /home/john/FM2012/autorun.inf - 1.83%: /home/john/FM2012/background.png - 1.83%: /home/john/FM2012/click.wav - Checking file 2.75%: /home/john/FM2012/click.wav - 2.75%: /home/john/FM2012/FM_readme_Danish.txt - Checking file 3.67%: /home/john/FM2012/FM_readme_Dutch.txt - Checking file 3.67%: /home/john/FM2012/FM_readme_Danish.txt - 4.59%: /home/john/FM2012/FM_readme_Dutch.txt - 4.59%: /home/john/FM2012/FM_readme_English.txt - Checking file ``` etc. This leads me to believe that ```-p``` is intended to point to a folder full of files, not the optical drive block device. Also, mounting the dumped ISO and doing e.g. ```MPF.Check dvdrom pc -s -p /home/john/virtual-drives/1/ -u redumper dump_231231_212910_sg0.iso``` also works fine. So the remaining problem is trying to run ```MPF.Check -s -p``` and passing the folder name of the "normal" mounted optical disc, the /run/media/etc folder I mentioned earlier, which appears to start at 0.00%, but hang there. I can't work out what would be different in that case.
Author
Owner

@JohnVeness commented on GitHub (Jan 3, 2024):

I've run MPF.Check in Linux on several more PC DVD discs (http://redump.org/disc/101295, http://redump.org/disc/101296, http://redump.org/disc/42471 and http://redump.org/disc/101524), dumped with redumper, and those ones seem to scan the protection fine using the mounted folder. So I guess there's something particular about http://redump.org/disc/32401 that MPF.Check doesn't like.

I notice that that disc is a PC/Mac disc, if that's the problem. I don't have any other PC/Mac discs I can immediately put my hands on to test this though.

@JohnVeness commented on GitHub (Jan 3, 2024): I've run MPF.Check in Linux on several more PC DVD discs (http://redump.org/disc/101295, http://redump.org/disc/101296, http://redump.org/disc/42471 and http://redump.org/disc/101524), dumped with redumper, and those ones seem to scan the protection fine using the mounted folder. So I guess there's something particular about http://redump.org/disc/32401 that MPF.Check doesn't like. I notice that that disc is a PC/Mac disc, if that's the problem. I don't have any other PC/Mac discs I can immediately put my hands on to test this though.
Author
Owner

@JohnVeness commented on GitHub (Jan 3, 2024):

Right, getting somewhere. It seems this PC/Mac disc has both an ISO9660 and a UDF filesystem present. By default it mounts as UDF, and MPF.Check fails as mentioned before. If I force it to mount as ISO9660, MPF.Check works fine.

I notice that when mounted in ISO9660 all the filenames are lower-case, whereas in UDF the filenames are in mixed-case. So maybe it's something to do with Windows being case-insensitive in general, and Linux being case-sensitive.

There are also other filename differences, e.g. a file called "Archive.pax.gz" in UDF is called "archivepax.gz" in ISO9660.

@JohnVeness commented on GitHub (Jan 3, 2024): Right, getting somewhere. It seems this PC/Mac disc has both an ISO9660 and a UDF filesystem present. By default it mounts as UDF, and MPF.Check fails as mentioned before. If I force it to mount as ISO9660, MPF.Check works fine. I notice that when mounted in ISO9660 all the filenames are lower-case, whereas in UDF the filenames are in mixed-case. So maybe it's something to do with Windows being case-insensitive in general, and Linux being case-sensitive. There are also other filename differences, e.g. a file called "Archive.pax.gz" in UDF is called "archivepax.gz" in ISO9660.
Author
Owner

@Deterous commented on GitHub (Jan 3, 2024):

I realise this is likely a BinaryObjectScanner problem, but at the moment I'm not even sure I've got the right syntax for the MPF.Check command.

It does sound like it's a BOS problem now, try running protection scanning using's the BOS Test program
And then log an issue with BOS

@Deterous commented on GitHub (Jan 3, 2024): > I realise this is likely a BinaryObjectScanner problem, but at the moment I'm not even sure I've got the right syntax for the MPF.Check command. It does sound like it's a BOS problem now, try running protection scanning using's the [BOS Test program](https://github.com/SabreTools/BinaryObjectScanner/releases/tag/3.0.2) And then log an issue with [BOS](https://github.com/SabreTools/BinaryObjectScanner/issues)
Author
Owner

@mnadareski commented on GitHub (Jan 6, 2024):

Interesting, this specific bit of the log:

0.00%: /dev/sg0 - Checking file
0.00%:  - 
100.00%: /dev/sg0 - 

Indicates that it's trying to scan /dev/sg0 as a file. Not sure why that would be, since I'm relying on .NET things to check for directory or file.

@mnadareski commented on GitHub (Jan 6, 2024): Interesting, this specific bit of the log: ``` 0.00%: /dev/sg0 - Checking file 0.00%: - 100.00%: /dev/sg0 - ``` Indicates that it's trying to scan `/dev/sg0` as a file. Not sure why that would be, since I'm relying on .NET things to check for directory or file.
Author
Owner

@JohnVeness commented on GitHub (Jan 6, 2024):

/dev/sg0 is a file. Well a block device. But it appears as a file. I.e. there isn't /dev/sg0/something/something.

@JohnVeness commented on GitHub (Jan 6, 2024): /dev/sg0 is a file. Well a block device. But it appears as a file. I.e. there isn't /dev/sg0/something/something.
Author
Owner

@Deterous commented on GitHub (Jan 9, 2024):

This will be fixed in MPF once https://github.com/SabreTools/BinaryObjectScanner/issues/276 is fixed, and MPF upgrades to a new version of BOS. There's nothing MPF can do.

@Deterous commented on GitHub (Jan 9, 2024): This will be fixed in MPF once https://github.com/SabreTools/BinaryObjectScanner/issues/276 is fixed, and MPF upgrades to a new version of BOS. There's nothing MPF can do.
Author
Owner

@mnadareski commented on GitHub (Jan 26, 2024):

Since the issue is in BOS and more specifically, an issue with "empty" symlinks, this issue will be closed and only tracked on the BOS side.

@mnadareski commented on GitHub (Jan 26, 2024): Since the issue is in BOS and more specifically, an issue with "empty" symlinks, this issue will be closed and only tracked on the BOS side.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SabreTools/MPF#664