Regression in 2026.10.15.2331:

Beta Community DVR Beta
#1

Regression in 2026.10.15.2331: updating broke fingerprint generation, playback, and commercial detecting & editing.

(“signal: abort trap”)

I updated Channels DVR Server to prerelease 2026.10.15.2331 today (10/18/26) to address the Spectrum Adobe authentication issue (I was previously running 2026.09.05.0220, but had a problem earlier this am when a Spectrum recording failed and showed this error message: “failing: could not start stream on channels= [6039]: TVE: adobe.pending Logout reason=34764”).

The Spectrum TVE issue appears to have been resolved with the update, but appears to have reintroduced another serious media-processing problem by breaking commercial detection (for both live and playback),

Environment

  • Channels DVR Server: 2026.10.15.2331
  • Server platform: Mac mini running macOS Sequoia
  • Client: MacBook Pro using Safari and the Channels DVR web admin interface
  • Recording storage: External volume mounted at /Volumes/MM for Channels DVR/

Symptoms

Recordings made before the update, including recordings from the previous evening and this morning continue to play normally on iOS and Apple TV. I can also edit or re-edit their commercial breaks normally.

ALL new recordings made after the update exhibit the following problem:

  1. Fingerprint generation fails. The server reports “signal: abort trap” when attempting to probe the recordings and generate fingerprints.
  2. Commercial redetection fails. Attempting to redetect commercials produces the same abort error.
  3. Commercial editing is unavailable. Under Manage Actions, the options to edit or re-edit commercials are missing entirely. The available actions include reprocessing the video, fixing video timestamps, and redetecting commercials.
  4. Playback fails in Safari. When I attempt to play a new recording on my MacBook Pro, Safari reports: “The media could not be loaded either because the server or network failed or because the format is not supported.” It repeatedly attempts to reconnect before eventually giving up.

This is the first time I have encountered these symptoms since I began using Channels DVR (only a few months now).

The distinction between old and new recordings is particularly significant: older recordings retain their playback and commercial-editing functionality, while new recordings made after the latest update do not.

Relevant server log excerpts

The following entries are from October 18, 2026.

The Great Debaters (file-3256):

2026/10/18 17:01:00.943312 [DVR] Processing file-3256: Movies/The Great Debaters (2007) 2026-10-18-1400.mpg

2026/10/18 17:01:00.971808 [ERR] Could not probe file 3256: signal: abort trap

2026/10/18 17:01:02.155179 [DVR] Generating fingerprint for file-3256: The Great Debaters (2007) 2026-10-18-1400.mpg

2026/10/18 17:01:02.182660 [ERR] Generating fingerprint failed for file-3256: probe file: /Volumes/MM for Channels DVR/Movies/The Great Debaters (2007) 2026-10-18-1400.mpg: signal: abort trap

Mutiny on the Bounty (file-3255):

2026/10/18 17:08:52.535645 [DVR] Generating fingerprint for file-3255: Mutiny on the Bounty 2026-10-18-1205.mpg

2026/10/18 17:08:52.549744 [ERR] Generating fingerprint failed for file-3255: probe file: /Volumes/MM for Channels DVR/Movies/Mutiny on the Bounty 2026-10-18-1205.mpg: signal: abort trap

2026/10/18 17:11:42.338880 [ERR] Failed to probe file #3255: signal: abort trap

2026/10/18 17:11:42.449643 [HLS] Couldn't generate master playlist: Couldn't probe recording: /Volumes/MM for Channels DVR/Movies/Mutiny on the Bounty 2026-10-18-1205.mpg

2026/10/18 17:11:44.328905 [ERR] Failed to probe file #3255: signal: abort trap

2026/10/18 17:11:44.329556 [HLS] Couldn't generate master playlist: Couldn't probe recording: /Volumes/MM for Channels DVR/Movies/Mutiny on the Bounty 2026-10-18-1205.mpg

2026/10/18 17:11:46.352712 [ERR] Failed to probe file #3255: signal: abort trap

2026/10/18 17:11:46.353764 [HLS] Couldn't generate master playlist: Couldn't probe recording: /Volumes/MM for Channels DVR/Movies/Mutiny on the Bounty 2026-10-18-1205.mpg

2026/10/18 17:14:00.439044 [MTS] Rewriting video timestamps for file-3255: Mutiny on the Bounty 2026-10-18-1205.mpg

2026/10/18 17:16:44.652850 [MTS] Statistics for #3255 "Mutiny on the Bounty 2026-10-18-1205.mpg": discontinuity_detected=4 transport_errors=0 saw_pcr=true saw_pmt=true highest_pts=12741.397289

2026/10/18 17:16:45.782143 [MTS] Finished rewriting video timestamps for file-3255 in 2m45s

2026/10/18 17:16:45.794682 [ERR] Could not probe file 3255: signal: abort trap

2026/10/18 17:16:46.427404 [DVR] Generating fingerprint for file-3255: Mutiny on the Bounty 2026-10-18-1205.mpg

2026/10/18 17:16:46.433393 [ERR] Generating fingerprint failed for file-3255: probe file: /Volumes/MM for Channels DVR/Movies/Mutiny on the Bounty 2026-10-18-1205.mpg: signal: abort trap

The timestamp rewriting operation completes, but the subsequent probe and fingerprint-generation attempts still abort.

Suspected regression

The timing strongly suggests that prerelease 2026.10.15.2331 may have reintroduced a bug in media probing or fingerprint generation on macOS.

The failure is not limited to commercial detection: the same probe failure prevents the HLS service from generating a master playlist for at least one affected recording, which corresponds with the Safari playback failure.

The simultaneous loss of fingerprint generation, commercial redetection, commercial-editing actions, and Safari playback suggests a problem in a shared media-processing component rather than simply an inaccurate commercial-detection result.

Could the developers investigate whether build 2026.10.15.2331 introduced a regression in the media-probing or fingerprint-generation code path on macOS? I would appreciate confirmation of whether this is a known (ie previously-reported) issue, and whether a fix or workaround is available.

TIA!

#2

Seeing something similar in 2026.10.15.2239

machine info:

Channels DVR Server2026.10.15.2239Up 3 days·Apple Macmini8,1·4-core Intel(R) Core(TM) i3-8100B CPU @ 3.60GHz·macOS 15.8.1·EDT

Log excerpt of a recording and post-recording failure:

2026/10/16 19:00:02.109079 [DVR] Starting job 1792191600-1 Wheel of Fortune on ch=[38.1]
2026/10/16 19:00:02.109846 [DVR] Waiting 2h59m58s until next job 1792202400-23 NewsCenter 5 at 10
2026/10/16 19:00:02.594160 [TNR] Opened connection to 10A3D007/2 for ch38.1 WSBK-TV
2026/10/16 19:00:02.983155 [DVR] Recording for job 1792191600-1 from 10A3D007 ch38.1 into "TV/Wheel of Fortune/Wheel of Fortune S44E25 NBA Week 2026-10-16-1900.mpg" for 29m57.890071s
2026/10/16 19:00:03.697212 [IDX] Generating video index for job 1792191600-1
2026/10/16 19:30:00.073012 [TNR] Closed connection to 10A3D007/2 for ch38.1 WSBK-TV
2026/10/16 19:30:00.175053 [SNR] Signal statistics for "TV/Wheel of Fortune/Wheel of Fortune S44E25 NBA Week 2026-10-16-1900.mpg": ss=99%-100% snq=99%,93%-100% seq=100% bps=9990061,4719552-14838464 pps=855,404-1273
2026/10/16 19:30:00.271996 [SNR] Buffer statistics for "TV/Wheel of Fortune/Wheel of Fortune S44E25 NBA Week 2026-10-16-1900.mpg": buf=0% drop=0%
2026/10/16 19:30:00.273337 [DVR] Finished job 1792191600-1 Wheel of Fortune
2026/10/16 19:30:00.548127 [DVR] Waiting 2h29m59s until next job 1792202400-23 NewsCenter 5 at 10
2026/10/16 19:30:00.676537 [DVR] Processing file-6319: TV/Wheel of Fortune/Wheel of Fortune S44E25 NBA Week 2026-10-16-1900.mpg
2026/10/16 19:30:00.701149 [ERR] Could not probe file 6319: signal: abort trap
2026/10/16 19:30:01.319392 [DVR] Generating fingerprint for file-6319: Wheel of Fortune S44E25 NBA Week 2026-10-16-1900.mpg
2026/10/16 19:30:01.370142 [ERR] Generating fingerprint failed for file-6319: probe file: /Volumes/TwoTB/Channels/TV/Wheel of Fortune/Wheel of Fortune S44E25 NBA Week 2026-10-16-1900.mpg: signal: abort trap
1 Like
#3

We're looking into it. It appears this was related to updates to our build tools.

1 Like
#4

Thanks for looking into this, Eric.

Since I installed the above-mentioned update yesterday, I’m already up to about ~20 affected recordings, including 30-minute shows recorded via passes as well as a few one-off movies.

Since the installed build is dated 10/15, the affected recordings and jobs could potentially be identified from their processing history in the error log, avoiding the considerable work of manually resubmitting each job that’s currently stuck in limbo (ie hopefully the fix will allow CDVR to recover and reprocess these existing recordings automatically, without requiring users to delete or manually resubmit them).

#5

Please try this out and see if it'll fix the issue:

@Feefer I'll have to get back to you on how best to recover from this.

1 Like
#6

Thanks for the prompt response, Eric. :+1:

My server is a 2018 Intel Mac mini (3.2 GHz 6-core i7-8700B, 8 GB RAM), which I just screen-shared into from my 2018 MacBook Pro to check the available prerelease.

It shows 2026.10.19.1653, rather than 1630.

Can you clarify whether .1653 includes the Intel macOS FFmpeg crash fix from .1630, and whether this update is also expected to resolve the probe/fingerprint generation/Comskip detection failures associated with the abort traps described in this thread?

(I have a recording that’ll end in about 30 min, & don’t want to abort the recording just to update… Next recording in queue is tonight at 6:30PM, so will have about 7 hours to work out this tech issue).

TIA!

#7

I'm doing a reprocess of my library, via Settings>Recording, Commercial Detection section, Media fingerprints, using the "reprocess" button.
Logs show steady progress on each file.

#8

Yes, unless specified in the release notes, any subsequent release has all of the changes from the previous releases.

Yes, that is the expectation.

Right now it will take running Reprocess Video and Redetect Commercials on each recording, but we are looking at ways to help automate that process to recover from this.

1 Like
#9

Thanks for the clarification. :+1:

I’ll go ahead and install the upgrade, as the recording completed (what’s bizarre is that even though I didn’t install the update and restart server (I only downloaded it), it seems to have fixed the issue!).

Here’s the most recent log entries, which suggests it’s now fixed, even without completing the install process!

2026/10/19 11:01:03.519322 [DVR] Processing file-3287: Movies/Seven Days in May (1964) 2026-10-19-0815.mpg
2026/10/19 11:01:07.297039 [DVR] Generating fingerprint for file-3287: Seven Days in May (1964) 2026-10-19-0815.mpg
2026/10/19 11:11:53.096574 [DVR] Generated fingerprint for file-3287 in 10m46s
2026/10/19 11:12:02.537966 [DVR] Completed Enhanced commercial detection on file 3287 (Movies/Seven Days in May (1964) 2026-10-19-0815.mpg) in 9s

I’m not sure if you changed something on your side, but the ability to edit commercials and watch ffmpeg playback is now back for the latest recording (I went back and checked the 30 or so possibly-corrupted recordings from after yesterday’s update, and they’ll require manual reprocessing, but I have a bit of time, so that shouldn’t be a problem. I also see in the log that after latest update and restart, CDVR is resubmitting older files for comskip evaluation, so I may just give it a little bit of time to settle the problem out on its own…).

#10

So just as a follow-up:

I installed the latest upgrade and submitted recordings for reprocessing (that alone causes files to undergo comskip), and so far, so good.

All problems seems to be resolved, so shout out to Eric! :clap:

BTW, whoever thought to add that “split” feature when verifying commercials must’ve read my mind, as that’s exactly the kind of useful feature which expands the power of comskip (I’ve lost count of how many times I’ve resubmitted commercial detection to give it another chance to pick up on a missed boundary, only for it to make the same mistake again by mashing up the commercial with the program yet again! Worse, it still gives itself a perfect score for commercial detection).

:joy:

I’ve always thought users should have a way to point out the error to CDVR, and give it a chance to fix where it went astray, so was pleasantly surprised to see the split feature added to the latest update.

That’s the kind of useful feature which makes CDVR such a useful tool over its competition (now if only CDVR devs added the ability to add negative (ie custom) start and end pads to one-off recordings, as is offered when creating passes! Heck, I’d be even happier if devs offered per-channel custom star and end settings, but that’s asking a lot (it makes sense though, as most broadcasters consistently offset shows, whether it requires a 30 sec start pad or a delay of start time, etc).

This is exactly the precise level of fine-tune control over recordings which made me decide in favor of CDVR vs Emby (despite their native integration of metadata having a slight edge). The cosmetics are great, but ultimately meaningless unless the recording mechanics are working well (Emby’s recording pads were far too imprecise to be useable).

1 Like
#11

To what degree is comskip nondeterministic?

1 Like
#12

I’m referring to situations where eg CDVR missed a commercial break in the show, so created a much-larger block of content that’s over twice as large as the other content blocks in the same program.

(You don’t need to use AI to know that just doesn’t make any sense…Broadcasters typically run commercial breaks of ~ the same length throughout the show, unless it’s a channel like TCM, PBS, etc which take pride in running commercial-free movies…)

If you downloaded the latest pre-release version of CDVR, you’d see how commercial verification process has been improved to allow users the opportunity to “split” segments, an especially helpful feature when dealing with border regions to fine-tune results (as I said, before this update, clicking on re-detect commercials more often failed to fix the missed segment more often that it successfully detected the start of a commercial block, which left me wondering what the redetect commercials button was even for, since it didn’t seem to help; worse, it didn’t change the quality score, the metric CDVR uses to gauge how well the comskim function works…)

1 Like