Project

General

Profile

Actions

Bug #217

closed

"Waiting for audio lock" On Seemingly Supported Codecs

Added by Daniel Carleton - almost 15 years ago. Updated almost 15 years ago.

Status:
Fixed
Priority:
High
Assignee:
-
Category:
General
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Found in version:
Affected Versions:

Description

I'm able to record one known channel, but others hang with a "Waiting for audio lock" message in the recorder schedule view. This behavior is consistent, and I can switch back and forth between the working channel and the non-working ones with the same results.

The last line in the debug log before the hang always looks something like this:

Jun 01 12:38:39 dvr: Dr. Christiane Northrup: Women's Bodies, Women's Wisdom.2010-06-01 from adapter: "LG Electronics LGDT3303 VSB/QAM Frontend", network: "", mux: "555,000 kHz", provider: "", service: "KCTS" 

The working and non-working channels yield the same details when hitting "i" in the service grid:

PID Type Details
2368 MPEG2VIDEO 29.97 Hz
2369 MPEG2AUDIO eng
2370 MPEG2AUDIO spa

Here is ""the email thread"":http://mail.lonelycoder.com/pipermail/hts-devel/2010-May/001160.html related to this ticket.

Attached are full DVB MUX for both a working and a non-working recording.

MUX File Debug Log File Works?
""_dev_dvb_adapter0_LG_Electronics_LGDT3303_VSB_QAM_Frontend555000000.dump3.ts"":http://dacc.s3.amazonaws.com/misc/tvheadend/_dev_dvb_adapter0_LG_Electronics_LGDT3303_VSB_QAM_Frontend555000000.dump3.ts ""nonworking.log"":http://dacc.s3.amazonaws.com/misc/tvheadend/nonworking.log No
""_dev_dvb_adapter0_LG_Electronics_LGDT3303_VSB_QAM_Frontend573012500.dump2.ts"":http://dacc.s3.amazonaws.com/misc/tvheadend/_dev_dvb_adapter0_LG_Electronics_LGDT3303_VSB_QAM_Frontend573012500.dump2.ts ""working.log"":http://dacc.s3.amazonaws.com/misc/tvheadend/working.log Yes
Actions #1

Updated by Andreas Smas almost 15 years ago

  • Status changed from New to Fixed
  • Found in version set to fixed

Based on the .ts files it seems that tvheadend misinterpreted the audio stream type.
It is actually AC3.

Fixed in r4962

Actions

Also available in: Atom PDF