Anki 2.1.36 Beta

Could I trouble you to confirm the issue doesn’t exist in beta 1? It will be helpful to know if this is a regression in the code or some change in Big Sur.

I downloaded some prior versions and tried to recreate it. I was having issues with the Browser side-by-side initially and then had it without using that add-on. Today I was able to recreate the issue with browser side-by-side all the way back to 2.1.30, but I couldn’t recreate it on any versions in a normal browser view today, despite being able to previously recreate the problem. May be an issue with Big Sur? Happy to provide a video if it would be helpful

It does sound like an issue with the OS update if you weren’t seeing it previously - thanks for trying to reproduce it, and let’s hope it doesn’t come back in the normal browser view at least.

@dae In beta 2 and beta 3, searching “tag:marked” in the browser is not working.

I just tried a clean install of beta 3 on windows (including deleting the appdata folder) and when launching anki I got this error:

Screenshot 2020-11-27 08.59.12

I had to install the stable version (2.1.35) first and then install beta 3 on top of that to get it to launch.

This was recently fixed in the development version.

Works for me using the latest development code - if Tools>Check Database doesn’t help you, please try again when the next beta comes out.

Indeed it is working (tag:marked). I don’t know what was happening. Thanks!

In Beta 3, the deck name in the title of the deck options window is wrapped in some control characters. This is independent of the deck and didn’t happen with the last stable.


I sent a PR to fix this and other strings a few days ago here:
If you found other places where the control characters need to be stripped, please report them too.

1 Like

That’s great! I couldn’t reproduce this anywhere when building from master. :smiley:

Beta 4 is now available.

Hi, not sure if this is really an issue, but I wanted to report it nevertheless.
I noticed that the webviews used in Anki’s interface constantly eat RAM, in small steps, that is only released the webview is destroyed. I don’t really know if that is expected behaviour?
The issue is on all webviews as far as I can tell. RAM usage steadily increases as soon as the mouse is moved (!), and stops increasing if the mouse is idle. In the Add dialog, I could not observe the memory being freed at some point, unless I close it.

The following short demo illustrates the issue in the Add window, all add-ons are disabled, 2.1.36.

I would estimate it is like 1Mb every 2.5s if you keep busy. Now that might be a non-issue if you just open the Add dialog for a limited amout of time or regularly close and reopen it, but I am running a javascript-heavy add-on in the Add window, whose state is destroyed if I have to reopen the dialog, and which makes me spend quite some time in the Add window.

Edit: Also, the memory usage increases really fast on resizing the window, a short demo:

This time, the memory seems to not be allocated in the webengine process, but rather in the main thread.
Edit 2: The memory increase on resize seems to be even larger if the resized window is big in size, e.g. if I drag the main window on a 1080p screen, vertically max-sized, the RAM jumps in like 70-100mb batches.
This is after resizing the main window from left to right (like in the last gif) for like 30-60s.

Edit 3: Maybe this has to do with Hardware Acceleration being enabled, but unfortunately I cannot test if the issue persists without, as I cannot disable it.


This error occurs everytime I uncheck Hardware Acceleration, and if I restart Anki afterwards, the box is checked again (it used the “Auto” gldriver setting then). I definitely have the newest driver for my graphics card (Intel HD Graphics 620).


The memory-grows-on-mouse-movement issue seems to exist in macOS as well, but resizing doesn’t seem to leak on macOS. Looks like yet another Qt bug. :frowning:

1 Like

Any idea how I could try to disable Hardware acceleration to see if the issue persists?

The issue seems to exist with and without hardware acceleration.

Thanks. I think I am gonna file an issue on the Qt issue tracker

I’ve got no idea anymore how to install Anki properly on my Arch. That is, with building a package and properly installing it that way.

qt/linux/ doesn’t copy the actual program files at all (just some irrelevant ones) but only creates a broken symlink of anki to the temporary build folder. As I understand, this isn’t because a proper packaging $PREFIX isn’t set (it is), but since cp -av * ${PREFIX}/share/anki/ no longer reaches/copies the relevant files as those now reside in some external bazel folder.

Seeing that the installation method changes/breaks a perceived every two versions I’m not really keen on investing more time to find out where/unbreak it. Arch’s packager (along others like Gentoo’s) likewise seems to be unwilling as he already skipped versions past 2.1.26 and only did .35 after the python 3.9 rebuilds forced him to.

[This wouldn’t be so bad if I could just use ./run's build, but it fails to load the IM module (fcitx5) and for about a week or so using the card browser has become prohibitively slow with my larger collection.]

e: Another issue, but with git: D&Ding a mp3 in the browser doesn’t work (plays, but in 90% doesn’t drop and in 10% into the wrong field).

Beta 5 is now available, and is expected to be released as stable in a day or two if no issues crop up.

@nwwt I have made some tweaks to the docs based on your feedback. If you wish to use your system Qt installation, you should follow the steps in the “Building redistributable wheels” section. That will also create an optimized build, which should solve the speed issues you’re having.

Thank you, following that it works again. Two minor issues in that ① bazel writes outside the build directory into ~/.cache, which I don’t care about but probably is an anathema to formal packagers, and ② with ccache one’s got to set export CC & CXX (since bazel will fail when the former tries to access its cache outside the sandbox).

e: Re. the reply: Alright, it’s just that traditionally ccache is “prepended” on Linux via those env vars. You might include a CCACHE_DISABLE=1.