FLAC playback fails on Linux (NotSupportedError / FFmpegDemuxer open context failed)

[alixsep]

Summary

On Linux, Dopamine crashes when attempting to play .flac files, showing a global error dialog and then exiting.

Initial investigation suggested missing codec support, but further testing shows that Electron does have FLAC decoding support available.
The failure appears to be caused by how FLAC files are passed to Electron’s media stack (MIME type and/or source handling), causing Chromium’s demuxer to reject the source before decoding.

Environment

• Dopamine version: 3.0.0
• Distribution: Fedora Linux (RPM package)
• Also tested: AppImage (same issue)
• Desktop: GNOME (Wayland)
• Audio backend: PipeWire
• CPU architecture: x86_64

Steps to reproduce

1. Install Dopamine 3.0.0 (RPM or AppImage)
2. Add a music folder containing .flac files
3. Attempt to play any FLAC track

Expected behavior

FLAC files should play normally.

Actual behavior

• Playback fails immediately
• A global error dialog is shown
• Dopamine closes shortly afterward

Application logs

[2025-12-13 22:37:23.507] [info]  [Queue] [setTracks] Set '15' tracks. Shuffle=false
[2025-12-13 22:37:23.510] [info]  [PlaybackService] [stopAndPlay] Stopping ''
[2025-12-13 22:37:23.522] [info]  [PlaybackService] [play] Playing '/home/user/Music/test.flac'
[2025-12-13 22:37:23.625] [error] [GlobalErrorHandler] [handleError] Handling global error.
Error: Uncaught (in promise): NotSupportedError: Failed to load because no supported source was found.
[2025-12-13 22:37:23.627] [info]  [GlobalErrorHandler] [showGlobalErrorDialog] Showing global error dialog
[2025-12-13 22:37:25.143] [info]  [GlobalErrorHandler] [showGlobalErrorDialog] Closing application

DevTools / Electron diagnostics

Codec availability

In Dopamine’s DevTools console:

document.createElement("audio").canPlayType("audio/flac")

Returns:

"probably"

This indicates that Electron/Chromium does have FLAC decoding support available.

However:

const a = document.createElement("audio");
a.canPlayType("audio/x-flac");              // ""
a.canPlayType("application/octet-stream");  // ""

Chromium only accepts audio/flac, and rejects other MIME types.

Direct file playback test

Attempting to load a FLAC file directly via a file:// URL:

const a = new Audio("file:///home/user/Music/test.flac");
a.onerror = (e) => console.log(a.error);
a.play();

Produces:

MediaError {
  code: 4,
  message: "DEMUXER_ERROR_COULD_NOT_OPEN: FFmpegDemuxer: open context failed"
}

Followed by:

DOMException: Failed to load because no supported source was found.

This suggests the demuxer refuses the source before decoding, despite FLAC support being present.

Additional information

System FLAC support is present and functional:

$ gst-inspect-1.0 flac

Plugin Details:
  Name                     flac
  Description              The FLAC Lossless compressor Codec
  Filename                 /usr/lib64/gstreamer-1.0/libgstflac.so
  Version                  1.26.9
  Source module            gst-plugins-good

This confirms the issue is not a missing system codec or Fedora packaging problem.

Analysis

Based on the above, the issue appears to be:

• FLAC decoding is available in Electron

• Chromium rejects the source before decoding

• Likely causes:

  • FLAC files being passed with an incorrect MIME type (e.g. audio/x-flac or application/octet-stream)
  • Blob / stream-based loading without an explicit audio/flac MIME type
  • Source handling that Chromium’s FFmpeg demuxer cannot open

This results in a NotSupportedError and application shutdown.

Suggestions

Possible ways to resolve or mitigate:

• Ensure FLAC sources are always provided with MIME type audio/flac
• Review blob / stream creation for local file playback
• Fail gracefully when a source cannot be opened (instead of closing the app)
• Consider documenting supported formats and Linux limitations
• Optional: provide a Flatpak build with a known-good media configuration

Notes

• MP3 and Ogg Vorbis playback work correctly
• Issue is reproducible 100% of the time with FLAC files
• Same behavior across RPM and AppImage builds

Thank you for your work on Dopamine.

[digimezzo]

@alixsep Thank you for logging this issue. Could you share one of the FLAC files that exhibit this issue? I have flac files which play correcly here in Dopamine 3.0. I'd like to compare.

[alixsep]

@digimezzo

Thanks for looking into this.

I was able to fully isolate the root cause and create a minimal flac file to reproduce the issue that would crash Dopamine deterministically.

I’m attaching repro.flac to this issue. It contains only synthetic audio (a sine wave) and a synthetic image.

repro.zip

Summary of findings

FLAC decoding itself works correctly in Dopamine 3 / Electron on Linux.
The crash occurs only when the FLAC file contains a malformed PICTURE metadata block.

Specifically, the failing files have an embedded album-art PICTURE block with:

• empty MIME type
• width / height / depth / colors = 0
• valid JPEG image data inside the block

Many native players (GStreamer, VLC, ffplay) tolerate this metadata, but Chromium’s FFmpeg demuxer rejects it during container parsing, before audio decoding. Dopamine then exits on the resulting NotSupportedError.

Removing or rewriting the PICTURE block fixes playback immediately.

How this was confirmed

For the problematic file:

metaflac --list problematic.flac

The PICTURE block looks like:

type: 6 (PICTURE)
MIME type:
width: 0
height: 0
depth: 0
colors: 0
data: valid JPEG

Playback behavior:

• Original FLAC → Dopamine fails with NotSupportedError
• Same FLAC with PICTURE removed → plays correctly
• Same JPEG re-imported using metaflac --import-picture-from=... → plays correctly

Re-importing the artwork rewrites the PICTURE header with proper MIME and dimensions, which resolves the issue. This shows the image itself is not the problem — only the malformed metadata header.

Minimal repro (attached)

The attached repro.flac contains:

• a 2-second sine wave (ffmpeg lavfi)
• a small synthetic JPEG
• a deliberately malformed PICTURE metadata block (empty MIME + zero dimensions)

Playback behavior:

• base.flac (no picture) → plays
• good.flac (proper picture) → plays
• repro.flac (malformed picture metadata) → crashes Dopamine
• repro.flac with PICTURE removed → plays

Steps to reproduce / regenerate locally

1) Create clean audio

ffmpeg -f lavfi -i "sine=frequency=1000:duration=2" \
  -ac 2 -ar 44100 -sample_fmt s16 -c:a flac base.flac

2) Create a synthetic image

ffmpeg -f lavfi -i color=c=black:s=300x300 -frames:v 1 cover.jpg

3) Import artwork normally (this file plays)

cp base.flac good.flac
metaflac --import-picture-from=cover.jpg good.flac

4) Patch the PICTURE block to match the failing metadata

Save the following as make_bad_flac.py:

#!/usr/bin/env python3
import sys
import struct

# Usage: python3 make_bad_flac.py good.flac repro.flac
if len(sys.argv) != 3:
    print("Usage: make_bad_flac.py good.flac repro.flac")
    sys.exit(1)

good_flac, out_flac = sys.argv[1], sys.argv[2]

with open(good_flac, "rb") as f:
    data = bytearray(f.read())

if not data.startswith(b"fLaC"):
    raise RuntimeError("Input is not a FLAC file (missing fLaC marker)")

pos = 4  # skip fLaC marker

while True:
    header_pos = pos
    header = struct.unpack(">I", data[pos:pos+4])[0]
    is_last = (header >> 31) & 1
    block_type = (header >> 24) & 0x7F
    block_len = header & 0xFFFFFF
    pos += 4

    if block_type == 6:  # PICTURE block
        payload_start = pos

        # PICTURE payload layout:
        # 4: picture type
        # 4: MIME length
        # n: MIME string
        # 4: description length
        # m: description string
        # 4: width
        # 4: height
        # 4: depth
        # 4: colors
        # 4: data length
        # k: image data

        mime_len = struct.unpack(">I", data[payload_start+4:payload_start+8])[0]
        mime_start = payload_start + 8

        desc_len_pos = mime_start + mime_len
        desc_len = struct.unpack(">I", data[desc_len_pos:desc_len_pos+4])[0]
        desc_start = desc_len_pos + 4

        dims_start = desc_start + desc_len

        # 1) Zero out width/height/depth/colors (16 bytes)
        data[dims_start:dims_start+16] = b"\x00" * 16

        # 2) Remove the MIME string and set MIME length to 0 (empty MIME like the failing file)
        del data[mime_start:mime_start + mime_len]
        data[payload_start+4:payload_start+8] = struct.pack(">I", 0)

        # 3) Fix the metadata block length in the FLAC block header
        new_block_len = block_len - mime_len
        new_header = (is_last << 31) | (block_type << 24) | new_block_len
        data[header_pos:header_pos+4] = struct.pack(">I", new_header)

        break

    pos += block_len
    if is_last:
        raise RuntimeError("No PICTURE block found in input file")

with open(out_flac, "wb") as f:
    f.write(data)

print(f"Wrote: {out_flac}")

Run it:

python3 make_bad_flac.py good.flac repro.flac

Verify the repro metadata matches the failing pattern:

metaflac --list repro.flac

You should see:

• MIME type: (empty)
• width/height/depth/colors all 0

Why this may be hard to reproduce locally

Most tagging tools write well-formed PICTURE blocks.
Malformed blocks like this (empty MIME + zero dimensions) come from older or non-standard taggers, but they still exist in real-world libraries.

Dopamine works fine with:

• clean FLACs
• FLACs with properly tagged artwork

It fails only with this specific metadata layout.

Recommended handling in Dopamine

Even if Chromium rejects the stream, Dopamine probably shouldn’t exit. Reasonable options could be:

• catch demuxer failure and show a non-fatal error
• skip the track and continue playback
• optionally detect malformed PICTURE metadata and warn
• document this Chromium limitation on Linux

Thanks again.

[digimezzo]

@alixsep You did amazing work! Thank you! I'll use your file and info to improve handling of such files in Dopamine.

[digimezzo]

This seems to be a bug report for Chromium that could match this problem: https://issues.chromium.org/issues/331369803
It seems fixed in Chromium M126. I verified, and Electron 31 should have this version of Chromium. Time to upgrade I guess. I'll plan this for 3.0.2.

Edit: no luck. I tested with all versions of electron between 31 and 39 and none of them play the file. For the fiel that is attached to the Chromium bug, the bug is indeed fixed. But not for our file. I might have to log a Chromium bug for this specific issue.