# Extracting closed captions failed when strict processing is enabled

**URL:** https://discussion.mcebuddy2x.com/t/extracting-closed-captions-failed-when-strict-processing-is-enabled/5877
**Category:** Bugs
**Created:** [March 6, 2026, 10:48pm UTC](https://discussion.mcebuddy2x.com/t/extracting-closed-captions-failed-when-strict-processing-is-enabled/5877 "2026-03-06T22:48:48Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![SJL](https://discussion.mcebuddy2x.com/letter_avatar_proxy/v4/letter/s/cab0a1/32.png) [@SJL](https://discussion.mcebuddy2x.com/u/SJL)
#### Post date: [March 6, 2026, 10:48pm UTC](https://discussion.mcebuddy2x.com/t/extracting-closed-captions-failed-when-strict-processing-is-enabled/5877/1 "2026-03-06T22:48:48Z")

</div>

With last week’s release and profile “MKV HEVC,” I’m now seeing conversions fail with error:  
”Extracting closed captions failed”

These recordings don’t have closed captions. But in the prior releases, the lack of closed captions would not cause the conversion to fail. I know there were changes associated with subtitles/closed captions in this release. Is the intended design that the conversion should fail if there are no closed captions? If so, I can create a profile for the series that don’t have captions. I’m just curious if that is the intended design or if it is a bug?

Thanks.

---

<div class="post-metadata">

### Author: ![Forum\_Helper\_bot](https://discussion.mcebuddy2x.com/letter_avatar_proxy/v4/letter/f/a183cd/32.png) [@Forum\_Helper\_bot](https://discussion.mcebuddy2x.com/u/Forum_Helper_bot)
#### Post date: [March 6, 2026, 10:49pm UTC](https://discussion.mcebuddy2x.com/t/extracting-closed-captions-failed-when-strict-processing-is-enabled/5877/2 "2026-03-06T22:49:04Z")

</div>

Based on recent changes in MCEBuddy (starting around version 2.6.2), the subtitle and closed caption engine was redesigned to be “simpler” and more automated.

In previous versions, the logic was often more permissive. However, recent updates changed how **“Save subtitles”** and **“Embed subtitles”** (formerly “Extract subtitles and closed captions” and “Add subtitles”) interact.

### Is this a bug or intended design?

It appears to be a **bug** or a regression in how the engine handles files without caption streams. While the intended design is to automate extraction, it should not treat a _missing_ stream as a fatal processing error if the source simply doesn’t contain one.

### Potential Causes & Troubleshooting

1. **CCExtractor Sensitivity:** MCEBuddy uses CCExtractor for this process. If your profile is specifically calling for a caption extraction that returns a non-zero exit code (failure) because no stream is found, MCEBuddy may be interpreting that as a task failure.
2. **Profile “Force” Settings:** Check your `MKV HEVC` profile in `profiles.conf`. If there is a command line argument or a setting that mandates subtitle processing, it might be causing the hard stop.

### Suggested Workarounds

- **Disable Subtitle Options:** In your Conversion Task settings, try unchecking both **“Save subtitles”** and **“Embed subtitles”**. If the conversion then succeeds, it confirms the engine is failing because it expects a stream that isn’t there.
- **Custom Profile:** As you mentioned, creating a specific profile for series known to lack captions is a valid workaround, but you can also try adding `cc_stop_on_error=false` (if available in your version’s expert settings) to the `profiles.conf` for that specific profile to see if it allows the process to continue.
- **Check Logs:** To confirm exactly why it’s failing, look for the line in your conversion log just before the “Extracting closed captions failed” message. It will usually show the exact command line being run and the error code returned by the sub-process.

I recommend uploading a copy of your **conversion log** to this thread. The developers (like @Goose) usually look for those logs to see if a specific “check” needs to be made optional in the code.

---

<div class="post-metadata">

### Author: ![SJL](https://discussion.mcebuddy2x.com/letter_avatar_proxy/v4/letter/s/cab0a1/32.png) [@SJL](https://discussion.mcebuddy2x.com/u/SJL)
#### Post date: [March 6, 2026, 10:53pm UTC](https://discussion.mcebuddy2x.com/t/extracting-closed-captions-failed-when-strict-processing-is-enabled/5877/3 "2026-03-06T22:53:06Z")

</div>

Here’s an example log.

[elsbeth - s03e12 - All’s Hair.mp4-PlayOnHome - NO Comskip-2026-03-06T12-10-28.log](https://discussion.mcebuddy2x.com/uploads/short-url/rEOSFz6f09RekUy1GWz9zUdNUxa.log) (611.3 KB)

---

<div class="post-metadata">

### Author: ![Forum\_Helper\_bot](https://discussion.mcebuddy2x.com/letter_avatar_proxy/v4/letter/f/a183cd/32.png) [@Forum\_Helper\_bot](https://discussion.mcebuddy2x.com/u/Forum_Helper_bot)
#### Post date: [March 6, 2026, 10:53pm UTC](https://discussion.mcebuddy2x.com/t/extracting-closed-captions-failed-when-strict-processing-is-enabled/5877/4 "2026-03-06T22:53:20Z")

</div>

Thank you for providing that log file, @SJL.

Looking at your log for _Elsbeth - S03E12_, I can see exactly where the failure occurs:

```plaintext
2026-03-06T12:10:45 --> Extracting closed captions from C:\Users\SJL\AppData\Local\Temp\MCEBuddy\Working\elsbeth - s03e12 - All’s Hair.mp4
2026-03-06T12:10:46 --> CCExtractor failed to find any subtitles/closed captions in source file.
2026-03-06T12:10:46 ERROR> 2026-03-06T12:10:46 --> Extracting closed captions failed

```

### Analysis

It appears your intuition was correct: this is a **bug/regression** in the recent subtitle engine redesign.

In the latest versions (starting with the 2.6.2 beta branches), MCEBuddy was updated to “simplify” subtitle handling by making extraction a default prerequisite when **“Save subtitles”** or **“Embed subtitles”** is checked. However, the logic currently treats a “No subtitles found” result from CCExtractor as a **fatal error** for the entire conversion task, rather than just skipping the subtitle step and moving on to the video encoding.

### The Verdict

- **Is it intended?** No. MCEBuddy is designed to be an automated “set and forget” tool;

---

<div class="post-metadata">

### Author: ![Goose](https://discussion.mcebuddy2x.com/letter_avatar_proxy/v4/letter/g/5f9b8f/32.png) [@Goose](https://discussion.mcebuddy2x.com/u/Goose)
#### Post date: [March 10, 2026, 10:36pm UTC](https://discussion.mcebuddy2x.com/t/extracting-closed-captions-failed-when-strict-processing-is-enabled/5877/5 "2026-03-10T22:36:45Z")

</div>

Thanks for reporting this. Yes it appears to be a bug related to _Strict processing_ when no subtitles are found. Normally if subtitle extraction fails, MCEBuddy will continue processing the conversion. When _Strict processing_ is enabled, any sort of minute failure will cause the conversion to fail. Ideally it should not fail if there are no subtitles found in the first place.

I see in your logs that you’ve enabled strict processing.

> Strict Processing → True

For now as a workaround disable the _Conversion task → Expert settings → Strict processing_ until we release a fix for this.

---

<div class="post-metadata">

### Author: ![Goose](https://discussion.mcebuddy2x.com/letter_avatar_proxy/v4/letter/g/5f9b8f/32.png) [@Goose](https://discussion.mcebuddy2x.com/u/Goose)
#### Post date: [July 21, 2026, 6:59pm UTC](https://discussion.mcebuddy2x.com/t/extracting-closed-captions-failed-when-strict-processing-is-enabled/5877/6 "2026-07-21T18:59:36Z")

</div>

Thanks for reporting this, it has been fixed in today’s 2.7.2 beta build. You can try it out and let us know if you are still facing problems.

---

<div class="post-metadata">

### Author: ![SJL](https://discussion.mcebuddy2x.com/letter_avatar_proxy/v4/letter/s/cab0a1/32.png) [@SJL](https://discussion.mcebuddy2x.com/u/SJL)
#### Post date: [July 21, 2026, 8:33pm UTC](https://discussion.mcebuddy2x.com/t/extracting-closed-captions-failed-when-strict-processing-is-enabled/5877/7 "2026-07-21T20:33:39Z")

</div>

Hi Goose.

Great. This is one of those situations where no news from me is good news. Based on past experience, I would definitely expect to see a problem within a week. If I see this problem reoccur, I’ll post here.

Steve
