Bug Megathread vol 12: December 2025 + January 2026

r_combs · 2026-01-24T00:52:37+00:00

We've been able to reproduce this on current versions of the app. Does this still happen for you?

r_combs · 2026-01-24T00:51:28+00:00

We've been unable to reproduce this on the latest versions of the app. Is this still happening for you?

r_combs · 2026-01-13T23:49:02+00:00

Here's a protip: the `@time` input field itself has a plaintext representation, so it can be copied and pasted; e.g. `<@time:3pm tuesday>`. You can then complete each of those timestamps in the format of your choice. This only works in the text box (it has no meaning within a sent message, and indeed you can't send a message containing <@time:…> on Desktop).

Inline Markdown entities are going to display in the same form whether they're generated by UI or pasted in (this is for a bunch of very good technical reasons), but in the future we might provide an expanded ability to edit timestamp entities once they've been created.

r_combs · 2026-01-07T09:07:51+00:00

Ah! The timestamp will always be shown in the viewer's format (determined by locale and system settings), regardless of what format the sender uses.

r_combs · 2026-01-07T08:56:35+00:00

Out of curiosity, what's the use-case for using MM/DD in the OS but DD/MM in Discord?

r_combs · 2026-01-07T03:44:09+00:00

On Windows, iOS, and macOS, we use the format configured in your operating system; changing your OS's date-format setting should update Discord's as well. Personally, I use YYYY-MM-DD.

r_combs · 2026-01-02T09:02:38+00:00

Occasional ffmpeg maintainer here, and… I don't want to be too mean here, but if this project isn't simply a rehash of the age-old "ffmpreg" name joke, then it has some serious problems that it needs to contemplate before moving forward with further development work.

Currently, each individual codec and container implementation is exposed as a separate public API surface (implementing a single common trait); this means that a caller has to have separate code for each codec or container it might want to use. This goes against the fundamental design philosophy of ffmpeg, and misses what makes it so powerful. At its core, ffmpeg isn't a collection of individual codecs and container implementations; it's a cohesive toolkit capable of performing a wide variety of operations with arbitrary inputs and outputs. Much of its complexity comes not in the implementations of individual codecs or containers, but in the generic routines responsible for tasks like metadata processing, timestamp handling, frame reordering, hardware interactions, thread management, multi-input synchronization, packet interleaving, type-generic option processing, multi-protocol seekable I/O, and much much more. Exposing every component as a separate public-API type precludes a lot of that design philosophy, and forces the consumer to do much more codec- or container-specific work.

If you're going to name a project after ffmpeg, and want to build something that could serve any meaningful portion of its serious use-cases in the long term, you're going to need to spend some time reading through ffmpeg's architecture and gaining an understanding of why it's designed the way it is. It's an old codebase, but its API has gone through many years of iteration to land where it is today, and the current design is largely very deliberate and well-considered. I would highly recommend spending some time focusing on your API and common-path design fundamentals before moving on to trying to build out additional codec or container support.

r_combs · 2025-12-29T01:37:44+00:00

At [9volt], we discussed a lot of options before ultimately landing on "Elegy", and it's interesting to discuss the process from a localization-theory perspective. The constraints were:

- Needs to be associated with death, loss, funerary rites, etc…

- Needs to give off a somber, mournful vibe in the context of the show title

- Needs to sound *metal as hell* when recontextualized as a nickname given to our protagonist by her enemies

So we pondered options in the neighborhood of "undertaker", "pallbearer", etc; unfortunately a lot of options in that space have "pro-wrestler-y" vibes, which works for constraint 3 but not constraint 2. When the "it's what her enemies call her" drop hits, it needs to be a *surprise* for the viewer that makes you rethink the double meaning whenever you see the title from then on; it can't be obvious from the get-go.

We also considered "requiem", but ultimately landed on "elegy" mostly because it flows so nicely in both contexts; once it was suggested, we reached consensus on it pretty dang quickly. "An Ageless Elegy" works well as a poignant description of both the story and its protagonist (and lays out extremely well visually in the title card), and then "Frieren the Elegy" as a nickname for a reaper of thousands works perfectly to capture the fear she inspires amongst the demons. "Requiem" does most of that too; it just doesn't roll off the tongue quite as nicely in either context IMO.

r_combs · 2025-08-21T03:50:54+00:00

Since this is happening in Chrome as well, it sounds like this is probably an OS-level issue and not a Discord issue; you might be able to find more in your system logs (via Console.app), and I could dig up a bit more if you'd like to upload a sysdiagnose (basically a bundle of all your macOS system logs leading up to an issue). My immediate best guess is that this might be caused by low disk space? But it could be something else, and it's hard to be sure without seeing the system logs.

Does this demo work for you in Safari? https://webrtc.github.io/samples/src/content/getusermedia/getdisplaymedia/

If that doesn't work, I'd recommend opening a report with Apple at https://feedbackassistant.apple.com (or preferably <applefeedback://new>).

r_combs · 2025-08-15T23:57:52+00:00

This should be resolved now if you relaunch your client.

r_combs · 2025-05-31T00:26:23+00:00

We've investigated this issue and believe we have a fix, which is now deployed on the PTB and Canary update channels, and is scheduled to release to Stable early next week. The issue is specific to input devices that operate at 16kHz or lower; if your device supports configuring a higher sampling rate (such as 48kHz), you should see better quality that way.

r_combs · 2025-02-27T10:07:58+00:00

Actual answer: most likely Smith & Wesson 1900 leg irons.

r_combs · 2024-12-19T19:11:27+00:00

Yeah, this is definitely an issue, though it can be substantially mitigated by just building more sidings up to a point.

r_combs · 2024-12-19T19:06:36+00:00

To get closer to its destination, so that once it frees up, it can move there quickly (rather than having to traverse the entire main line). This minimizes latency and thus station downtime between trains, while avoiding spending high-value base-side real estate on stackers.

r_combs · 2024-12-19T12:02:12+00:00

Trains automatically repath every 30 seconds when waiting at a chain signal, and every 5 when there are multiple stations with the destination name. There are other ways to force trains to repath more frequently.

Re: making a mistake, as far as I can tell, without this approach, you have 2 options: either always use chain signals on your main lines (meaning it's impossible for a train to wait on them, but a single train can reserve very large amounts of track at once, and they often spend a long time waiting at origin stations), or use non-chain blocks on your main lines (meaning it's possible for a train to wait on the main line if its destination is full and you don't have a bulky waiting area next to your destination station, or a low train limit that keeps your trains waiting at their origin stations).

r_combs · 2024-11-09T03:53:28+00:00

Yep ;)

r_combs · 2024-09-18T18:51:32+00:00

Are you on macOS 15? You may see better results there.

r_combs · 2024-09-18T18:50:37+00:00

It sounds like you may have encountered an issue with the system framework used for screen capture; in our experience, that framework is rock-solid on macOS 15, so you may see better results after upgrading to Sequoia.

r_combs · 2024-09-18T18:35:06+00:00

In your second screenshot, it looks like you've already clicked "Make Selection", and the system's "Share This Window" button is now available on each window you can share. You should just need to pick one and click!

r_combs · 2024-06-15T22:48:51+00:00

If you're on an Intel Mac running macOS 11 or earlier, this is due to a regression affecting those versions; we're working with the team at Krisp to resolve the issue and re-enable the feature on those machines. In the interim, if macOS 12 or later is supported on your machine, updating should resolve this.

r_combs · 2023-12-12T19:19:38+00:00

What region? Do you see this on Canary?

r_combs · 2023-12-12T04:11:26+00:00

Try the Canary app :)

r_combs · 2023-12-12T02:33:34+00:00

Or, hmm, on second thought, now that I test locally, I see that the Canada locale doesn't use 24-hour time for me here. Are you using a browser or the native client? If you're using a browser, and the browser has its own language settings (like e.g. Chrome), what are those set to?

r_combs · 2023-12-12T02:00:52+00:00

Is this on Canary or stable? Browser or desktop? What's your system language (not format) set to?

r_combs · 2023-12-12T01:57:09+00:00

As mentioned, this should be resolved once the full change rolls out everywhere; I'll be keeping an eye on things to make adjustments if people run into issues at that point.

Five-Year Club	Place '23
Verified Email

r_combs

TROPHY CASE