pauleve/docker-mtgo

Mtgo freezing 30 seconds every ingame action

MrCarri opened this issue · 26 comments

MrCarri commented

Using latest image, mtgo:2020-09-18, and issue102:

I'm experimenting mtgo freezes every action for about 30 seconds, and then updates the clock. I'Collection and deck building is slow but doable. How could I debug it, so I can post more information?

pauleve commented

Thanks for the report. Looks similar to #68
A few information:

  • are you on Linux or macOS?
  • ./run-mtgo --debug &>output.log and post the file output.log in a comment
MrCarri commented

There it is, I've played a game for a few turns, and then concede. I've noticed it gets sluggish when there's a lot of cards involved, for example when 4 or 5 cards go to the graveyard at once. The both clock stops, and then they update after a while. Sorry for not getting into more detail yesterday, I'm on linux (fedora 32), with the kernel 5.8.11, and a AMD fx-8350 and 8 GB of RAM in case that helps.

I've included the output log as a file, since It's pretty long.

output.log

pauleve commented

Thanks - nothing strange here, I get a very similar output..
Can you post the output of docker info as well? When it gets sluggish, are the art of cards already displayed?
During a deck building or game session, is there a high CPU usage?
Is it getting worst the more you play, or is it progressively getting smoother?

From #68, using an old image may help - but now it requires a workaround:

./run-mtgo panard/mtgo:wine-4.9
(prompt) wine /opt/mtgo/mtgo.exe

let me know if it gets smoother

If you feel adventurous enough, you can give a try using wine outside docker, by installing winehq-devel using https://wiki.winehq.org/Fedora and then by following for instance this guide https://github.com/pauleve/docker-mtgo/wiki/macOS:-installing-MTGO-using-Wine from step 3 or https://appdb.winehq.org/objectManager.php?sClass=version&iId=32007 ; it could be very helpful to see if it's due to wine or a weird bug with the docker image..

MrCarri commented

Yeah sure :)

dockerinfo.log

I'm not sure if I'm executing the old image, I'm using

./run-mtgo panard/mtgo:wine-4.9 $wine /opt/mtgo/mtgo.exe

and I'm getting a crash when I'm writing the password (I'm not sure I'm executing it correctly)

output49.log

I will try to install it via wine today, I haven't had time. :)

pauleve commented

Ah, I pushed a fixed for the wine 4.9 image:
just ./run-mtgo --update panard/mtgo:wine-4.9 should work now

serokellcao commented

Any updates on this one? 4.9 just works?

UPD:

It seems to work better. It might be some sort of cognitive bias, but I remember MTGO working smoother before the "new UI" update.

Is there anything I can do to help investigate?

serokellcao commented

Another informal report:

It seems like when I disconnect an external display, the lag almost disappears (tested on 4.9).

Also, the more content gets buffered by MODO, the less lag there is.

pauleve commented

Interesting - does disconnecting the second monitor also improve the freezes with the latest wine, using
./run-mtgo --update --test panard/mtgo:pr106?
Post-wine 4.9 introduced a lot of changes regarding X11 and multimonitor handling... @MrCarri do you also have a multimonitor setup?

Regarding buffered content, yes, I also observe that as well; but the lag is not really bad, nothing that locks the game for several seconds.

pauleve commented

Ah, and if it is indeed related to multimonitor, you may want to try enabling "Emulate virtual desktop" you can tick using with the --winecfg argument to ./run-mtgo (in the Graphics tab, you need to enter your resolution manually).
I'm also interested in the CPU usage during the freezes (top output or similar).

MrCarri commented

Nope, I only have one monitor. I will try to test it out tomorrow. I've just started a new job and haven't got much time lately :)

serokellcao commented

Testing panard/mtgo:pr106. It complained about .NET (sorry, didn't manage to catch the error), but got:

0128:err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or isy, you can find it in the winbind package of your distribution.
0130:err:vulkan:get_vulkan_driver Wine was built without Vulkan su
0128:err:ole:apartment_getclassobject DllGetClassObject returned e
0128:err:ole:com_get_class_object no class object {1e66f26b-79ee-1
0174:err:ole:apartment_getclassobject DllGetClassObject returned error 0x80131700 for dll L"mscoree.dll

and

image

Next time I play on 4.9, I'll do my best to capture mpstat and other load output as the game progresses.

Update:

I have an annotated CPU / mem usage capture over the course of an hour of playing MTGO, but it's not worth posting it here since it was stable on 69.6%±3% total and memory was stable too,

All the freezes have to do with caching / loading resources and are the same as Windows users report.

Moving forward I'll test it with the newest Wine, but so far it seems like the solution to all the freezes is — just use 4.9 and keep using it till it stops lagging.

MrCarri commented

Well, having tested version 4.9, definitely works better. I had freezes only in the first 2 minutes of the game, and then it went quite well. I play a click intensive deck, and I was losing about 1 second every time I clicked and got a response, not a big deal since I'm playing in TP mostly. Latest version freezes feel like io/wait, and maybe its related to my hardware. I'm getting a new SSD soon, so I will reinstall everything on another distro, to see if it improves :)

Also (and kinda unrelated) I've testing installing from wine directly without the docker container, and since it takes more than one hour to install .net 4.6 (or a lot, never finished it) ended giving up on it., I'm not sure if it's just me again, though. Also, lutris mtgo installer, doesn't work either. Managed to run it once, and then it broke somehow. I've been using virtualbox lately and it works, so it's not like I'm not playing, but 4.9 is definitely playable, specially if you don't go to deckbuilding and play click intensive decks.

kylemarkwilliams commented

Just wanted to add that I'm also having this issue and it makes play pretty unfun.

I tried with the latest master image as well as panard/mtgo:pr106.

pr106 is a little bit better than master but it still freezes frequently enough to hamper play.

pauleve commented

@kylemarkwilliams have you tried with the wine-4.9 image? From above comments it might help..

Can you post the output of docker info ?

If it is related to caching / loading resources, the file system used by docker may play a big role here.. I'm using btrfs and have very few lags (mainly in the first minutes of launching the app..)

kylemarkwilliams commented

@pauleve I have not tried Wine 4.9, so I'll give that a go next time I play.

My fs is ext4, but it always has been and it hasn't been an issue before. I've been using this project for years now with no problems. I recently came back after a break from magic and found it to be lagging.

Here is the output of docker info

Containers: 1
 Running: 0
 Paused: 0
 Stopped: 1
Images: 10
Server Version: 18.06.1-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 468a545b9edcd5932818eb9de8e72413e616e86e
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 5.4.0-54-generic
Operating System: KDE neon User Edition 5.20
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.37GiB
Name: anubis
ID: ZPP7:OOTX:XFPL:2JEW:TTID:HE53:OQ27:LQ7F:I2UJ:QHV6:KGWC:VZG5
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support
pauleve commented

Given your setup, Docker is probably not the issue indeed.

Are you on KDE Plasma? I did some brief tests and it might be that it feels slower when I'm using KDE rather than Unity or GNOME ; but I need to do more tests to confirm that..
By chance, do you have the possibility to easily try with a different desktop manager? Alternatively you may try doing

./run-mtgo --winecfg

and in the Graphics tab, select "Emulate a virtual desktop"

Also do you experience the freezes only during a game, or even when navigating tabs/building a deck/trading/...?

MrCarri commented

Well, after a few days, I've managed to fix it. While I was doing experiments with docker at AWS for a web application I'm developing for work, I discovered RHEL and fedora use an alternative of docker called podman because Red Hat parted ways (you maybe know this, but I didn't at the time). So after testing a little bit, tried to run this image on podman, and gave up. Checked the docker version I had, and compared with the one in official fedora repos, and turns out the docker version that comes is not the most updated, since they prefer you use podman.

Also, it crashed sometimes on this docker image because it had the inodes limited to a small number, don't really know why. In the end was using a kinda old version of docker, installed the newest one (4 days ago while writting this comment) directly from docker repo, and It was supposed to work well in fedora, but for me it couldn't start on systemctl.

So, to not making this comment much longer, I got back to arch, found the most updated version of the image still froze my system (probably due to hardware) and then I installed 4.9, and it just works great.

In conclusion, I got back to arch, got fed up of fedora due mutliple issues at work and in my workstation, and at least now I can play normally. Thanks for the help :)

  • 🎉2
pauleve commented

Thanks for the detailed feedback, and happy to hear that it is working well for you now :-)
OK, so the panard/mtgo:wine-4.9 is definitely much more stable than more recent ones; I would like to understand why, but probably that in the meantime I'll make it the default image.

vivaria commented

Hullo! Popping in to try and add my experiences to the pile. This probably isn't all that useful given the edit in #107 (comment) seems to have roughly pinpointed the problem, but, here you go. (A big thanks for maintaining this, too. 😄)

Environment

Output of docker info 
viv@XPS-15-9560:~$ docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Build with BuildKit (Docker Inc., v0.5.0-docker)

Server:
 Containers: 1
  Running: 1
  Paused: 0
  Stopped: 0
 Images: 2
 Server Version: 20.10.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc version: ff819c7e9184c13b7c2607fe6c30ae19403a7aff
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.4.0-58-generic
 Operating System: Ubuntu 20.04.1 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 7.629GiB
 Name: XPS-15-9560
 ID: A7PG:A4OE:5DTJ:LX2W:GCZT:V33S:4MDV:OJD7:NU4B:JKJR:GLWD:43NC
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No swap limit support
WARNING: No blkio weight support
WARNING: No blkio weight_device support

Single-monitor setup (laptop) with power management set to always use my laptop's GPU (GTX 1050).

Anecdotal info

My experience is very similar to what's described in #107 (comment).

  • I only ever draft (vintage cube, etc.) so my experiences are mainly draft picks + matches.
  • No noticeable difference between readme steps and ./run-mtgo --update panard/mtgo:wine-4.9. (You may have already made this the default image, though.)
  • MTGO freezes for 4-5 when clicking through menus, but only on tabs I haven't clicked on before. After the first click per tab, I can then switch between tabs without too much lag.
  • In draft, after taking a card, the draft may freeze for 30s, but I can't reliably trigger it. It happens 1-3 times per draft.
    • Unrelated: Clicking and dragging a card to pick it doesn't always work. I can't reliably trigger this either.
  • In matches, the game sometimes freezes for 10-15s, but it only happens 2-3 times a match, if that. The rest of the time it still feels sluggish, but good enough to play.

All and all, not the worst, but losing a draft pick or falling behind on time can be a bit stressful. It's close enough to usable for me to keep trying, though. 😝

pauleve commented

Do you have an nvidia graphics card? If so, #132 may be worth a try:

  1. install nvidia-container-toolkit, aka nvidia-docker2
  2. update the run-mtgo script
wget -O run-mtgo https://raw.githubusercontent.com/pauleve/docker-mtgo/master/run-mtgo
chmod +x run-mtgo
  1. use ./run-mtgo -- --gpus all panard/mtgo

Let me know if helps or not...

jathanasiou commented

@MrCarri & @pauleve I've been having this issue as well for a while, seemingly irrelevant of wine version and even without docker (plain wine and/or lutris runs).

I played a quick match with multiple occasions causing this "UI Freeze" effects from 5secs up to 1-2 mins. This is on KDE Plasma.
Then, without any change in my run method I rebooted into an Openbox session.
There were some flickering effects when alt-tabbing the game's windows but there were 0 freezes and the animations (eg tap/untap) were smoother than I've seen in quite a while.

I think it's reasonable to say this issue is DE/window-manager dependent. I also suspect that compositing WMs might be the actual cause though toggling compositing (via system settings) on Cinnamon/Plasma makes no difference for me. I will continue experimenting.

  • 👍1
serokellcao commented
jathanasiou commented

I'm confirming that I had freezes on non-compositing XMonad on Ubuntu 20.04.

This is so weird... Even though the Plasma "start without compositor" setting didn't help I just now managed to KWIN_COMPOSE=N pre-login and this seemingly makes my MTGO behave much more consistently.

Is there a chance that someone between you,me and OP have a "different kind of freezing" ?

serokellcao commented
kylemarkwilliams commented

Commenting on this issue 1.5 years after reporting that MTGO kept freezing for me as well.

It is working pretty much perfectly now. Only minor issue is that right click takes about 5 seconds to respond. Same hardware and OS (KDE Neon), but just with latest updates and a fresh run of ./run-mtgo -reset.

Docker info in case it's useful.

Containers: 1
 Running: 0
 Paused: 0
 Stopped: 1
Images: 12
Server Version: 18.06.1-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 468a545b9edcd5932818eb9de8e72413e616e86e
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 5.11.0-43-generic
Operating System: KDE neon User - Plasma 25th Anniversary Edition
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.36GiB
Name: anubis
ID: ZPP7:OOTX:XFPL:2JEW:TTID:HE53:OQ27:LQ7F:I2UJ:QHV6:KGWC:VZG5
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false
pauleve commented

Closing old inactive bugs. Feel free to open a new issue if still occurring, with info on Linux distribution, window manager, graphics card, and docker info