https://bugs.winehq.org/show_bug.cgi?id=49617
Bug ID: 49617
Summary: Wine regression with gog galaxy 2.0
Product: Wine
Version: 5.13
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ryan(a)rnrcarpet.com
Distribution: ---
Gog galaxy 2.0 fails to start and freezes during splash screen with 5.13.
----------
2020-07-25 10:18:48.557 [Information][SubSystem shortTasks thread (64)] [TID
262][galaxy_client]: Starting ClientTask: InitializationMultiTask
2020-07-25 10:18:48.558 [Information][SubSystem shortTasks thread (64)] [TID
262][galaxy_client]: Starting ClientTask: UpgradeDatabaseTask
**5.13 stops here without error in standard log. 5.5 and others continue**
2020-07-25 10:18:48.569 [Information][ (0)] [TID 9][galaxy_client]: Starting
Communication Service on login.
2020-07-25 10:18:48.595 [Information][ (0)] [TID 9][galaxy_client]: Starting
Communication Service.
2020-07-25 10:18:48.622 [Information][SubSystem shortTasks thread (64)] [TID
262][galaxy_client]: Galaxy DB is up to date. Version: 26.
----------
Reproduce:
1) Install distro wine 5.13 (Fedora 32) $ dnf install wine
2) Install gog galaxy via Lutris install script
3) Run gog galaxy 2.0 successfully
3) Switch to system wine 5.13 (distro)
4) Gog galaxy freezes during splash screen
Install wine 5.5 (eg $ dnf install wine*5.5*).
Check system wine 5.5 is in use.
Start gog galaxy and it runs successfully.
Reinstall wine 5.13, check, still freezes on start.
Notes:
Fedora 32 doesn't have anything between these two available via dnf so I can't
quickly check which version the regression starts at.
Possibly could be an issue with the distro provided version of wine? I don't
have an answer here if that's possible or not. Have a feeling its with wine
itself.
Possible future entry:
Am trying to get at a more detailed log but its really massive and apparently
ultra slow to obtain.
--
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=29582
Bug #: 29582
Summary: Star Wars Battlefront (I and II) "Loading" screen very
slow.
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: daniel.santos(a)pobox.com
Classification: Unclassified
The "Loading" screen takes so long (in SW Battlefront II) that I can't connect
to network games because when it finally finishes loading the level, I get a
message that says "lost connection to host" (presumably because it timed out).
I haven't timed it, but it seems to be about 2 minutes, whereas running it on
windows takes roughly 5-10 seconds.
WINEDEBUG=+relay did show that PeekMessageA was being called about 2700 times a
second (probably not a big deal) but then GetForgroundWindows was being called
right after that (a wineserver call). I suspected that as a possible culprit,
but haven't dug in too deeply yet.
I'll do some profiling on this later and try to get some better info. Maybe I
can find a hack-around to positively isolate the cause.
--
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=46301
Bug ID: 46301
Summary: TimeShift DEMO: freezes during the startup
Product: Wine
Version: 4.0-rc2
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: wylda(a)volny.cz
Distribution: ---
Created attachment 63025
--> https://bugs.winehq.org/attachment.cgi?id=63025
console log
TimeShift Demo freezes during the startup immediately after "Processing
Shaders" phase (Loading cca 80%).
$ du -h timeshift_sp_us_demo.exe
984M timeshift_sp_us_demo.exe
$ sha1sum -b timeshift_sp_us_demo.exe
efe37b94ea907c5d663b8b5bebe934945d814e31 *timeshift_sp_us_demo.exe
--
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=49627
Bug ID: 49627
Summary: Magic The Gathering: Arena Update manager needs
Windows.Foundation.Diagnostics.AsyncCausalityTracer
Product: Wine
Version: 5.13
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: sashok.olen(a)gmail.com
Distribution: ---
Not sure when this change in MTGA's download manager happened, but now it's
stuck in an update loop.
While I'm not entirely sure this is the cause of the looping, in the logs, I
see that it needs some new UWP debug library:
0009:fixme:combase:RoGetActivationFactory
(L"Windows.Foundation.Diagnostics.AsyncCausalityTracer",
{50850b26-267e-451b-a890-ab6a370245ee}, 0032D1D8): semi-stub
0009:err:combase:RoGetActivationFactory Failed to find library for
L"Windows.Foundation.Diagnostics.AsyncCausalityTracer"
--
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=31046
Bug #: 31046
Summary: Wine advertises 32bit depth buffer, behaves like 24bit
Product: Wine
Version: 1.5.7
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: billy65bob(a)gmail.com
Classification: Unclassified
Created attachment 40757
--> http://bugs.winehq.org/attachment.cgi?id=40757
title screen: 32-bit Z buffer on wine (DirectX9 Hardware)
Title says it all really.
I'm currently playing a game in PCSX2 (Persona 4) and frankly it looks really
bad.
According to the application, wine is reporting a 32bit Z-buffer, but amusingly
it behaves precisely how a 24bit buffer behaves in windows with this
application.
--
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=46501
Bug ID: 46501
Summary: GFWL: fails to verify cert file
Product: Wine
Version: 3.20
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: bcrypt
Assignee: wine-bugs(a)winehq.org
Reporter: lilyrivers48(a)gmail.com
Distribution: ---
Created attachment 63349
--> https://bugs.winehq.org/attachment.cgi?id=63349
Backtrace of Universe at War Earth Assault GFWL startup
The bcrypt functions don't work for verifying the cert
Wintrust fails to get information from the CAT file
--
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=49635
Bug ID: 49635
Summary: Fallout NV: Radio skip song after ~40sec
Product: Wine
Version: 5.13
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: quartz
Assignee: wine-bugs(a)winehq.org
Reporter: timofeevsv1989(a)gmail.com
Distribution: ---
wine-staging 5.12 from Manjaro repo, and wine-tkg git (5.13)
Tested on clean GOG installation (DRM-Free, without mods, old configs removed)
It is not depend on my pulseaudio settings, with or without pulseaudio-staging
patchset
EAX disabled to
I have installed:
chaotic-aur/ ffmpeg (+32bit)
chaotic-aur/faudio-tkg-git
chaotic-aur/lib32-faudio-tkg-git
But this bug still exist. There is no cure for it, Installations of codecs,
quartz.dll, FAudio.dll, XACT does not solve this problem.
--
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=48291
Bug ID: 48291
Summary: Detroit: Become Human crashes on launch
Product: Wine
Version: 5.0-rc1
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: sashok.olen(a)gmail.com
Distribution: ---
Created attachment 65990
--> https://bugs.winehq.org/attachment.cgi?id=65990
backtrace
For now I've only uploaded a backtrace, but it's a bit unusual:
0x0000000000000000: -- no code accessible --
Let me know if you need anything else.
--
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=49640
Bug ID: 49640
Summary: Loading certain builtin/Winelib DLLs twice may crash
Product: Wine
Version: 5.13
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: bshanks(a)codeweavers.com
Distribution: ---
When certain "builtin"/Winelib DLLs/EXEs get loaded, then unloaded, then loaded
again (by two calls to GetFileVersionInfoSize() for example), the second load
may result in a crash.
The underlying problem is that dlopen_dll() in dlls/ntdll/unix/loader.c assumes
that dlopen() is returning a freshly-mapped copy of the file. POSIX doesn't
guarantee this though, and if the file was already previously loaded by Wine,
and relocation fixups were applied, those fixed-up headers will be still be
present. map_so_dll then applies fixups again, and that's where I'm seeing the
crash. In particular, when map_so_dll is building the import directory, I see
that imports->Name already has the delta applied to it from the previous load.
An EXE that has this problem is the "steam.exe.so" shipped with Proton, I
believe since it links to a C++ library it will not be unloaded by a dlclose()
call (see
https://stackoverflow.com/questions/38869657/dlclose-not-unloading-so-file-…)
--
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=49699
Bug ID: 49699
Summary: Red Dead Redemption 2 has crackling audio
Product: Wine
Version: 5.14
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winepulse.drv
Assignee: wine-bugs(a)winehq.org
Reporter: bshanks(a)codeweavers.com
Distribution: ---
Red Dead Redemption 2 uses WASAPI for audio, and sometimes has crackly audio.
It asks for a very small buffer (10 ms) when calling
IAudioClient::Initialize(), and then has a thread which checks the buffer
padding every 2 ms. It waits until there's at least 256 frames free in the
buffer, and fills 256 frames at a time.
When using winepulse, it has a low latency path and provides a 10 ms buffer.
This is 440/480 frames, not leaving much slack when refills are only 256 at a
time.
As far as I can tell, Windows never gives out a buffer smaller than 20 ms
though. This is more around 1056 frames, leaving much more slack. Disabling the
winepulse low latency path results in a buffer around this size, and audio is
much better. winealsa also seems to do this by default, and it sounds fine.
--
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.