Changelog

Release history for ARTGTO, newest first. All versions during closed beta carry the -beta suffix.

[0.9.34-beta]

Fixed

• A minimized window no longer eats memory during a batch. This was the true root of the week's memory mystery. Every frame the app draws first prepares small upload buffers, then asks Windows for the screen surface to present on. A minimized window refuses that request, the frame is skipped, and the buffers that were already prepared are never released. No error is raised anywhere, so every earlier defense looked past it. With the app minimized during a batch, the leak ran at about 150 buffers per second; the telemetry from 0.9.33 recorded ten gigabytes accumulating in eleven minutes, the export gate then waiting on the very memory the window had eaten, and everything releasing the moment the window was restored. The order is now reversed: the app asks for the screen surface first and prepares upload buffers only when the frame can actually be shown. Verified by running a batch minimized for four and a half minutes: buffer count held at six, where the same scenario previously stranded tens of thousands.

[0.9.33-beta]

Fixed

• The heavy system lag some batches caused at their start is addressed. When the app itself held a large pool of reusable memory, the first helper process to load a spot forced Windows to write that pool to the page file mid-load. The disk work of both collided, and the whole PC lagged for minutes; one measured stall took seven minutes. A batch now releases and pages out the app-side pool before the first helper starts, while the disk is otherwise idle, so the cost is a brief hitch at batch start instead of a stall in the middle.
• Browsing a solution no longer parks the memory it used. Opening a spot in the app rebuilds the solution and recomputes its equities, which churns several gigabytes through the memory allocator. The solve and export paths have always returned that memory afterwards; the interactive open path did not, so one browse could hold gigabytes for the rest of the session. It returns the memory now, and closing or replacing a solution does the same.

Added

• The log records when the app itself grows. Any jump of more than a gigabyte in the app process is written to the log together with what the app was doing at that moment. One session this week grew ten gigabytes from a source that could not be identified afterwards; the next time it happens, the log will name it.

[0.9.32-beta]

Changed

• Each spot in a batch export now runs in its own helper process. The app's memory allocator keeps most of a process's peak memory for reuse and only returns it when the process exits. Inside one long-running app that meant every batch dragged 10 GB and more of reusable-but-not-free memory along, which held free RAM low, caused the between-spot waits, and quietly limited every recorded batch to a single worker. A helper process gives everything back the moment its spot finishes, so free RAM stays high through whole runs, waits become rare, and the worker pool can size itself to real parallelism again. Starting a helper costs one to two seconds per spot against exports that take minutes. The exported files are byte-for-byte identical, and a failure in one spot can no longer disturb the app itself.

[0.9.31-beta]

Fixed

• The display pause no longer blanks the window or interrupts normal use. 0.9.30 paused all drawing whenever free memory dropped below a fixed level. That level is crossed briefly during every large spot load, and a fully paused window could show solid black, which looked like a crash. The pause is now driven by actual drawing failures instead of a memory number: while failures are occurring, drawing rests for two seconds at a time, then tries one normal frame. A clean frame restores normal display at once, so in ordinary use, exporting included, the app looks and behaves exactly as it always did. Only when failures persist does the display hold its last image, and the window title then says the app is paused for memory and still working. The title returns to normal when drawing recovers.

[0.9.30-beta]

Fixed

• The self-feeding memory pinning during batch exports is fixed at its source. 0.9.29's renderer report identified the mechanism within hours: when the machine runs out of memory, frames fail partway through drawing, and each failed frame strands the small staging buffers it had already allocated. One measured episode held 225,543 stranded buffers totalling 15.4 GB, all freed at once by the first frame that succeeded. The stranded memory pinned RAM, which made more frames fail, which stranded more memory. The app now skips whole frames while free memory is critically low, before any allocation happens, so nothing can strand and the loop cannot start. The window shows its last image until memory recovers; solving and exporting continue underneath.

[0.9.29-beta]

Changed

• The interface slows to about one refresh per second while the machine is critically low on memory. During this week's batch runs, the graphics driver periodically pinned up to 15 GB of system memory on the app's behalf. That memory shows in no process list, which is why Task Manager never explained the shortages. The episodes only ever ran while the app was drawing at full rate into an already starving machine. Below 2 GiB of free RAM the idle refresh now drops to one frame per second; moving the mouse still repaints instantly, and the normal rate returns as soon as memory recovers.

Added

• The renderer reports its own memory use during a batch. Once per minute of active export, the log records how many graphics buffers and textures the app itself holds and how much memory they use. The first measurements show the app's own graphics allocations stay near 1 MB while the driver pins gigabytes, so the next episode will document itself and say which side grew.
• Start the saved export queue from the command line. Launch with ARTGTO_AUTOSTART_LIBRARY=1 and the app starts the saved Library queue on its own and opens the Library tab, exactly as if Export had been clicked. Useful for launch-and-walk-away overnight runs.

[0.9.28-beta]

Changed

• A spot that cannot get memory is now retried, not lost. When free RAM stayed short, each waiting spot used to give up after ten minutes and count as a failed export. A shortage on one machine lasted 52 minutes and cost five spots that way, with each one spending the full ten minutes waiting first. A spot that runs out of patience is now set aside, the batch moves on at once, and every set-aside spot is retried after the rest of the run has finished and released its own memory. Only a spot refused twice counts as failed. While a shortage is in progress the wait per spot also drops from ten minutes to two, so the batch skips through the affected stretch instead of stalling on every spot in it. Set ARTGTO_EXPORT_RAM_TIMEOUT_SECS to change the full wait if your machine releases memory more slowly.

Added

• Headless export from the command line. artgto.exe --batch-export <in_dir> <out_dir> runs the same batch pipeline the Library tab uses, with its resume skip, memory gate, and the new retry, without opening a window. --reexport-artgto also accepts a folder now and converts every .art in it in turn.

[0.9.27-beta]

Fixed

• The exporter returns each finished spot's memory to Windows right away. The app's memory allocator keeps freed memory for reuse instead of handing it back to the system. Across a long batch that added up to roughly one spot's memory per finished spot. Windows moved the idle pages to the page file, and the multi-gigabyte flushes that followed made free RAM collapse to zero for minutes at a time while the exporter itself sat waiting in its own memory gate. A spot could then fail its wait while the app held the very memory it was waiting for. The batch solve runner has released its memory after every job since it hit this same problem; the export loop now does the same after every spot.

[0.9.26-beta]

Fixed

• Exporting needs less than half the memory it did. Loading a spot for export rebuilt the solver the same way a live solve does. That allocated a full-size buffer for solver-internal data the export never reads, and it expanded the whole file through several temporary copies on the way in. Both are gone: the unused buffer is no longer created, and the file now streams directly into its final place in memory. Measured on a real spot, peak memory use drops from 11.9 GB to 5.0 GB. The exported file is byte-for-byte identical to what previous versions produced.

Changed

• The between-spot memory wait is sized per spot. 0.9.24 made the exporter wait for a flat 10 GiB of free RAM before each spot. The exporter now measures each spot's actual size first and waits only for what that spot needs, so small spots start without waiting. A spot too large to ever fit in this machine's RAM is reported as a failed export right away instead of holding the batch for the full timeout.

[0.9.25-beta]

Fixed

• The last way for an out-of-memory frame to close the app is gone. 0.9.24 taught the app to treat a refused graphics allocation as a dropped frame instead of a fatal error, and its log shows that working. But the drawing library the app is built on contained a second stop of its own: when its request for frame memory came back empty, it closed the app itself. This stop ended a batch export at 1.4 GiB free RAM, one layer past the 0.9.24 guard. The app now ships its own copy of that library with the stop removed: a frame that cannot get memory is drawn stale or blank, the failure is recorded in the log, and drawing recovers on its own once memory is available again. Nothing else about the library is changed.

[0.9.24-beta]

Fixed

• Running out of memory during a batch export no longer closes the app. Exporting a spot rebuilds the whole solution in memory, which is several gigabytes. When that drove free memory to zero, the graphics driver refused the renderer's next allocation, and the app treated every graphics error as fatal: one undrawable frame closed the app in the middle of a batch. A graphics error is now written to %APPDATA%\artgto\artgto.log and that frame is skipped; the app keeps running and the batch keeps exporting.

Changed

• The batch exporter waits for memory between spots. Before loading the next spot, a worker now waits until at least 10 GiB of physical RAM is free, so the previous spot's memory has actually been released before the next multi-gigabyte load begins. The progress display shows the wait. If the memory does not come back within 10 minutes, some other program is holding it. The spot is then recorded as a failed export with the reason and the batch moves on. Running the same export again later picks up exactly the skipped spots.

[0.9.23-beta]

Fixed

• A failed export now says what went wrong. When exporting a spot failed, the app counted the failure and deleted the partial file, but the reason went to standard error. A release build has no console, so nothing received it. You saw a failure count with no explanation, which is why these read as silent crashes. Every message on the export path now goes to %APPDATA%\artgto\artgto.log, naming the spot and the reason.
• A runout that fails to export no longer disappears without a word. If one section of a spot failed, it was dropped from the file's index while the export still reported success. The result was a spot that looked complete but could not open that runout. The drop is now recorded in the log, and it says the exported file is incomplete.

Changed

• The frame diagnostic added in 0.9.22 is off by default. It wrote one line per second whenever the window was in use. The log file is capped at 1 MB and discards the oldest entries when it fills, so the diagnostic was crowding out the crash and export records the log exists to keep. Set ARTGTO_FRAME_LOG=1 to turn it back on while investigating a display problem.

[0.9.22-beta]

Fixed

• Moving the window lagged behind the cursor. Moving a window does not change what the window shows. The app was still drawing a complete frame for every mouse movement, then waiting for the display refresh before presenting it. Windows runs its own loop while you drag, so each of those waits held up the drag. The app now presents these frames without waiting for the refresh. Resizing was never affected, which is what isolated the cause, because resizing takes a different path internally. The effect is most visible on high-refresh monitors. To restore the previous behaviour, start the app with ARTGTO_PRESENT=vsync.

Added

• The log records the graphics backend and per-frame timings. At startup the app writes which graphics backend and adapter it selected. While running it writes two numbers per second: the time spent drawing a frame, and the wall-clock time between frames. The two values diverge when the app is waiting on the display rather than on its own work, which is what this bug was.

[0.9.21-beta]

Fixed

• Clicking Update could close the app without installing the new version. This is the cause behind reports that the app downloads an update, closes, and does not come back. The download and the installer were never at fault. The app crashed while the progress dialog was open, a few seconds into the download, so the installer never started. The progress bar requested an infinite layout width. Most controls clamp that value; the progress bar does not, so the next control in the dialog received an invalid position, and hit-testing failed as soon as the pointer was over the dialog. The pointer is always over the dialog at that moment, because you have just clicked Update there. That is what made the failure look intermittent, and why retrying sometimes worked. The fix takes effect in the version you install, not the version you are running, so on 0.9.19 or 0.9.20 you may need to run the installer manually once. If an update fails again, %APPDATA%\artgto\artgto.log records the download, the handoff to the installer, and any crash with a backtrace.

[0.9.20-beta]

Changed

• Exported .artgto files are about a quarter of their previous size. The file name, the extension and the contents are unchanged. A solve you export now holds the same strategies, weights and equities it did before. One full 3-bet-pot spot goes from 910 MB to 239 MB.

The change is in how a spot stores its river and turn sections. Each section used to be a separate compressed document that repeated the same field names, combo identifiers and strategy matrices thousands of times. Sections are now a compact binary layout, and the strategy matrices and combo lists that repeat between runouts of the same board are stored once per group of sections and referenced.

Two things follow from this. Files written by 0.9.20 are format version 2, and an older viewer refuses to open them; the updated viewer reads both, so your existing library keeps working. And existing libraries do not need re-solving, because a .art file already holds everything the exporter needs.

Added

• --reexport-artgto converts a solved .art file without the GUI and without re-solving. Run artgto.exe --reexport-artgto <in.art> <out_dir> [--zstd N]. This is the supported way to bring an existing exported library up to the current format. The strategies live in the .art file at full precision, so the conversion is a rewrite rather than a re-solve.

[0.9.19-beta]

Changed

• Batch runs skip a cache they never use. After every solve the app used to compute a full expected-value cache, a single-threaded walk over the entire tree taking roughly 10 to 30 seconds per board, and then discard it. The .art save keeps only the strategy, and the viewer has always rebuilt those values when you open a file. Nothing you see when browsing a solution changes. This applies to batch runs only; interactive solves are untouched.
• Capped batch runs check exploitability less often. Each convergence check costs about three iterations of work. Interactive solves keep the every-50 cadence, because early stopping depends on it. Batch jobs now scale the cadence to the run length, so a 200-iteration job checks at 1, 100 and 200 instead of five times. Library-style runs essentially never reach the early-stop target, so the skipped checks were pure overhead. Expect per-board batch times to fall by roughly 7 to 18 percent, to be measured on the next production batch. One consequence: a board that would have stopped early now runs a little longer and finishes less exploitable, so its solve is not byte-identical to one produced before this change.
• Fresh installs seed corrected preflop range templates. 4-bet-pot defending ranges keep their premium hands. Existing installations keep their current ranges folder unchanged. This also shipped as a 0.9.18 repack.

[0.9.18-beta]

Fixed

• The app could close a few seconds after launch, which is what made auto-updates look broken. The update downloaded and installed correctly, and the installer did relaunch the app. The new copy then crashed before its window appeared, so it read as an update that closed the app and never came back. Four such crashes appear in a single day of one log, every one 2 to 3 seconds after launch.

The cause is a non-finite number reaching a control's on-screen rectangle. The interface stores each control's rectangle and compares controls structurally during hit-testing. A not-a-number value does not equal itself, so such a control fails to match itself, an internal check fails, and the process stops mid-frame, somewhere the app cannot catch it.

One concrete source is fixed. Inside a scrolling area the available width is reported as infinite, because the content may be arbitrarily wide, and that infinity was being used directly as a layout width. Guards now check both routes such a value can take into a control rectangle, across 156 call sites.

Added

• Diagnostics, so a crash or a failed update is no longer a dead end. The updater logged nothing at all before. It now records the download, the SHA-256 check and the handoff to the installer, and states that if no launch follows, the fault is the relaunch or startup rather than the download. Crash reports carry a full stack trace instead of one line. If a guard catches a non-finite value it writes the source file and line to the log.

[0.9.17-beta]

Fixed

• The Jobs queue stutter, this time at its actual cause. 0.9.16 fixed a different one. Every queue refresh re-read each job file, re-parsed both range strings per job, and checked the output file of every board in every job on disk, all on the interface thread. On a queue of 30 jobs and 5,520 boards one refresh measured 2.4 seconds of blocking work, and while a job was running the app requested a refresh every 0.4 seconds. The interface could never finish one pass before the next was due, so the window was effectively frozen for the duration of a run. This happened at any Solver cores setting, and on the Jobs tab only, because that is where the scan lives.

The scan now runs on a background thread, and the auto-refresh interval went from 0.4 seconds to 2 seconds. Measured on the same queue, opening the Jobs tab went from 2.469 seconds of interface-thread work to 0.016 seconds, about 150 times less. The table keeps its current rows until fresh ones arrive, so nothing flickers, and only one scan is ever in flight. The old code could re-enter the scan on successive frames and repeat the 2.4-second walk.

[0.9.16-beta]

Fixed

• The Jobs queue stuttered while a job was running. The pulsing status dot in the queue requested a new frame on every frame, so for the whole duration of a run the Jobs tab redrew the entire queue table at the monitor's full refresh rate. On a large queue that consumed most of a CPU core on the interface thread, and made the window sluggish to drag and scroll. This happened at any Solver cores setting, because the cost was in the interface rather than in the solve. The pulse is now capped at 30 frames per second. It is a slow six-second fade, so it looks identical, and input still redraws instantly, which makes the app more responsive during a run rather than less. The same unthrottled redraw was fixed in the status-bar dot, drawn on every tab, and in the Jobs and Library hero cards.

Nothing else changed in this release. It is 0.9.15 plus that one fix.

[0.9.15-beta]

Added

• Preflop tab, for browsing and copying your preflop ranges. The tab sits next to Library. Select a range set in the sidebar; several sets can live side by side in one folder. Select a spot, which covers every position's RFI and each spot it faces. The 13x13 grid then shows the action mix for every hand, with fold, call and each raise size as coloured bands, in the same visual language as the postflop strategy grid.

Hover a hand to read its exact frequencies. Each action in the legend has a Copy button that copies that range as stored. Frequencies are conditional, meaning they show the decision at that spot rather than a fraction of all hands, so hands that cannot reach the spot read as out of range rather than as folds. Files that cannot be read, and files whose reach range is missing, are reported above the grid rather than quietly changing what the numbers mean.

[0.9.14-beta]

Changed

• The licence agreement carries the full statutory details of ARTGTO UG (haftungsbeschränkt). Registered office, managing director and Handelsregister entry. You accept it once, on first launch.
• The Single Job form uses the full height again. The queue shows every column, with clickable OOP and IP range links. Per-job elapsed times are recorded and survive a restart, and the status bar reports batch-run progress.
• Exports and saves report success or failure instead of failing silently.
• The range preview was redesigned.
• Library export counts and status badges agree. The badge and the count read from one source, so a folder cannot report two different numbers.
• A first contrast pass across both themes.

Added

• A guard against silently corrupted solves. The hand evaluator returns rank 0, the worst possible hand, if it is handed a board and holding that contain a duplicate card. In a release build that fallback wrote to stderr, which a Windows GUI process does not have, so the affected hands were ranked wrongly and the equilibrium shifted with nothing on screen to say so. The app now reads the engine's duplicate-evaluation counter before and after every solve, interactive and batch alike, and marks the result untrusted in the status area and the log if the count moved.

[0.9.13-beta]

Changed

• Solves use every logical thread by default, and run 20 to 30 percent faster. The solver previously used physical cores only. It now uses every logical thread, SMT included, which measured 20 to 30 percent faster per iteration across all board textures, including 30 percent on dry boards. Results are bit-identical: the same equilibrium, reached the same way, on more threads. Existing installations migrate automatically unless you had chosen a custom core count, in which case your setting is kept. The Solver cores slider in Settings, under Performance, remains the way to keep the machine lighter during long solves.

[0.9.12-beta]

Added

• Settings window. Every preference moved out of the nested View, Performance and Algorithm submenus into one sectioned window: Appearance, Performance, Solver, Folders (all six app folders with Browse buttons in one place), and About (version, update check, bug report).
• Scale with window size, optional and off by default. The whole interface zooms proportionally to fit the window, so maximising on a large monitor scales everything, and no panel is cut off at any window size. The app renders a fixed full layout and fits it to the window in both dimensions. The UI scale slider then acts as a fine adjustment on top of the fit.
• Keyboard shortcuts shown in menus. New spot (Ctrl+N), Save Solution (Ctrl+S) and Export solution (Ctrl+E) appear next to their menu items. The Jobs tab tooltip shows Ctrl+J for the queue and Ctrl+M for Multi Job.

Changed

• Display preferences persist. Four-colour deck, BB display and Fold EV = 0 survive restarts instead of resetting at every launch.

[0.9.11-beta]

Fixed

• Critical: 0.9.9 and 0.9.10 could not open or export older solutions. The Low-memory fallback checkbox added in 0.9.9 also wrote its setting into the solution file format, which is positional. Every .art file saved before 0.9.9 then failed to decode, which broke both solution loading and the entire Library export. The format is restored to its original frozen layout. Files solved on 0.9.9 or 0.9.10, in the changed layout, stay fully readable through a built-in compatibility reader, so nothing needs re-solving and no files were damaged. Round-trip tests now cover the frozen layout, the accidental 0.9.9 layout, and real library files.

[0.9.10-beta]

Fixed

• Crash on low-memory-fallback boards. In 0.9.9, a board solved through the river-bucket fallback crashed about twenty seconds into the solve, logging an index out of bounds error in the run log. An internal convergence diagnostic still read strategy tables in the per-hand layout, which bucketed river nodes no longer use. The diagnostic now sizes its rows from the data itself, and bucketed boards solve through cleanly. Re-run any board that failed this way.

[0.9.9-beta]

Added

• Low-memory fallback, so oversized spots solve instead of failing. When a board does not fit in RAM even with 16-bit compression, which happens with deep stacks, many raise sizes and wide ranges, the solver groups similar-strength river hands so they share one strategy, at the highest level of detail your free RAM allows. Flop and turn keep full per-hand detail, and all showdown and blocker maths stays exact.

The trade-off is less precise river play, so the fallback engages only when the board could not solve at all otherwise. Those boards are marked clearly: the solve status reads river-bucketed @ N, where N is the number of strength groups the river was collapsed into, and the Multi Job run log records SOLVED (river buckets @ N). - Low-memory fallback checkbox, on by default. It sits under 16-bit compress in Bet Sizing, and next to it in the Multi Job Game config and the per-job editor. Hover any of them for a plain-English explanation. Turn it off if you would rather an oversized board fail than solve with reduced river detail.

[0.9.8-beta]

Added

• Match folder smart-fill for library export. Select the parent of your export tree once. Every queued folder whose library subfolder, for example 3bp/buvssb, exists underneath it is targeted automatically, so you no longer browse each row by hand. Rows with no matching subfolder are left untouched.

Changed

• The library export queue persists across restarts. Folders and their targets are saved under %APPDATA%\artgto\ and restored at launch, the same way the Jobs queue already worked. The queue no longer resets when you reopen the app.
• The library export queue scrolls. The Library tab's export queue scrolls once it outgrows the panel, matching the Multi Job queue. A long queue of folders used to clip at the bottom with no way to reach the lower rows.

[0.9.7-beta]

Fixed

• Post-solve freeze on large solves. Building the EV view right after the last iteration briefly doubled memory use and paged the machine, so a finished solve looked stuck on Solving. This happened most often with 16-bit compress enabled. The solver now frees its working regret memory before building the EV view, and stores that view compactly, in 16-bit, on compressed solves. Post-solve memory is now close to the memory the solve itself used, and the solve reports Done promptly.
• In-app auto-update installs completely. The app now quits itself during an update, and the installer force-closes it as a backstop, so Windows can replace the running .exe in place. The app then reopens on the new version. It previously could relaunch the old version, or swap only after a reboot.

Added

• Smart 16-bit fallback in Multi Job. A board that would run out of memory at full precision now solves in 16-bit automatically instead of failing.
• Run log and Log tab in Multi Job. A per-run .txt file in %APPDATA%\artgto\job-logs\ and a Log sub-tab show which job ran, which boards solved or fell back to 16-bit, and why anything failed.
• Desktop progress overlay, opt-in. A small always-on-top window shows live solve, Multi Job and export progress, as stat tiles and a progress bar, while the main window is minimised, so you can watch a long run without restoring the app. Click it to restore. It is off by default; enable it in Settings, under Performance.

Changed

• The Multi Job queue scrolls. A long job queue scrolls instead of being cut off at the bottom of the panel.
• The library export pending count is honest. When a destination is set and skip-already-exported is on, the queue shows how many .art files are already exported there and counts only the rest as pending, instead of always showing the whole folder.

[0.9.6-beta]

Added

• 16-bit compress option. Fits roughly twice the tree in about half the RAM, and reaches the usual 0.3 percent of pot target as full precision does, at a slightly slower rate per iteration. Available in Bet Sizing, and as a per-batch toggle in the Multi Job Game config.
• Pre-solve memory guard. A flop too large for available RAM is refused up front, with a clear message, instead of freezing the machine.

Changed

• Solves default to physical cores, so the desktop stays responsive.
• A failed solve reports the reason.
• Auto-update reopens the app after installing. It previously closed the app without relaunching it.
• Multi Job: output folders are settable, Save As no longer dead-ends, and the folder browse buttons moved into the card headers, so the card no longer scrolls vertically.
• The Solver tab's bet-sizing dropdown shows the file name.
• Unused MCCFR baseline buffers are no longer allocated, which lowers memory use and shortens solve startup.

[0.9.5-beta]

Added

• Batch export resume. Re-running a batch skips files that are already exported.

[0.9.4-beta]

Fixed

• Batch export could run out of memory on slow drives. The worker count now adapts, and writes are flushed with fsync.

Changed

• CBOR is now the default export format.

[0.9.3-beta]

Changed

• Portable build, compiled for x86-64-v3 (AVX2). It runs on any CPU from roughly 2013 onward. This fixes an illegal instruction crash that some testers hit on the previous machine-specific build.

[0.9.2-beta]

Changed

• The tuned HS-DCFR schedule is now the default solver. It reaches the same target in roughly 6 to 13 percent fewer iterations, at the same equilibrium. Legacy DCFR remains available in Settings.

[0.9.1-beta]

Fixed

• Auto-update version mismatch, so the updater detects new releases reliably.

[0.9.0-beta]

Added

• In-app auto-update. Checks for a newer version, downloads it, verifies it with SHA-256, and installs it silently.
• EULA and Privacy Policy, with a first-run acceptance gate. The gate also appears in the installer.
• In-app bug reporting. Report a problem attaches diagnostics automatically.

Fixed

• AltGr text input, for example the German @ character.