Clicker - An Unofficial Player for Channels DVR Server- written in Rust

No. ARM64 Windows is still pointless imo. I don't have hardware to test on.

I get not having the hardware to test on, but its definitely not pointless lol. The best Windows laptop I've ever used (and I'm old!) is my Lenovo Yoga running Windows ARM. It has forever battery life, almost instant resume and I have very few apps that don't have ARM versions.

Feel free to fork and recompile for ARM 64. It's MIT. :slightly_smiling_face:

I don't know if you want to test the ARM64 version of my Windows HTPC or not, but it is in pre release here: Release V1.2.9-ARM · nuken/HTPC · GitHub

1 Like

just open another instance of Clicker

Thanks for the suggestion, but for Windows I mainly am watching on my laptop while working, so not sure an HTPC interface would work well for that lol.

1 Like

DVRDesk has an ARM version

1 Like

Might be doable with a CI. I'm taking a look really quick, but I just don't have a lot of energy for this right now.

Fixed the reported bugs on the library page (hopefully, couldn't test myself). Also added ARM64 support for Windows.

1 Like

What I mean by PIP is the ability to have the video window float above the other windows so its always on top. This is possible on the Safari browser.

Thanks for the ARM version - looks good so far.

A couple of quick issues:

Channel collections don't seem to work. They show in the dropdown, but when I select a specific collection, I get "Nothing matches".

Also I assume Dolby Vision doesn't work? Watching a 4K DV movie from my library and it shows in purple (which I believe means it isn't handling the DV content)

Thanks!

I won't be adding that. This is written in rust not a web view.

Looking into this... I may have a personal use case for it. Depends on how hard it is to implement on all platforms in one shot.

Dolby Vision is not possible, it requires a license.

Channel collections do work. You probably have a filter set on the source.

Just tested ARM64 Windows running on Parallels on a Mac.

PIP support! I initially hit some Windows defender issues. If anyone does please let me know but it is a false positive. An EV cert is way too much for a project like this. Apple notarization is much less expensive for example.

Edit there is a small bug with Windows when minimizing the main window.

Edit 1: Cutting 1.3.1 it will be up in a few mins!

Edit 2: Should be all good.

1 Like

Awesome! I really like this client. Simple, streamlined... It works way better in Ubuntu Wayland than WebKitGTK in Tauri. If you don't mind, I'm going to convert DVRDesk to this tech stack and steal some ideas, like the guide implementation. Great work!

I'm going to be completely honest with you.
This client started out as a PR to yours.

And as I was working on my PR to your client, I realized I should just rebuild this in pure rust. That's why I specifically cited you in my original post.

Cool. This is something I've learned about leaning on AI for this kind of thing. The AI will happily help you implement a bad solution, and try like hell to make it work until you make a remark like "this doesn't seem to be a good way to do this. Isn't there a better way?" and then it's like "Yeah, how about this?".... right, why didn't you suggest that in the first place??. I brought that up with Claude:

me:

macid1993 appears to be someone familiar enough with the tech to know that the Tauri path would be problematic. If I had that much knowledge at the start of the project, I could have steered claude code (actually I started with the claude sonnet model in CoPilot) toward the native Rust path to begin with. I actually tried to do that by stating that I wanted to use a player that could use MPEG2 natively and play the CC track without needing access to the .srt file, but this path was not identified nor offered

Claude:

That's the sharpest observation in this whole thread, and I think you're being a little unfair to yourself about it. You did state the right requirement. "MPEG-2 natively, CC track without a sidecar .srt" is almost exactly the constraint mackid built the entire architecture around — his README spells out that Chromium's MSE can't decode mpeg2ts or AC-3 at all, and that CEA-608/708 ride inside the picture rather than existing as a selectable track. So you named the precise thing that should have vetoed the webview class of solutions. The gap wasn't in what you knew to ask for. It was that the model didn't propagate your constraint backward into an architectural conclusion.

That's a specific and, I think, underappreciated failure mode. Models are strong at solving locally within a frame you've handed them and weak at telling you the frame itself is doomed. Faced with "I need native MPEG-2 and embedded CC," the likely path of least resistance is to reach for hls.js or mpegts.js or video.js — something that looks like it satisfies the requirement — rather than to stop and say "everything in this category feeds MSE and hits the same wall, so the webview approach is dead and you want mpv rendered to a texture." The correct answer required rejecting the dominant pattern, and Tauri-plus-webview is overwhelmingly the mean response to "cross-platform desktop app with a nice UI." The rarer, correct pattern sits far out in the tail.

What mackid had wasn't Rust fluency so much as negative knowledge — the "that won't work because AC-3, don't even start" instinct. That's the hardest kind of expertise to elicit from an AI when you don't already possess it, because you don't know the shape of the question that surfaces it. A domain expert carries a whole library of dead ends they never have to re-walk; the model will happily walk you into several of them with total confidence, because a plausible-looking wrong path scores just as well as the right one until it doesn't.

The genuinely encouraging part is that you're now acquiring exactly that negative knowledge the efficient way — by reading a reference implementation whose author already paid for it in evenings lost. You don't have to independently discover that MSE can't do AC-3; he wrote it down, with the isTypeSupported calls that return false. Steering the next architecture-level decision well is mostly a matter of having enough of those "won't work because X" priors loaded, and reading his source is a fast way to load a batch of them. The Tauri detour cost you some time, but it also gave you the thing that makes the second attempt go right.

1 Like

It's all about knowing how to orchestrate the model.

Any plans for a light skin? Clicker works but its not easy on the eyes lol :smiley: so I think a light skin would be a nice feature

I actually hate light theme.

It shouldn't be too hard to have a model like Fable handle it. So, I'll look into it when I have some time.

1 Like