[Bug 33292] New: Vietcong: Disc can't be authenticated
http://bugs.winehq.org/show_bug.cgi?id=33292 Bug #: 33292 Summary: Vietcong: Disc can't be authenticated Product: Wine Version: 1.5.26 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: sworddragon2(a)aol.com Classification: Unclassified Starting Vietcong with the original disc will result the most times in the error message "Unable to authenticate original disc within time limit.". Clicking on "Retry" will continue the authentication process but the vietcong process will then close after a few seconds. The only message the terminal is showing is "fixme:ntdll:server_ioctl_file Unsupported ioctl 2d1400 (device=2d access=0 func=500 method=0)". -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33292 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |obfuscation -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=33292 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |focht(a)gmx.net --- Comment #1 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, is this problem still present? Please retest with recent Wine 1.7.x version, preferably Wine 1.7.33
From what you've described it could be the data density measurement phase failing here. I've described it here: https://bugs.winehq.org/show_bug.cgi?id=10190#c21
--- quote --- The original media is recognized in general but there are some cases where it still fails. The reason is there a high precision time measurement done during software and optical drive interaction, called "data density measurement". There is a set of locations spread over the disc which are read using pairs of SCSI read commands (pass-through) per location from the drive. You can watch them using +cdrom channel. While the disc spins the time is measured it takes for the second command to return (depends on the time it takes the disc to do a full round = depends on the data density). Combining all predefined locations a vendor specific pattern is formed and verified. Wine might not be able to reliably guarantee certain timing constrains. If your disk fails to be recognized this helps: - start wineserver and services prior (notepad/whatever in different terminal) - wait a bit until the drive/media completely stopped spinning before start Don't run any CPU intensive processes in background that cause workload spikes during time measurement/calibration phase. (still fails: try again) --- quote --- If it still fails many times with the "time limit" message there is not much that can be done here, unless you use less crappy original media (DVD) and better host hardware (certain disk drives/models are pretty crappy when it comes to validating copy protected media). Likely a WONTFIX. Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=33292 --- Comment #2 from sworddragon2(a)aol.com ---
is this problem still present? Please retest with recent Wine 1.7.x version, preferably Wine 1.7.33
The bug does still exist in Wine 1.7.33.
If your disk fails to be recognized this helps:
- start wineserver and services prior (notepad/whatever in different terminal) - wait a bit until the drive/media completely stopped spinning before start
Don't run any CPU intensive processes in background that cause workload spikes during time measurement/calibration phase.
Doing this hasn't helped to solve this problem.
If it still fails many times with the "time limit" message there is not much that can be done here, unless you use less crappy original media (DVD) and better host hardware (certain disk drives/models are pretty crappy when it comes to validating copy protected media). Likely a WONTFIX.
On booting into Windows with the same system all works fine so it is not an issue with the media or the optical drive. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=33292 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #3 from joaopa <jeremielapuree(a)yahoo.fr> --- Does the bug still occur with wine-5.16? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=33292 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME Summary|Vietcong: Disc can't be |Vietcong: Disc can't be |authenticated |authenticated (SecuROM | |v4.84) --- Comment #4 from Anastasius Focht <focht(a)gmx.net> --- Hello joaopa, --- quote --- Does the bug still occur with wine-5.16? --- quote --- well, the game now hangs on startup - even before the disk validation part. Testing reveals a regression in between Wine 3.0-rc2 and Wine 3.0-rc3. From quick debugging I already know the problem but this is an entirely different, albeit interesting issue of SecuROM v4.x DRM. With a quick-partial-revert patch applied to any Wine 3.x-6.0-rc1 release, disk validation still works. Resolving 'WORKSFORME' here since there was no response since five years. Although since 2018 it wouldn't have worked anyway due to the regression. I will create a new bug report for the regression. It's not easy to fix as it highlights a general problem with Wine: Service Control Manager (SCM) and services lacking (named pipes) security and privilege separation. Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=33292 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #5 from Austin English <austinenglish(a)gmail.com> --- Closing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=33292 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED --- Comment #6 from Austin English <austinenglish(a)gmail.com> --- Closing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=33292 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #7 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Closing bugs marked workforme -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla