add new temporary deepseek-r1:14b results

1 files changed, 13 insertions, 0 deletions

diff --git a/results/classifier/deepseek-2-tmp/reasoning/vnc/1099403 b/results/classifier/deepseek-2-tmp/reasoning/vnc/1099403
new file mode 100644
index 000000000..a9f0109e2
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/reasoning/vnc/1099403
@@ -0,0 +1,13 @@
+<think>
+Alright, I'm trying to figure out how to classify this bug report about high CPU utilization in QEMU's VNC mode. The user mentioned that when they start a Gentoo guest with QEMU and connect via VNC, starting a video causes the CPU usage of qemu-x86-64 to spike to 90%. Even after closing the VNC viewer, the CPU remains high. Without the remote connection, the CPU usage is much lower (20-30%).
+
+So, first, I need to understand what category this issue falls into from the given options: mistranslation, assembly, other, device, graphic, socket, network, KVM, boot, vnc, debug, files, permissions, performance, kernel, peripherals, hypervisor.
+
+The bug is related to VNC usage causing high CPU. The user suspects it's due to QEMU's VNC server needing to send framebuffer updates. They're puzzled why the CPU doesn't drop when the client disconnects, unlike a regular VNC server.
+
+I'm thinking this isn't a translation issue because mistranslation relates more to incorrect mapping in code conversion. It's also not an assembly or kernel issue. It seems directly related to how QEMU handles VNC connections and resource management after disconnection.
+
+The high CPU usage is a performance problem, but since it's specific to the VNC component, 'performance' might be too broad. The bug is specifically about VNC behavior, so the most fitting category would be 'vnc'.
+</think>
+
+vnc
\ No newline at end of file