Skip to content
⌂ Home

How To Solve Problems

When something breaks, the most important thing is not guessing the cause. It is preserving the scene. Whoever helps you needs the full window, the raw error, the steps that trigger it, and your environment. A tiny screenshot crop, or just “this doesn’t work”, is asking people to solve the problem blindfolded.

Prepare information in this order:

  1. Screenshot the whole window, not one button, one dialog corner, or one red line.
  2. Open the console under Settings -> General.
  3. Reproduce the problem once by repeating the action that triggers it.
  4. Copy the error report: paste the console error, diagnostics, or copied report as-is.
  5. Write down what you did, step by step, from opening the page to hitting the problem.

If you only crop a tiny piece of the screen, even the smartest assistant cannot help. It cannot see the page state, what you clicked, where the error came from, or whether this is a playback, library, network, driver, plugin, or settings problem.

A screenshot should tell people where you are, what you did, and what state the app is in. Capture the full window, not a fragment.

A complete screenshot usually includes:

  • The current page title or the left navigation.
  • The area that failed.
  • The bottom player state: playing or not, whether the progress bar moves, whether volume is muted.
  • The current output device, output mode, scan progress, remote-source state, or plugin state.
  • Any dialog, banner, red error, blank area, or endless spinner.
  • If settings are involved, capture the relevant settings section, not just one toggle.

Avoid these:

Don’t do thisWhy it doesn’t help
Crop a single red exclamation markNobody can tell which page or feature it belongs to
Crop just the word “failed”Failed at what — playback, scanning, login, download, or connection?
Crop only a buttonNo before/after state, and no idea what you were trying to do
Paste a retelling from a chat logRetellings lose error codes, paths, device names, and real context
Send only “same here”Nobody knows if your system, version, device, and steps actually match

For dynamic problems — crashes, stutter, failed track changes, stuck scan progress, black MV screens, remote-source connection failures — a screen recording is usually more useful than a screenshot.

Many problems look identical on the surface but have completely different causes.

“No sound”, for example, could be:

  1. The wrong output device is selected.
  2. The app volume is muted in Windows.
  3. WASAPI Exclusive is held by another player.
  4. The ASIO driver failed to open.
  5. A DSD file cannot be handled by the current output chain.
  6. DSP, ReplayGain, speed change, or channel settings caused an anomaly.
  7. The file is corrupt or failed to decode.

“No sound” alone has no diagnostic value. The error codes, device names, file paths, audio formats, request URLs, HTTP status codes, plugin names, and stack traces in the console are the evidence that actually locates the problem.

When a problem occurs:

  1. Open ECHO.
  2. Go to Settings -> General.
  3. Enable the console / developer console / debug console option.
  4. Return to the page where the problem occurs.
  5. Repeat the action that triggers it.
  6. Copy the raw console error, or use the copy-diagnostics / export-report / copy-error-report button on the page.
  7. Send the copied content together with a full screenshot.

If the error is long, do not trim or edit it yourself. Collapse it, zip it, or paste it into a text file — but do not screenshot only the last line. The useful part is often the first error, the device state around it, the request URL, the file path, or the call stack.

Good reproduction steps look like this:

1. Open ECHO.
2. Go to Settings -> Audio Output.
3. Set output mode to WASAPI Exclusive.
4. Select the xxx USB DAC device.
5. Play this FLAC: file name / format / sample rate.
6. After clicking next track, no sound; progress bar keeps moving.
7. The console shows this error: ...

Bad reproduction steps look like this:

I was just using it normally and it broke.

“Using it normally” is not a step. Nobody knows what you clicked, which settings were on, what format the file is, what the device is, or when the problem started.

While troubleshooting, do not switch output modes, enable DSD, tweak the EQ, swap drivers, and rescan the library all at once. Even if the problem disappears, you will not know which change fixed it.

Recommended order:

  1. Save the full screenshot and error first.
  2. Change one setting.
  3. Reproduce once.
  4. Record the result.
  5. Then change the next setting.

For playback problems, go back to System or WASAPI Shared first. For library problems, reproduce with a small folder of 3 to 10 tracks. For remote-source problems, confirm the browser or the original service’s client can reach it. For plugin problems, disable the plugin first and see if things recover.

In a hurry? At least fill in this template:

ECHO version:
Windows version:
Page with the problem:
What I wanted to do:
What actually happened:
Steps to reproduce:
1.
2.
3.
Full screenshot:
Console / error report:
What I already tried:

If you want an AI to help organize it, send it the content above and add:

Do not guess the root cause. First list confirmed facts, missing information, possible causes, and low-risk checks.

Problems are solved with evidence, not guesses. A full screenshot, the console error, reproduction steps, and version and environment info are the cheapest way to get a problem located fast. The more complete the information, the faster the fix; the more fragmented it is, the longer everyone circles around “it doesn’t work”.

To keep digging: common symptoms are in the FAQ, stuck scenarios are in Common Stuck Points, and feedback templates live in the Ask AI guide.