TraceApps

Glad you are liking it so far! Yes i have thought about adding Kanban support, and will look to implement it in the near future. I’ve been thinking about putting all my app son F-Droid, so i will say coming soon!. With respect to the color… you can change it to literally whatever you want, so you are not stuck to the purple if you prefer something else.

Yes. You can share any note or checklist with other people on your server, with view or edit access. Pins, labels, colors and reminders stay personal to each person, so a family member can pin the grocery list without it jumping to the top of your grid.

It isn’t live yet, though. Changes sync rather than stream. The Android app syncs every 30 seconds and whenever you open it, so a checked-off item shows up on the other phone within about half a minute. In the web app, changes from someone else show up when you refresh, reopen the note, or pull down on the list.

If you both edit at the same time:

• Checklists merge item by item. You can both tick things off or add items in the same list and nothing gets lost, which covers the usual shared shopping list case.
• For text notes, the last save wins, and the other version is kept in the note’s version history, so nothing is ever thrown away.

Live updates, where a tick or edit shows up on the other person’s screen within a second or two, are very doable, and I’d like to add them. If you open a feature request for it, it goes on the list and you’ll get a notification when it’s in: github.com/TraceApps/notetrace/issues/new?templat…

A couple of lines about how you’d use it (for example, two phones on one shopping list at the store) will help me with envisioning how this should work.

:)

Yes of course. I will look into and hopefully release in the very near future.

Happy to look into this! To help me track it, would you mind submitting a feature request on the GitHub repo? I appreciate your input!

One thing I wish ai would teach vibe coders is how to use semantic versioning.

Trying to infer state of project from versions in ai-assisted software is an exercise in confusion.

Thank you. Hoping to continue to improve the products in meaningful ways. Always appreciate your continued support!

yes both are included as an available option to enable/disable!

Thanks, that narrows it down a lot. Fathom renders through libmpv and currently leans on its default frame timing, where a well-tuned client instead syncs frames to the display refresh.

Two questions would let me pin it down:

Which official client are you comparing against: the web client in a browser, or the Jellyfin Media Player desktop app? It matters because a browser hands video to a hardware overlay that is tear-free by design, while Jellyfin Media Player runs the same engine Fathom does, just configured differently.

What OS are you on, and what is your monitor’s refresh rate (60, 120, 144Hz)? On Linux, which desktop or compositor?

On the fix side, the next dev build adds a “Smooth Motion (Display Sync)” option under Settings > Playback > Advanced that paces frames to your monitor’s refresh. That is the usual cure for this kind of judder, so please try it when you have a moment.

The same build also adds a Diagnostics screen under Settings > About. Open it, turn on Diagnostic Logging, start the video again, let the stutter happen for a few seconds, then use “Copy Diagnostics” and paste the result here. That shows me the exact decode path and frame timing instead of me guessing. It strips out anything sensitive before copying.

github.com/Fathom-Media/fathom/…/v0.9.1-dev.3

Glad 10.11.11 fixed the login. Since it’s the same with hardware acceleration on or off, decoding isn’t the bottleneck, it’s likely delivery or frame timing. Two quick checks: in your Jellyfin dashboard, is that session Direct Play or Transcode? And does the same file play smoothly in plain mpv/VLC (Fathom uses libmpv underneath)? That’ll tell us if it’s server/network vs. something on the Fathom side.

Yeah, unfortunately that’s a Google account/billing thing, not a playback thing. Fathom only fetches the video stream on your machine; it doesn’t touch your account or Premium. That “verify your country” check is much stricter than playback and wants a residential IP in the country, so datacenter VPN ranges like Proton’s can get “flagged”. Nothing i think a media client alone can get around.

Sorry about that. That message is a network timeout, so the Quick Connect request isn’t getting a response back within the window. Since you had to enter the server address to reach that screen, plain reachability and your cert are should be fine, so it’s something specific to the Quick Connect path.

Two things would help me narrow it down:

Does normal username/password sign-in work against the same server, or does that time out too? If password works and only Quick Connect hangs, that isolates it to the Quick Connect endpoints.

Is Jellyfin behind a reverse proxy (nginx/Caddy/Traefik), and which Jellyfin version?

Interesting idea, but that’s out of scope for this app, Fathom is just a Jellyfin/YouTube/Seerr client, with no torrent or P2P layer, so there’s nothing for I2P to integrate with.

Unfortunately, it’s Jellyfin-only. Emby and Jellyfin came from the same codebase originally, but their APIs and auth have drifted apart enough that Fathom’s Jellyfin-specific calls won’t work against Emby. No Emby support planned, the focus is Jellyfin, alongside the Seerr and YouTube pieces.

Sign-in goes through Jellyfin’s normal username/password endpoint (AuthenticateByName) plus Quick Connect, which is the same path the LDAP plugin hooks into, so LDAP logins generally work with a standard client like this, it shouldn’t be the blocker by itself. A few things worth trying: if your server has Quick Connect enabled, try that (it sidesteps the password path entirely and is a good way to isolate the problem); double-check the server URL has the scheme and port (e.g. host:8096); and a self-signed HTTPS cert can also cause a failure. If you can paste the exact error you’re seeing, I’ll dig in, and a GitHub issue is welcome.

Yes, the YouTube side is fully client-side, the app resolves and fetches the stream directly, the Jellyfin server isn’t involved at all. So YouTube sees the connection of whatever machine is running Fathom, using that machine’s IP and location. Fathom doesn’t spoof anything itself, but because it’s client-side, running it at home or behind a VPN is what should decide the location YouTube sees.

Appreciate the kind words, thank you.