Project

General

Profile

Bug #217

"Waiting for audio lock" On Seemingly Supported Codecs

Added by Daniel Carleton - about 9 years ago. Updated almost 9 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

History

#1 Updated by Andreas Smas almost 9 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

Also available in: Atom PDF