http://bugs.winehq.org/show_bug.cgi?id=20555
Summary: inconsistent handling of Audio-CDs Product: Wine Version: 1.1.32 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll AssignedTo: wine-bugs@winehq.org ReportedBy: hoehle@users.sourceforge.net
mci "open cdaudio" fails on pure Audio CDs, but the bug is not within MCI rather than in volume management or kernel32/ntdll (the MCI calls GetDriveTypeW).
Case A) When an audio-only CD is inserted before Wine is started, it creates the link dosdevices/d:: -> /dev/scd0 and in system.reg: [Software\Wine\Drives] "d:"="cdrom" mciSendString "open cdaudio" fails (MCIERR bad device) because GetDriveTypeW does not return a CDROM type. It would succeed on MS-Windows.
Wine creates the additional link d: -> /media/cdrom0 only when using a data-only CD-ROM or a mixed data + audio CD. In the latter case, mciSendString "open cdaudio" succeeds.
Conversely, an existing dosdevices/d:: link causes dosdevices/d: to be removed when Wine starts with a pure Audio-CD in the drive.
For consistency, you should have dosdevices/d:: point to your CD-ROM device, because of another bug in volume management: MCI "open e:\ type cdaudio" fails, while open d:\ succeeds even when E: is the CD-ROM!
Case B) Defining a CD-ROM myself (or like Wine did years ago?) using: dosdevices/d: -> /media/cdrom (which is in turn a link to /media/cdrom0 in Ubuntu) dosdevices/d:: does not exist. [Software\Wine\Drives] "d:"="cdrom" mciSendString "open cdaudio" succeeds. "play cdaudio" causes the drive to spin, but is sometimes returned with MCIERR_HARDWARE. AoE2 sends slightly different MCI commands and manages to play the CD. Even Crazy Machines successfully plays the audio CD with this setup.
Using Ubuntu Intrepid.
http://bugs.winehq.org/show_bug.cgi?id=20555
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
--- Comment #1 from André H. nerv@dawncrow.de 2009-11-02 15:16:29 --- can you attach a small testapp that does a mci "open cdaudio". so its easier to test.
http://bugs.winehq.org/show_bug.cgi?id=20555
--- Comment #2 from Jörg Höhle hoehle@users.sourceforge.net 2009-11-03 03:35:58 --- Binary attached to bug #20232, comment #10 because that's where I posted the source and my MCI tests.
open cdaudio play cdaudio status cdaudio mode status cdaudio position set cdaudio time format tmsf seek cdaudio to start play cdaudio from 2
The interactive shell is perfect for exploratory testing.
http://bugs.winehq.org/show_bug.cgi?id=20555
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #3 from André H. nerv@dawncrow.de 2009-11-03 12:04:37 --- confirming in git
http://bugs.winehq.org/show_bug.cgi?id=20555
--- Comment #4 from Jörg Höhle hoehle@users.sourceforge.net 2009-12-14 06:24:06 --- The difference between A) (default behaviour) d:: -> /dev/scd0 =>(Wine creates) d: -> /media/cdrom0 B) (entry created by hand) d: -> /media/cdrom (itself a link to /media/cdrom0) declared as CD-ROM affects "Ritter Rost - die eiserne Burg" (not yet in AppDB)
Behaviour in case A): 1) Ritter Rost displays a screen asking to insert the CD, even though it is already there. Hit Ok and it will proceed. 2) Next it displays a file requester (once) asking "Where is e:\MCI\movies.cst ?" (I don't know how E: comes into play). The directory displayed is already the one which contains movies.cst (or the MCI subdirectory)! Select the file therein and continue.
B) Neither of the above 2 requesters appear. The app starts fine and displays no less animations than in case A).
I'm pretty sure I have read in either AppDB or Bugzilla about apps requesting a CD already in the drive. This is another example.
http://bugs.winehq.org/show_bug.cgi?id=20555
--- Comment #5 from Jörg Höhle hoehle@users.sourceforge.net 2010-01-14 08:55:58 --- Oops, I realised that the Ritter Rost CD is a pure data CD without audio tracks. This means there are two distinct issues: 1. inconsistent handling of pure audio CD vs. mixed audio+data CDs -- the subject of this issue. 2. inconsistent handling of A) d:: -> /dev/scd0 and B) d: -> /media/cdrom that affects Ritter Rost as per comment #4. Generally, my experience is that A) - the hand-created link d: -> /media/cdrom works better with apps than B) - the auto-configured d:: + d: -> /media/cdrom0
http://bugs.winehq.org/show_bug.cgi?id=20555
--- Comment #6 from Jörg Höhle hoehle@users.sourceforge.net 2010-08-25 06:44:27 --- Still present in wine-1.3.1. A fresh Wine install in Ubuntu will not let mcicda open cdaudio (in case of an audio-only CD) because of GetDriveTypeW not reporting a CD-ROM. This is surprising because winecfg shows device D: as an "Audio CD" and even shows its serial number.
As a result, a default Wine install will skip most of mcicda tests even when a CD is present in the drive.
open cdaudio only works with the hand-made symbolink link /media/cdrom as an extra DOS drive E: declared as CD-ROM in winecfg (i.e. case B).
http://bugs.winehq.org/show_bug.cgi?id=20555
--- Comment #7 from butraxz@gmail.com 2013-06-27 12:32:07 CDT --- This ticket has not been updated for over 900 days.
Is this still an issue in wine version 1.6-rc3 or higher or is this to be closed as abandoned ?
https://bugs.winehq.org/show_bug.cgi?id=20555
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |ABANDONED
--- Comment #8 from Austin English austinenglish@gmail.com --- (In reply to butraxz from comment #7)
This ticket has not been updated for over 900 days.
Is this still an issue in wine version 1.6-rc3 or higher or is this to be closed as abandoned ?
Abandoned.
https://bugs.winehq.org/show_bug.cgi?id=20555
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #9 from Austin English austinenglish@gmail.com --- Closing.
-
wine-bugs＠winehq.org