TCL Q8C Issues (stuck on button press)

[gmbhneo]

Hey there, thanks for all the efforts!

My issue is, I've bought an TCL Q8C 75 inch. TV is amazing, even streaming works perfectly fine with your versions. Even normal Moonlight works but has bad/worse Decoder latency. (Yours around 3-10, normal around 15-30)

My issue is, after playing some time, whenever I press any button, TV freezes and is not responding. The image is stuck but the sound works like normal.

It seems like the longer I play, the longer it takes the TV to get unstuck. But when I play for like 10-20 mins, TV got stuck for like 5 mins or longer and reboots at some point.

Can you help me debug this? Would love to keep the TV but this really bothers me a lot since I only use it to stream games.

Can anybody explain to me how I can debug this? I am familiar with flashing roms and using adb. But would be great to know what is causing the issue so we might be able to fix this hopefully 🙌🏼

Device:G08/G08_4K_GB
Hardware: mt5896
Build: tcl9618-user 14 UTT2.250416.001 AU02

Thanks for your help everybody 🎉

[gmbhneo]

I found out, that if you enable the performance Infos, the TV is less likely to get stuck. Which doesn't make any sense to me.

[gitjbar]

qm6k, this works for me. without i will almost always get crashes from exiting with tv remote or controller combo. playing for similar or longer periods of time with the stats enabled has produced zero crashes. very strange. glad there is something that isnt extremely intrusive that works. i could have sworn this wasnt an issue when i bought the 2025 model in february. factory reset didnt make a difference to my firmware or os version. whatever, it works.

[gethari]

difference

But how do you play with the overlay on as it will hinder the gaming experience as it occupies most of one corner of the screen

[gitjbar]

it occupies most of one corner of the screen

the specific options i have for it are

Performance Monitor ●
Enable Lite Mode ●

along with OLED burn-in protection for fun. this is what i get.

[gmbhneo]

I think now after testing a lot of things, that if you disable the overlay, some sort of overlay service of Google TV is going to sleep or something. And whenever you use a button, this service gets "awake" from sleep which causes the Decoder to crash and lead to these issues. Maybe the performance overlay is using the same service which prevent it from going to sleep and causing these issues. Because, when you keep it enabled the whole time, it works flawlessly. 5ms Decoder latency whatever Bitrate and resolution I use. I've tested FPS, Bitrate and Resolutions all across the board. Always the same outcome. So this seems to fix the issue.

However, keeping the performance display on the whole time is kinda annoying. I've changed it to use the simple one already which is less distracting. But I would still appreciate it, if there would be a fix for that. (Displaying the overlay but using 0% opacity might be a fix I guess) But this is just my observation.

[derflacco]

hello, this is happening on Artemis \ Moonlight ?
I can't reproduce this problem on my phones.

[gmbhneo]

Artemis and moonlight. So it might be something Google TV related I guess. Howevery, this could still be fixed in some way if this one setting is fixing all the issues.

[gmbhneo]

Yes, Artemis and Moonlight. I think it seems to be something Google TV or TCL TV specific I guess.

Sometimes my TV just restarts after playing for a while. But the responsiveness works fine as long as I keep the overlay enabled. Sadly this still destracts from the gameplay.

[gethari]

Yes facing the same issue on my TCL Q6C/C6K

[derflacco]

I have the same TV, the C6K, but I don’t use it for streaming because it doesn’t enable Game Mode in apps, only on HDMI inputs. So you’ll get very high panel input latency, especially since it’s a VA panel, which makes it pretty bad for streaming games.

[gmbhneo]

Try enabling the fps overlay, this solved most of my issues. It is kinda strange but give it a try. Maybe it might help you too.

Just keep it enabled and use the TV like normal. On my end, having it enabled keeps everything working flawlessly. It is kinda annoying to see the net stats all the time but at least it works.

[derflacco]

@gmbhneo I don’t have time to dig into it right now, and debugging the TV won’t be plug n play.
But it’s on my list of things to check.

[gmbhneo]

No worries, take your time. Thanks for your efforts.

[gmbhneo]

I've had some chat with AI and tried to pin down the issue. Claude found some interesting bugs and fixes. Maybe you can have a look and implement some of them. (before testing ofc, it is still AI)

What was changed – and why

AsyncCodecAdapter.java – Patch 0001

OUTPUT_Q_CAP: 8 → 4
The output queue acts as a buffer between the MediaCodec callback thread and the renderer thread. Every additional slot beyond the required minimum holds back a decoded frame that could already be displayed.
With preferLowerDelays=true, the queue is drained to 1 anyway, but a smaller cap increases backpressure earlier, preventing the callback thread from accumulating stale frames.
infoPool max: 64 → 32
Adjusted to match the new cap, resulting in less heap fragmentation.

MediaCodecHelper.java – Patch 0002

MTK keys added to knownVendorLowLatencyOptions
vendor.mtk.vdec.low-latency.mode, vendor.mtk.vdec.disable-idle, and vdec-lowlatency were added to the list.
This fixes a real bug: decoderSupportsKnownVendorLowLatencyOption() returned false for c2.mtk, causing decoderSupportsRefFrameInvalidationHevc() to skip the vendor-option fast path and fall back to the prefix list instead.
Google TV HEVC whitelist
For Build.HARDWARE values starting with mt9 or mt5 (TCL Q8C = MT9653), c2.mtk and omx.mtk are now explicitly whitelisted.
The MEDIA_PERFORMANCE_CLASS check works on most devices, but fails on some Google TV firmware builds that incorrectly report class 0.
vendor.mtk.vdec.maxoutput.delay = 0
This key instructs VDecComp not to buffer frames for PTS reordering.
In live streaming, frames already arrive in decode order, making reordering unnecessary and costing 1–2 frame timeslots (~16–33 ms at 60 fps).
Output queue depth always set to 1
Previously, vendor.mtk.vdec.output.max.queue.depth was set to the same value as the input queue (2–3).
This is incorrect: every output queue slot above 1 means a fully decoded frame remains inside the decoder instead of being displayed.
The input queue remains tunable (2–3) to ensure smooth feeding.

MediaCodecDecoderRenderer.java – Patch 0003

Always apply Surface.setFrameRate()
This fixed a real bug.
The hint was previously only applied when the GL upscaler was active (__codecSurface != renderTarget). Without the upscaler — the normal case — the display compositor overlay never received a framerate hint, meaning SurfaceFlinger used default scheduling.
On a 120 Hz panel, this can introduce up to 8 ms of jitter per frame.
Callback thread priority for latency modes
desiredCodecCallbackOsPriority() always returned THREAD_PRIORITY_DISPLAY (-4) regardless of the pacing mode.
In latency-critical paths (MIN_LATENCY, GPU_RAW, WARP), the callback thread is time-critical: it must immediately place the decoded frame into the output queue so the renderer thread does not stall.
For these modes, it now returns THREAD_PRIORITY_URGENT_DISPLAY (-8).
Vsync-aligned release timestamp for latency modes
MIN_LATENCY, WARP, and WARP2 previously fell into the else branch of releaseBufferAccordingToMode, which passed System.nanoTime() as the timestamp.
If this timestamp lands shortly after a vsync edge, the frame is not displayed until the following vsync (+8 ms at 120 Hz, +16 ms at 60 Hz).
The fix uses System.nanoTime() + halfFrameNs (half a frame time as lookahead), ensuring the frame reliably lands within the next vsync window.

MediaCodecDecoderRenderer.java
MediaCodecHelper.java
AsyncCodecAdapter.java
0003-decoder-renderer-fixes.patch
0002-mtk-helper-improvements.patch
0001-async-queue-cap-and-pool-reduction.patch