http://bugs.winehq.org/show_bug.cgi?id=35587
Bug ID: 35587 Summary: League of Legends: Long delay before loading into the game when sound is enabled Product: Wine Version: 1.7.12 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: codehotter@gmail.com Classification: Unclassified
This problem has existed for a while, it is not a problem new in 1.7.12.
If you have sound enabled, and you load into a game, there's a delay before the game starts loading. For 70 seconds (on my system) the screen stays the same: the background and your own summoner name are loaded, but your champion portrait and your summoners, are blank. Your % loaded stays at 0%. Other players are also completely blank. Eventually, you start loading normally, at 0%, when most everyone else is already done.
If you start the game with sound disabled in the game options (ESC -> Sound -> Disable All Sound), there is no delay and you load into the game immediately. However, if you then enable sound during the game, you experience the delay as soon as you click OK. The screen freezes, and you cannot see what is happening or do anything until the delay is over.
This is a relatively minor issue. However, if the game client crashes and you restart it, you not only have to load in again, but you also have to wait an extra minute for this delay, during which the enemy team can gain significant advantage.
Attached is the console output while this happens.
http://bugs.winehq.org/show_bug.cgi?id=35587
Iskren Todorov metalgrid@mail.bg changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |metalgrid@mail.bg
https://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #1 from Joshua spam-dreck-shit@web.de --- Created attachment 47536 --> https://bugs.winehq.org/attachment.cgi?id=47536 Logs before freeze
I can confirm this. On my machine it's about 160 seconds, though. This is a bit annoying. Workaround works, too.
This bug happens with LoL 4.1 and 4.2 and following wine versions: -stock 1.7.12 -Playonlinux 1.7-LeagueofLegends -Playonlinux 1.5.24-LeagueofLegendsShop
The last thing in log right before it freezes (except all the d3d fixmes) is this: fixme:avrt:AvSetMmThreadCharacteristicsW (L"Audio",0xc70e994): stub
System Info: Arch Linux x86_64 wine 1.7.12 Pulseaudio 4.0 alsa-lib 1.0.27.2
https://bugs.winehq.org/show_bug.cgi?id=35587
Joshua spam-dreck-shit@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spam-dreck-shit@web.de
http://bugs.winehq.org/show_bug.cgi?id=35587
Riccardo c10ud.dev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |c10ud.dev@gmail.com
--- Comment #2 from Riccardo c10ud.dev@gmail.com --- I can confirm this.
However what would the best way to debug the cause here?
https://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #3 from Joshua spam-dreck-shit@web.de --- (In reply to Riccardo from comment #2)
I can confirm this.
However what would the best way to debug the cause here?
As not everyone is experiencing this, it would be good to know wine/kernel/libraries versions and your distribution. Maybe we can get a correlation.
https://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #4 from Riccardo c10ud.dev@gmail.com --- (In reply to Joshua from comment #3)
(In reply to Riccardo from comment #2)
I can confirm this.
However what would the best way to debug the cause here?
As not everyone is experiencing this, it would be good to know wine/kernel/libraries versions and your distribution. Maybe we can get a correlation.
Ubuntu 12.04 x64 with kernel 3.8.0-36-generic and wine 1.7.12 from wine-ppa LoL with texture patch
https://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #5 from Iskren Todorov metalgrid@mail.bg --- (In reply to Joshua from comment #3)
(In reply to Riccardo from comment #2)
I can confirm this.
However what would the best way to debug the cause here?
As not everyone is experiencing this, it would be good to know wine/kernel/libraries versions and your distribution. Maybe we can get a correlation.
I can confirm this too.
System info: Slackware64 14.1 Kernel 3.10.17 Wine: self-built 1.7.12 ALSA: 1.0.27 PulseAudio: 4.0 (Removing it has no effect) League of Legends is patched with tuxlol texture patch.
Can provide logs and backtraces if needed.
http://bugs.winehq.org/show_bug.cgi?id=35587
lolbugs Virmantas7@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Virmantas7@gmail.com
--- Comment #6 from lolbugs Virmantas7@gmail.com --- Yeah when you disable sound in previous game in then the next game loading screen shows up fast, also if i forget to disable sound or want to enable sound in game which makes my game kinda freeze i wait a minute and then i press ctrl+alt+8 and then back ctrl+alt+7, it sometimes helps.
http://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #7 from Riccardo c10ud.dev@gmail.com --- Created attachment 47591 --> http://bugs.winehq.org/attachment.cgi?id=47591 Relevant section of debug when "freeze" happens
Here is a debug with: +tid,+mmdevapi,+winmm,+driver,+msacm,+midi,+dsound,+dsound3d,+dmusic,+mci,+oss,+alsa,+coreaudio
when the "freeze" happens. Not really sure if it's related though since after hanging for a bit no new messages arrive, only d3d's fixme.
Hence I'm not sure if it's winmm's fault or what...
http://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #8 from Riccardo c10ud.dev@gmail.com --- Should we change Component to mmdevapi?
http://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #9 from Riccardo c10ud.dev@gmail.com --- Created attachment 47593 --> http://bugs.winehq.org/attachment.cgi?id=47593 Another mmdevapi trace when hanging
http://bugs.winehq.org/show_bug.cgi?id=35587
Riccardo c10ud.dev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #47591|0 |1 is obsolete| | Attachment #47593|0 |1 is obsolete| |
--- Comment #10 from Riccardo c10ud.dev@gmail.com --- Created attachment 47595 --> http://bugs.winehq.org/attachment.cgi?id=47595 new, more complete log
Another trace with timestamps etc.
AvSetMmThreadCharacteristicsW is where more or less "hangs"
I suspect those lines:
32206.313:0062:trace:alsa:alsa_write_data XRun state avail -32, recovering
http://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #11 from Riccardo c10ud.dev@gmail.com --- I'm not entirely convinced this is a "plain" wine bug.
Here's game debug when sound is loaded:
000010.605| 0.0000kb| 0.0000kb added| ALWAYS| CreateParticleSystemManager 000011.518| 0.0000kb| 0.0000kb added| ALWAYS| CreateAudioManager: Create audio manager FMOD. 000062.177| 0.0000kb| 0.0000kb added| ALWAYS| FMOD: Attempting to load localized audio for ...
Notice the >50s delay for FMOD instancing. Now, all the wine debug I gathered doesn't show any section hanging or giving weird errors. Is there any other game using FMOD out there? Or any test program that shows this behaviour?
https://bugs.winehq.org/show_bug.cgi?id=35587
Joshua spam-dreck-shit@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #47536|0 |1 is obsolete| |
--- Comment #12 from Joshua spam-dreck-shit@web.de --- Created attachment 47647 --> https://bugs.winehq.org/attachment.cgi?id=47647 Game Client Logs
(In reply to Riccardo from comment #11)
I'm not entirely convinced this is a "plain" wine bug.
Yeah, after reading the logs I think LoL/FMOD has problems finding and loading an audio file. It stalls for some time and then loads a failsafe.
The interesting thing is: Even though my LoL locale was set to en_GB (I play in EUW) the only *.fev file in my installation was en_US. So a I changed the locale (in RADS/system/locale.cfg) to en_US.
My next attachement will contain a log with en_US.
https://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #13 from Joshua spam-dreck-shit@web.de --- Created attachment 47648 --> https://bugs.winehq.org/attachment.cgi?id=47648 Game Client Logs (en_US)
Notice this at 000111.841: pFilename = Data\Sounds\FMOD\en_US/LoL_Audio_en_US.fev
Maybe it is confused by the different path separators.
Also interesting is that it finds a correct file but the overall delay ist still the same.
I have no idea how to debug this further, do you know how to proceed?
https://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #14 from Riccardo c10ud.dev@gmail.com --- (In reply to Joshua from comment #12)
Created attachment 47647 [details] Game Client Logs
(In reply to Riccardo from comment #11)
I'm not entirely convinced this is a "plain" wine bug.
Yeah, after reading the logs I think LoL/FMOD has problems finding and loading an audio file. It stalls for some time and then loads a failsafe.
The interesting thing is: Even though my LoL locale was set to en_GB (I play in EUW) the only *.fev file in my installation was en_US. So a I changed the locale (in RADS/system/locale.cfg) to en_US.
My next attachement will contain a log with en_US.
It's weird that it stalls for 100 seconds for "localizing audio"... I tend to think that it may be something in FMOD itself or Lolclient..triggered maybe by wine but who knows?
The same behaviour can be obtained ad libitum deactivating-activating audio from the in-game menu. Really weird, wine gives no useful output...definitely not a simple problem to deal with :(
http://bugs.winehq.org/show_bug.cgi?id=35587
a.metaphysical.drama@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |a.metaphysical.drama@gmail. | |com
http://bugs.winehq.org/show_bug.cgi?id=35587
RaGreen marvin.nekromanta@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marvin.nekromanta@gmail.com
--- Comment #15 from RaGreen marvin.nekromanta@gmail.com --- I also confirm the issue.
Distro: Arch x86_64 Wine: 1.7.13 Kernel: 3.12 Sound system: Alsa
Before I used Ubuntu 12.04-13.10 and I have same bug. IMO something is wrong with loading sound system.
It's possible to play without sound, but it isn't too enjoyable.
http://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #16 from Riccardo c10ud.dev@gmail.com --- Tried another path: WINEDEBUG=+seh,+timestamp
those exceptions could be interesting? Something related to http://bugs.winehq.org/show_bug.cgi?id=27620 ?
http://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #17 from Riccardo c10ud.dev@gmail.com --- Created attachment 48156 --> http://bugs.winehq.org/attachment.cgi?id=48156 +seh,+timestamp
http://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #18 from Riccardo c10ud.dev@gmail.com --- Ok, I think I identified the issue.
When sound is enabled the game does a lot of overlapped io (mostly 4 bytes reads). 1963.535:0063:trace:file:CreateFileW L"C:/Riot Games/League of Legends/RADS/projects/lol_game_client/filearchives/0.0.0.209/Archive_2.raf.dat" GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE FILE_SHARE_DELETE creation 3 attributes 0x40000000 1963.535:0063:trace:file:RtlDosPathNameToNtPathName_U (L"C:/Riot Games/League of Legends/RADS/projects/lol_game_client/filearchives/0.0.0.209/Archive_2.raf.dat",0x33e8a8,(nil),(nil)) 1963.535:0063:trace:file:RtlGetFullPathName_U (L"C:/Riot Games/League of Legends/RADS/projects/lol_game_client/filearchives/0.0.0.209/Archive_2.raf.dat" 520 0x33e5f8 (nil)) 1963.535:0063:trace:file:wine_nt_to_unix_file_name L"\??\C:\Riot Games\League of Legends\RADS\projects\lol_game_client\filearchives\0.0.0.209\Archive_2.raf.dat" -> "/home//.wine/dosdevices/c:/Riot Games/League of Legends/RADS/projects/lol_game_client/filearchives/0.0.0.209/Archive_2.raf.dat" 1963.535:0063:trace:file:CreateFileW returning 0xf0
Interestingly many of them have the same arguments (???) eg:
1973.405:0063:trace:file:ReadFile 0xf0 0x33a424 4 0x33a230 0x3e11650 1973.405:0063:trace:file:ReadFile 0xf0 0x33a424 4 0x33a230 0x3e11650 1973.405:0063:trace:file:ReadFile 0xf0 0x33a424 4 0x33a230 0x3e11650
..and so on. Is this expected? Is further debugging needed?
You can check this out by running with WINEDEBUG=+tid,+timestamp,+file warning: the log will be really big.
http://bugs.winehq.org/show_bug.cgi?id=35587
Riccardo c10ud.dev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #47595|0 |1 is obsolete| | Attachment #48156|0 |1 is obsolete| |
--- Comment #19 from Riccardo c10ud.dev@gmail.com --- Created attachment 48212 --> http://bugs.winehq.org/attachment.cgi?id=48212 Test case for overlapped IO
compiled with: gcc -o testio.exe testio.c --std=c99
usage: wine testio.exe bigfile or, in windows: testio.exe bigfile
Sample runs.
WINDOWS: Large read: 16 for 0 bytes Small reads: 14265 for 0 bytes
WINE (ubuntu 14.04 x64, wine 1.7.16): Large read: 14 for 11128460 bytes Small reads: 53487 for 11128460 bytes
http://bugs.winehq.org/show_bug.cgi?id=35587
Riccardo c10ud.dev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #48212|0 |1 is obsolete| |
--- Comment #20 from Riccardo c10ud.dev@gmail.com --- Created attachment 48215 --> http://bugs.winehq.org/attachment.cgi?id=48215 Test case for overlapped IO - version 2
Better version of the test case, thanks to focht suggestions on #wine.
compile with: gcc -o testio.exe testio.c
usage: (windows) testio.exe bigfile (wine) wine testio.exe bigfile
sample run: - windows xp sp3: Large read: 15 for 11128460 bytes - overlapped: 0 Small reads: 14500 for 11128460 bytes - overlapped (total: 2782115): 2782115
- wine 1.7.16 ubuntu 14.04 x64 kernel 3.13.0-24-generic: Large read: 15 for 11128460 bytes - overlapped: 0 Small reads: 44849 for 11128460 bytes - overlapped (total: 2782115): 0
http://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #21 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Riccardo from comment #20)
sample run:
- windows xp sp3:
Large read: 15 for 11128460 bytes - overlapped: 0 Small reads: 14500 for 11128460 bytes - overlapped (total: 2782115): 2782115
- wine 1.7.16 ubuntu 14.04 x64 kernel 3.13.0-24-generic:
Large read: 15 for 11128460 bytes - overlapped: 0 Small reads: 44849 for 11128460 bytes - overlapped (total: 2782115): 0
It would be interesting to compare this to a not overlapped case, which I suspect will show the same results.
http://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #22 from Riccardo c10ud.dev@gmail.com --- (In reply to Dmitry Timoshkov from comment #21)
(In reply to Riccardo from comment #20)
sample run:
- windows xp sp3:
Large read: 15 for 11128460 bytes - overlapped: 0 Small reads: 14500 for 11128460 bytes - overlapped (total: 2782115): 2782115
- wine 1.7.16 ubuntu 14.04 x64 kernel 3.13.0-24-generic:
Large read: 15 for 11128460 bytes - overlapped: 0 Small reads: 44849 for 11128460 bytes - overlapped (total: 2782115): 0
It would be interesting to compare this to a not overlapped case, which I suspect will show the same results.
Hello Dmitry, you're right, without FLAG_FILE_OVERLAPPED the results are more or less the same for both Windows and wine.
http://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #23 from Riccardo c10ud.dev@gmail.com --- (In reply to Riccardo from comment #22)
(In reply to Dmitry Timoshkov from comment #21)
(In reply to Riccardo from comment #20)
sample run:
- windows xp sp3:
Large read: 15 for 11128460 bytes - overlapped: 0 Small reads: 14500 for 11128460 bytes - overlapped (total: 2782115): 2782115
- wine 1.7.16 ubuntu 14.04 x64 kernel 3.13.0-24-generic:
Large read: 15 for 11128460 bytes - overlapped: 0 Small reads: 44849 for 11128460 bytes - overlapped (total: 2782115): 0
It would be interesting to compare this to a not overlapped case, which I suspect will show the same results.
Hello Dmitry, you're right, without FLAG_FILE_OVERLAPPED the results are more or less the same for both Windows and wine.
It looks like this issue is actually two different issues: - Commenting out (or, actually, disabling for type=FD_TYPE_FILE) send_completion in ntdll/file.c NtReadFile brings down my test case execution time from 55s to 5s in wine. See relevant line: if (send_completion) NTDLL_AddCompletion( hFile, cvalue, status, total );
- The fact that we're not doing overlapped IO locks the game UI for a while during load
game load time: - with send_completion: ~120s to load - without send_completion: ~105s to load
I think the game issue is a mixture of those two: the game may crash for slow systems because it might remain "locked" for a while (no overlapped IO)..and it's even a bit slower than it should because of the NTDLL_AddCompletion call.
http://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #24 from Riccardo c10ud.dev@gmail.com --- (In reply to Riccardo from comment #23)
(In reply to Riccardo from comment #22)
(In reply to Dmitry Timoshkov from comment #21)
(In reply to Riccardo from comment #20)
sample run:
- windows xp sp3:
Large read: 15 for 11128460 bytes - overlapped: 0 Small reads: 14500 for 11128460 bytes - overlapped (total: 2782115): 2782115
- wine 1.7.16 ubuntu 14.04 x64 kernel 3.13.0-24-generic:
Large read: 15 for 11128460 bytes - overlapped: 0 Small reads: 44849 for 11128460 bytes - overlapped (total: 2782115): 0
It would be interesting to compare this to a not overlapped case, which I suspect will show the same results.
Hello Dmitry, you're right, without FLAG_FILE_OVERLAPPED the results are more or less the same for both Windows and wine.
It looks like this issue is actually two different issues:
- Commenting out (or, actually, disabling for type=FD_TYPE_FILE)
send_completion in ntdll/file.c NtReadFile brings down my test case execution time from 55s to 5s in wine. See relevant line: if (send_completion) NTDLL_AddCompletion( hFile, cvalue, status, total );
- The fact that we're not doing overlapped IO locks the game UI for a while
during load
game load time:
- with send_completion: ~120s to load
- without send_completion: ~105s to load
I think the game issue is a mixture of those two: the game may crash for slow systems because it might remain "locked" for a while (no overlapped IO)..and it's even a bit slower than it should because of the NTDLL_AddCompletion call.
I tricked the game, in dlls/kernel32/file.c NtReadFile add:
if (status != STATUS_PENDING && bytesRead) { *bytesRead = io_status->Information; + if (cvalue) { + // http://support.microsoft.com/kb/156932?ln=en-us + // even if we did a sync read tell the client we didn't so it can process its events + SetLastError( RtlNtStatusToDosError(STATUS_PENDING) ); + return FALSE; + } }
this will cause the user to call GetOverlappedResult in order to get the data (and theoretically execute something in background meanwhile).
25532.065:trace:file:ReadFile 0xe4 0x33c5e8 4 0x33c440 0x3e11650 25532.065:trace:file:GetOverlappedResult (0xe4 0x3e11650 0x33c444 0)
as you can see from this snippet of a new trace the trick works.
However loading time or UI responsivity are not improved at all and I think the conclusion here is that this is not a bug in wine.
The game should really read more than 4 bytes per call...
As for the NTDLL_AddCompletion slowness, since I doubt anything is doing 2M calls for a single file, I wouldn't just mind about it.
http://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #25 from Riccardo c10ud.dev@gmail.com --- Fixed by Riot in Beta client, hopefully next patch will contain this fix!
http://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #26 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Riccardo from comment #25)
Fixed by Riot in Beta client, hopefully next patch will contain this fix!
Invalid then since it was a game issue?
http://bugs.winehq.org/show_bug.cgi?id=35587
s1w_ muad@go2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |muad@go2.pl
--- Comment #27 from s1w_ muad@go2.pl --- always a game issue, lol is so weak programmed that i havent near simmilar game in my cybercafe making so much trouble as lol. shop, icons, lags, minimalizing, loosing keyboard, graphical artifacts, hanging during launch etc etc...
check for wot programmers....... their game never made a single problem, being emulated it runs better than on winshit, it cooperate with ubuntu gl etc..
nevermind. loading problem in LoL still exists, why this bug have still status unconfirmed?
http://bugs.winehq.org/show_bug.cgi?id=35587
bugzilla@dolphinling.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla@dolphinling.net
--- Comment #28 from bugzilla@dolphinling.net --- (In reply to Riccardo from comment #25)
Fixed by Riot in Beta client, hopefully next patch will contain this fix!
It appears the fix for this is part of a rewrite of the entire audio system in LoL. It's still in development, and is occasionally added to the beta client for a short time for testing, but won't be pushed to the live client for a while.
http://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #29 from Riccardo c10ud.dev@gmail.com --- (In reply to bugzilla from comment #28)
(In reply to Riccardo from comment #25)
Fixed by Riot in Beta client, hopefully next patch will contain this fix!
It appears the fix for this is part of a rewrite of the entire audio system in LoL. It's still in development, and is occasionally added to the beta client for a short time for testing, but won't be pushed to the live client for a while.
It's fixed with the new audio system (Wwise) but for a brief time, it was fixed with FMOD too.. now it's broken again.
Here's a link to the upstream bug.
http://community.pbe.leagueoflegends.com/en/c/bugs/12eEfQsI-fmod-systemsetfi...
http://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #30 from Riccardo c10ud.dev@gmail.com --- I think with patch 4.12 and the switch from FMOD to Wwise sound engine this is not reproducible anymore.
http://bugs.winehq.org/show_bug.cgi?id=35587
Sakse Dalum dons@yodanism.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dons@yodanism.org
--- Comment #31 from Sakse Dalum dons@yodanism.org --- I can indeed confirm, that with League of Legends patch 1.7.12, this is no longer a problem.
http://bugs.winehq.org/show_bug.cgi?id=35587
--- Comment #32 from Sakse Dalum dons@yodanism.org --- (In reply to Sakse Dalum from comment #31)
I can indeed confirm, that with League of Legends patch 1.7.12, this is no longer a problem.
Patch 4.12, obviously.
http://bugs.winehq.org/show_bug.cgi?id=35587
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |focht@gmx.net Resolution|--- |FIXED
--- Comment #33 from Anastasius Focht focht@gmx.net --- Hello folks,
reported 'fixed' multiple times.
Regards
http://bugs.winehq.org/show_bug.cgi?id=35587
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |matteo.mystral@gmail.com
--- Comment #34 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to Anastasius Focht from comment #33)
Hello folks,
reported 'fixed' multiple times.
Regards
AFAIU it was "fixed" on their end, so most likely this should be closed ABANDONED or UPSTREAM.
https://bugs.winehq.org/show_bug.cgi?id=35587
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED Resolution|FIXED |UPSTREAM
--- Comment #35 from Austin English austinenglish@gmail.com --- (In reply to Matteo Bruni from comment #34)
(In reply to Anastasius Focht from comment #33)
Hello folks,
reported 'fixed' multiple times.
Regards
AFAIU it was "fixed" on their end, so most likely this should be closed ABANDONED or UPSTREAM.
UPSTREAM.