http://bugs.winehq.org/show_bug.cgi?id=17806
Summary: AutoCAD LT 2008 fails to install
Product: Wine
Version: 1.1.17
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: msi
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: lukasz.wojnilowicz(a)gmail.com
Created an attachment (id=20038)
--> (http://bugs.winehq.org/attachment.cgi?id=20038)
WINEDEBUG=+msi Wine 1.1.17
I'm using Wine 1.1.17 (compiled from source using gcc version 4.3.2 20081105
(Red Hat 4.3.2-7) ) on Fedora 10 i386.
I installed gecko,msxml3,vcrun2005,dotnet20,corefonts,gdiplus through
winetricks.
The problem is that AutoCAD LT 2008 PL fails to install (default installation).
It doesn't crashes but the AutoCAD installer notifies about that.
The error in terminal is (installation stops at this)
err:msi:ITERATE_Actions Execution halted, action L"InstallExecute" returned
1603
--
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=27937
Summary: winmm kept busy playing silence after play finishes
Product: Wine
Version: 1.3.25
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: mmdevapi
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: hoehle(a)users.sourceforge.net
CC: aeikum(a)codeweavers.com
The winmm player is kept busy for several seconds after audible rendering ends.
This is easily reproduced using my MCI shell from bug #20232, comment #10.
Issue these commands to the MCI:
open 8k8bitpcm.wav alias 8 ; any sample with at least 2 seconds of data
play 8 from 1000 to 2000 notify ; play sample from position 1s to 2s
play 8 from 1000 to 2000 WAIT
status 8 mode
I recommend to use a multi-line copy&paste to the console instead of typing.
The MCIWAVE player will correctly play 1 second worth of data. After that
however, a random amount of upto 4 messages about ALSA pcm underrun are sent to
the console, approx. 1 per second. It's only after those that the player
eventually stops, i.e. execution of the synchronous command ends.
The command "status 8 mode" serves to show when execution of the previous
command ends.
I suspect the cause is the way mmdevapi handles silence and/or feeds too much
data into the "default" ALSA device. I have no idea where that 1s log message
spacing comes from.
Expected behaviour (as in 1.3.24): the synchronous (WAIT flag) player is kept
busy for 1 second, after which the MCI shell processes the next command. Upto
one ALSA pcm underrun log message is the norm, since indeed WINMM is closed
only after all buffers (headers in waveOut* speak) have been returned to the
app, i.e. there's a tiny gap between "played last header => Set Event" and
waveOutClose. I.e. one underrun is designed into the WINMM API, after playing
ends.
--
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=6033
Jerome Leclanche <adys.wh(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #81 from Jerome Leclanche <adys.wh(a)gmail.com> 2012-02-02 16:11:13 CST ---
Reported fixed
--
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=6033
--- Comment #80 from drachu(a)gmail.com 2012-02-02 15:46:39 CST ---
As I mentioned before. I did clean install of wine, at ubuntu 11.10, then
installed Fallout 2, and everything worked out of box like a charm. Even cursor
who had some issues in the past.
I've tested it with NVIDIA 9600GT with 275 driver (quite recent).
I would recommend to close this ticket.
--
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=8295
Henri Verbeet <hverbeet(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
--- Comment #29 from Henri Verbeet <hverbeet(a)gmail.com> 2012-02-02 15:06:45 CST ---
Resolving FIXED.
--
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=8295
--- Comment #28 from Henri Verbeet <hverbeet(a)gmail.com> 2012-02-02 15:06:28 CST ---
(In reply to comment #27)
> just a clarification regarding the performance - I've foud who kills it. It's
> the "Z Read" option at the very bottom of the graphic options (you have to set
> the Graphic detail to "Custom" in order to see it).
If that's depth readback, I think that makes sense. I wouldn't expect that to
be terribly fast on Windows either though.
--
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=8295
--- Comment #27 from Tomek Kaźmierczak <tomek-k(a)wp.eu> 2012-02-02 14:33:08 CST ---
just a clarification regarding the performance - I've foud who kills it. It's
the "Z Read" option at the very bottom of the graphic options (you have to set
the Graphic detail to "Custom" in order to see it).
With the option enabled I get average 10 fps. When it's off, I get 86 fps with
all options set to max and in 1366x768 screen res.
Have a nice play
--
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=8295
--- Comment #26 from Tomek Kaźmierczak <tomek-k(a)wp.eu> 2012-02-02 13:46:47 CST ---
Fixed in 1.4-rc1 (was still present in 1.3.37).
Now it's possible to run the game in hardware accelerated mode.
The performance of WineD3D is terribly poor, however - the game runs smoothly
in SW mode, even with highest gfx settings. In order for it to be playable in
HW mode, one has to turn off almost all gfx options and play in the lowest
screen resolution. But this is not related to this bug report.
As for me, the bug can be finally closed.
--
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=29496
Bug #: 29496
Summary: Mouse doesn't release when moving/resizing Steam
window
Product: Wine
Version: 1.3.36
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: wine(a)placesthroughtime.com
Classification: Unclassified
The Steam window, when resized or moved shortly after changing tabs, ex. from
Store to Library or visa versa, will act as though the mouse has not been
released after it has been and will remain in its state of resize/move window.
Possibly also related to this, shortly after starting steam and attempting to
move the window occasionally the mouse will stick but the cursor will move
itself to above the Steam window and any attempt to move back within the window
will force it away from the cursor.
--
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=29122
Bug #: 29122
Summary: Sonic R has rendering (color keying) issues in
Direct3D mode
Product: Wine
Version: 1.3.32
Platform: x86-64
URL: http://www2.sega.co.jp/download/pc/sonicr/sonicr.exe
OS/Version: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: directx-ddraw
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: RandomAccountName(a)mail.com
Classification: Unclassified
Regression SHA1: c8901d6f6253f6c97610eb1068ac4ff89758ed0a
When Sonic R is run with the Direct3D renderer, it has some rendering issues
(various objects have a green background instead of transparent) as seen in
this screenshot: http://appdb.winehq.org/appimage.php?iId=9421
The DirectDraw renderer works without this problem. According to bug 21878,
comment 5, it's a regression caused by:
commit c8901d6f6253f6c97610eb1068ac4ff89758ed0a
Author: Stefan Dösinger <stefandoesinger(a)gmx.at>
Date: Fri Jun 9 19:36:12 2006 +0200
ddraw: Rewrite most of ddraw using WineD3D.
Attachment 36962 from that bug fixes the issue.
The demo has the same problem. It will most likely crash on startup due to a
game bug unless the CPU power available to it is limited somehow, e.g. by
running a program with high CPU usage while starting it.
--
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.