http://bugs.winehq.org/show_bug.cgi?id=30666
Bug #: 30666
Summary: MPEG movie does not play in Capitalism 2 demo
Product: Wine
Version: 1.5.4
Platform: x86
URL: http://www.cnwcentral.com/capitalism-2/demo.shtml
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winegstreamer
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jeremielapuree(a)yahoo.fr
Classification: Unclassified
Created attachment 40144
--> http://bugs.winehq.org/attachment.cgi?id=40144
console output
While playing intro movie of Capitalism 2 demo, one can hear the sound, but
video is playing.
--
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=53633
Bug ID: 53633
Summary: Visual Novel Ninki Seiyuu no Tsukukurikata crashes on
start throwing failed to call ConnectFilters (pSrc,
pMPEG1Splitter)
Product: Wine
Version: 7.16
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: quartz
Assignee: wine-bugs(a)winehq.org
Reporter: bugmetoo(a)protonmail.com
Distribution: ---
Created attachment 73031
--> https://bugs.winehq.org/attachment.cgi?id=73031
Crash log in a freshly created Wine Prefix
On trying to launch the game, the game throws the following message
"failed to call ConnectFilters (pSrc, pMPEG1Splitter).:[0x80004005] Error:
0x80004005" and application crashes.
Running winetricks quartz fixes the issue.
--
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=9127
Alberto Salvia Novella <es20490446e(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |es20490446e(a)gmail.com
--- Comment #106 from Alberto Salvia Novella <es20490446e(a)gmail.com> ---
*** Bug 53726 has been marked as a duplicate of this bug. ***
--
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=53718
Bug ID: 53718
Summary: WoW Beta/PTR get "Your 3D accelorator card is not
supported"
Product: Wine
Version: 7.17
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: mckittrick.kaminski(a)gmail.com
Distribution: ---
Created attachment 73148
--> https://bugs.winehq.org/attachment.cgi?id=73148
Collection of Retail and Beta logs.
I had be playing/testing the new Dragonflight expansion for WoW recently, and
after this week's update, the game no longer launches, with the age old "Your
3D accelerator card is not supported" error. Research on previous occurrences
of this error have been fruitless, usually having something to do with multiple
GPUs and having the wrong one assigned.
Being that the WoW client updating was the only change to cause this issue, and
native Windows clients seem to have no issue, I can't help but think this lies
somewhere in wine, dxvk, or vkd3d namespace.
For information on my environment, I'm running via Lutris, and have tried both
Lutris and Wine runners, a few releases from 5.x, 6.x, and 7.x, up to 7.17
staging. I'm using dxvk v1.10.3 and vkd3d v2.6. My graphics card is 3060Ti, and
I get the error with both the 470xx and 515 nvidia drivers. The 3060Ti is the
only VGA controller in my system, and I'm running Arch 5.19.9. Manually setting
the 'gxApi "D3D11"' config line in Config.wtf doesn't change the behavior,
which applies to D3D11, D3D11_LEGACY, as well as D3D12.
I'll note that this error only occurs with Beta and PTR clients. (PTR is open
to everyone, if you'd like to test, not sure if you need gametime). Retail and
Classic both work just fine and haven't any issue, although, I've noticed the
in-game option to use D3D12 has disappeared, leaving me with only D311 options.
It used to be there, and I'm unsure when the option left.
I've attached logs from both Beta and Retail, let me know what else I can
provide/test for y'all.
--
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=53763
Bug ID: 53763
Summary: eSword crashes when changing fonts, throws Text
Control error on newer bible modules
Product: Wine
Version: 7.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: thegamemaster(a)hotmail.com
Distribution: ---
eSword found here: https://www.e-sword.net/files/e-sword_1220_setup.exe
Using Wine 7.18 on Fedora 36 KDE Spin.
This behavior is observed on several different machines including high end AMD
3900XT gaming system and low end Dell 1540 laptop.
eSword 12.2.0 works fine under Wine 6.0.4 and does not exhibit these behaviors.
When you click on certain newer bible modules it throws an error;
"Error: 20058 Unexpected Text Control error. (1-1d03)
This only happens on newer bible modules: LSB, LSB+, NASB, NASB+, ESV,
ESV+,CSB, and TPT.
If you click OK on the error message, the font colors change to black on gray,
hard to see, and none of the "Perascope" links work, but the greek/hebrew
Strongs Number links still work.
Older bible modules work fine, including some with Parascope links such as
NASB95, NASB95+.
On the menu bar, if you click on Options, then on Font Settings... the program
crashes.
On the menu bar, if you click on Options, then on App Theme, and select any
Theme the program locks up and must be forced to Terminate.
--
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=48912
Bug ID: 48912
Summary: Allow blacklisting unreliable and always new failures
Product: Wine-Testbot
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
A number of tests produce false positives because:
* Either the failure message contains a value that changes with each run (e.g.
an HWND). In some cases these values are really necessary for diagnosis and
moving them to a separate line would make the code quite a bit more complex.
* Or the test fails intermittently and is hard to fix. Sometimes the cause of
the failures may also come from external factors such as bugs in QEmu (for
instance long execution delays causing timeouts).
* Sometimes the intermittent failure is the product of a new Windows version or
configuration, which requires investigating before a fix is found.
In all cases the tests should be fixed eventually, but a solution is needed for
the interim so these tests to not make the TestBot so unreliable that its
results are ignored.
So the goal is to provide a way to blacklist some test failures so they do not
cause a patch to be rejected. Some safeguards are needed to ensure that:
* Failures are not blacklisted lightly. The preference should always be to fix
the test.
* The blacklist does not get so large that it becomes hard to maintain.
* Once a test is fixed the corresponding blacklist entries are removed in a
timely fashion.
* There is still an incentive to fix the tests.
So here is a proposal for implementing this blacklist:
* Each blacklist entry should be associated with a Wine bug describing the
issue. That bug should provide some minimal diagnosis: whether it's a new
Windows behavior, a race condition or some issue that was reported to QEmu.
That would ensure we know why the blacklist entry was added. One could also
check the status of the bug when reviewing the blacklist entries. A closed bug
would be a strong hint that the blacklist entry is no longer needed.
* Rather than blacklisting whole test units, blacklist entries should target
specific test failures via a regular expression. Besides being finer grained
this would be useful for cases like user32:win which has different issues
depending on the locale and where each should be linked to a different bug
(bugs 48815, 48819 and 48820).
* The TestBot should record when each blacklist entry was last used. This
relies on having the above regular expression since without it the TestBot
would not know anything beyond 'the test unit was run and had failures'. Also
the regular expression would only be used against *new* failures. So this would
really record the last time the blacklist entry was actually useful.
An entry that was unused for a long time would be a prime candidate for
reviewing the corresponding bug and for removal. (Note: The blacklist would
also be used on WineTest reports so it would get a chance of matching its
target at least 5 days / week).
* The blacklist entries would only be needed for 'base' test configurations
since they are the only ones wine-devel patches run on.
* There should be a page listing the blacklist entries so developers have a
good starting point to work on them.
* Ideally the blacklist page would also point to the tasks where the blacklist
was last used. Since most of the blacklisted failures are either intermittent
or specific to a given test configuration this would make it easier for
developers to find reports where the failure did happen.
Note that Wine VMs often test multiple configurations per task (e.g. wow32
and wow64, different locales), each producing its own test report. So pointing
at just the task would leave the developer guessing which report should be
looked at. But that may be sufficient guidance.
* (test:unit, testbot-vm) tuples make it impossible to target a specific Wine
test configuration such as a specific locale since they all run on the same VM.
Similarly it would make blacklisting bitness-blind on Windows VMs. If necessary
the tuple could be extended either with the specific mission the blacklist
applies to, or with the basename of the corresponding report (the latter being
easier to use in comparisons). Whether that's practical and worth the effort
remains to be determined. One complication for instance is that this would lead
to more blacklist entries: many 64 bit VMs would need two entries, one for 32
bit tests and one for 64 bit tests.
* Pseudo database schema and sample use:
FailureBlacklists
-----------------
PK Bug 48815
PK TestModule user32
PK TestUnit win
Name 0x738 message
FailureRegExp Test failed: hwnd [0-9A-F]{8,16} message 0738
LastUse 2020-03-27
FailureBlacklistVMs
-------------------
PK Bug 48815
PK TestModule user32
PK TestUnit win
PK VMName Entries for w1064v1709, w1064v1809, etc.
(48815, user32, win, w1064v1709)
(48815, user32, win, w1064v1809)
(48815, user32, win, w1064v1809_2scr)
...
FailureBlacklistUses (optionally)
---------------------------------
PK Bug
PK TestModule
PK TestUnit
PK JobId
PK StepNo
PK TaskNo
(48815, user32, win, 68507, 1, 7)
(48815, user32, win, 68508, 1, 7)
...
--
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=48209
Bug ID: 48209
Summary: Ignore random parts of test failure messages
Product: Wine-Testbot
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
The TestBot needs to detect if a patch introduces NEW test failures. To do so
it compares the failure messages with those from reference WineTest runs. But
in some cases part of the message changes from one run to the next, causing the
failure to look new.
Of course in all cases the ideal solution is to fix the test so it does not
fail.
Barring that there are also cases where the varying value is not really useful
(e.g. handle or pointer values) and in that case it should just be removed from
the message.
But there may be cases where knowing the value is still useful. So one solution
would be to tag such values so the TestBot knows it can ignore them when
comparing failure messages. For instance they could be enclosed in double
braces, curly braces, or other.
--
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=53759
Bug ID: 53759
Summary: FPGA Programmer can't open port
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: 7Cattac(a)gmail.com
Distribution: ---
Created attachment 73229
--> https://bugs.winehq.org/attachment.cgi?id=73229
output log
I'm trying to use FPGA Programmer
(https://www.fpga-cores.com/software/fpga-programmer/) to broadcast UPD
packages to my FPGA.
Starting it up has no issues, but when it depends a device in the network it
hangs for a couple of minutes and the app runs very slowly.
Trying to upload a .bin takes a long time and gives an error saying "can't open
port", when that happens "010c:fixme:progress:ProgressWindowProc state 2 not
yet handled" is spammed in the logs.
Wine version: Wine-staging 7.18
FPGA Programmer version: 1.1
--
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=53758
Bug ID: 53758
Summary: Prototype freezes and crashes after intro/in menu
Product: Wine
Version: 7.16
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: odecif(a)gmail.com
Distribution: ---
Created attachment 73228
--> https://bugs.winehq.org/attachment.cgi?id=73228
Execution log
After a fresh install from DVD-disc on a clean 64-bit prefix, if I run the game
using "WINEPREFIX=<prefix> wine prototypef.exe" in the games installation
folder, the game start up showing a cinematic of some license-text and the
developers logo and transfers to the games main menu. Here a modal shows with
some information regarding save game and here is when the game freezes.
winetricks dxvk removes said freeze and the game is playable.
GTX 760M
i5-6300HQ
Budgie DE
Manjaro 22
Kernel 5.4.212-1
--
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=52689
Bug ID: 52689
Summary: NVCUDA: Daz Studio 4.20 and CUDA SDK11 implementation
Product: Wine-staging
Version: 7.4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: cybermax(a)dexter.no
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
Created attachment 72031
--> https://bugs.winehq.org/attachment.cgi?id=72031
Series of patches to implement basic SDK11 functionality
Recently DAZ Studio4 updated to 4.20 and the Iray engine also got updated to
the point it requires support for CUDA 11.4
I have worked through a great deal of the issues regarding support for SDK
11.4, aside from the D3D9/10/11 elements that have no equivalent Linux support.
The result is adding a few functions to the nvcuda implementation in
wine-staging. (Attachment with a series of 4 patches).
I have not yet been able to get SDK 11.6 samples to run, as this will (for now)
fail the CUDA runtime validation.. but DAZ Studio 4.20.1 is running fine.
2022-03-17 22:24:11.731 Iray [INFO] - IRAY:RENDER :: 1.1 IRAY rend info :
NVIDIA display driver version: 510.54
2022-03-17 22:24:11.732 Iray [INFO] - IRAY:RENDER :: 1.1 IRAY rend info :
Your NVIDIA driver supports CUDA version up to 11.6; iray requires CUDA version
11.4; all is good.
2022-03-17 22:24:11.732 Iray [INFO] - IRAY:RENDER :: 1.1 IRAY rend info :
Using iray plugin version 5.3, build 349500.7063 n, 18 Jan 2022,
nt-x86-64-vc142.
2022-03-17 22:24:11.768 Iray [INFO] - IRAY:RENDER :: 1.1 IRAY rend info :
CUDA device 0 (NVIDIA GeForce RTX 2070): compute capability 7.5, 7.773 GiB
total, 7.229 GiB available, display attached
I have built and run the main demo samples from the cuda-samples source github,
aswell as 30 some samples in addition to that, compiled with VS2019 and using
the SDK11.4 runtime library.
--
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.