ffprobe duration WARN 대량 발생 원인 분석 — 빈 OGG 세그먼트 / 캡션 probe 비대칭

cf. 초기 AI 스냅샷(WARN 1,738 / ffprobe 896)과 시점 차이로 절대값은 다르나 "ffprobe가 WARN 최다·대부분 End of file" 구조는 동일. 단 AI가 "No valid segments 1건"이라 한 것은 실제 27건으로 과소집계였음.

ffprobe 실패 1,224건을 에러 종류로 분류하면, 구조가 깨진(손상된) 파일을 가리키는 Invalid data found는 0건이다.

수십 건(consumer 실패 28+12, ffmpeg 크래시 24)의 사고가 1,200건의 빈 세그먼트를 만들 수 없다. 빈 세그먼트는 거의 모든 수업에서 방당 ~20개씩 고르게 나오는 상시 현상이다.

4-1. 세그먼트는 producer 교체마다 갈라진다

recordingManager.ts — replaceChildConsumer/replaceAiConsumer → transitionFfmpeg

if (session.childPair) {
  session.childProducer = childProducer;
  if (session.ffmpegProcess) {
    await this.transitionFfmpeg(session, router);   // ← 매 producer 교체마다 새 세그먼트
  }
}
…
private async transitionFfmpeg(session, router) {
  …
  const segNum = ++this.segmentCounter;
  session.recordingPath = join(RECORDING_TMP_DIR, `${roomId}_${startedAt}_seg${segNum}.ogg`);  // 새 .ogg
  await this.startFfmpeg(session);   // 새 ffmpeg + pushOggSegment 등록
}

아동 마이크/핑퐁이(AI) 오디오 트랙이 재발행될 때마다(발화 단위·활동 전환·재접속) producer가 교체되고, 그때마다 세그먼트가 끊긴다. 교체가 연달아 일어나면 방금 연 세그먼트가 오디오를 거의 못 받고 닫혀 빈 OGG가 된다. → 방당 ~20개 누적.

4-2. 비대칭 — 빈 파일 필터가 한쪽(오디오)에만 있다

// ② 오디오 경로 — 빈 파일을 제대로 거른다
private async collectSegment(session) {
  const fileStat = await stat(session.recordingPath);
  if (fileStat.size > 0) session.segmentPaths.push(session.recordingPath);
}

// ① 캡션 경로 — 크기 검사 없이 전부 probe (← WARN 노이즈의 출처)
private async buildAndUploadCaptions(session, mp3S3Key) {
  const segments = await Promise.all(
    session.oggSegments.map(async (seg) => ({
      ...seg,
      audioDurationMs: (await probeAudioDurationMsSafe(seg.filePath)) ?? 0,  // 빈/없는 파일도 그대로 probe
    })),
  );
}

캡션을 MP3 타임라인에 맞추려 각 세그먼트 duration이 필요해서 oggSegments를 순회하는데, ②에 있는 size>0 가드가 ①엔 없다. 그래서 오디오에선 버려진 빈/없는 파일이 캡션 probe에선 검사되고 → ffprobe duration measurement failed WARN → null(=0ms) 반환.

ffprobe.ts의 probeAudioDurationMsSafe는 실패를 잡아 WARN 로깅 후 null 반환 → 캡션 계산엔 0ms로 무해하게 처리됨.

위 노이즈와 독립적으로, ffmpeg 비정상 종료(Active ffmpeg exited abnormally, 24건/24h) 중 다수는 RTP 수신 UDP 포트 bind 충돌이다. 오늘 7건 분석에서 5건이 bind failed: Address already in use였다.

// udpPort.ts — 포트를 bind해 번호만 읽고 소켓을 닫아버림 (TOCTOU)
socket.bind(0, "127.0.0.1", () => {
  const port = socket.address().port;
  socket.close(() => resolve(port));   // 닫는 순간부터 포트 free → ffmpeg가 늦게 bind하면 충돌
});

확보(close)와 ffmpeg 실제 bind 사이에 다른 reserve(ai 입력·dual-spawn 새 ffmpeg·다른 방)가 같은 포트를 선점 → code=1 종료 → 그 세그먼트 1개가 빈다. ffprobe 실패의 ~8%만 설명하므로 WARN 노이즈의 주범은 아니나, 크래시·간헐적 녹음 손실 위험이 있어 별도 처리가 필요하다.

개선 우선순위

1. [노이즈 제거 · 우선] 캡션 probe에 ②의 가드를 ①에도 적용 — buildAndUploadCaptions의 probe 루프 전에 oggSegments를 size>0/존재 여부로 거르거나, 빈/없는 파일은 0ms로 조용히 스킵(WARN 미발생). 하루 ~1,200건 노이즈 즉시 제거, 결과 동일.
2. [근본 · 선택] 빈 세그먼트 자체를 덜 만들기 — 연속 producer 교체를 디바운스/병합하거나, 직전 세그먼트가 일정 ms 미만이면 새 세그먼트를 끊지 않고 합치는 식으로 빈 세그먼트 생성 자체를 줄임.
3. [별개 이슈 · §6] 포트 충돌 제거 — reserveLocalUdpPort가 소켓을 닫지 말고 fd를 ffmpeg에 인계하거나, EADDRINUSE 감지 시 새 포트로 세그먼트 재시작. ffmpeg 크래시 24건/일 제거.