Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 9 years ago

Closed 9 years ago

Last modified 7 years ago

#343 closed defect (invalid)

'Signal 100% (l ) no lock' and no video with DVB-S and DVB-T

Reported by: daniel.danner@… Owned by: danielk
Priority: major Milestone: 0.19
Component: mythtv Version: head
Severity: high Keywords:
Cc: Ticket locked: no

Description

Although all problems with dvb and black screens were reported as solved in newest revisions, I'm still experiencing them.

My frontend runs rev 7266 fine, and it also works in combination with rev 7026 on the backend machine. Upgrading the backend to rev 7266 leads to black screens in LiveTV with "Signal Lock 100% (l ) No Lock" written on the OSD.

Here's the output of mythbackend -v record,channel,siparser:

$ mythbackend -v record,channel,siparser
2005-09-16 22:17:54.066 Using runtime prefix = /usr/local
2005-09-16 22:17:54.090 New DB connection, total: 1
Starting up as the master server.
2005-09-16 22:17:54.111 New DB connection, total: 2
2005-09-16 22:17:54.115 New DB connection, total: 3
2005-09-16 22:17:54.126 DVB#0 Device Name: 'ST STV0299 DVB-S'
2005-09-16 22:17:54.126 DVB#0 Opening DVB channel
2005-09-16 22:17:54.127 DVB#0 Using DVB card 0, with frontend ST STV0299 DVB-S.
2005-09-16 22:17:54.567 DVB#0 Trying to tune to channel 26.
2005-09-16 22:17:54.570 DVB#0 Frequency: 12187500 Symbol Rate: 27500000 Pol: H/L Inv: Auto
2005-09-16 22:17:54.571 DVB#0 Setting LNB: Tone ON 18V
2005-09-16 22:17:54.588 DVB#0 Old Params: freq(0) type(QPSK)
2005-09-16 22:17:54.588 DVB#0 New Params: freq(12187500) type(QPSK)
2005-09-16 22:17:54.589 dvbchannel.cpp:wait_for_backend: Status: Signal,Carrier,
2005-09-16 22:17:54.589 DVB#0 DVBChannel::Tune: Frequency tuning successful.
2005-09-16 22:17:54.589 DVB#0 Tuned to frequency for channel 26.
2005-09-16 22:17:54.589 SetSignalMonitoringRate(50, 0)
2005-09-16 22:17:54.589 SetupSignalMonitor()
2005-09-16 22:17:54.589 DVB#0 Opening DVB channel
2005-09-16 22:17:54.589 SetupSignalMonitor() -- DVB hack begin
2005-09-16 22:17:54.589 SetupSignalMonitor() -- DVB hack end
2005-09-16 22:17:54.592 SM(0)::AddFlags: Seen() Match() Wait(Sig,SNR,BER,UB,)
2005-09-16 22:17:54.592 DVBSM(0)::constructor(): initial flags 0x7400000
2005-09-16 22:17:54.593 signal monitor successfully created
2005-09-16 22:17:54.593 Setting up table monitoring.
2005-09-16 22:17:54.593 Not ATSC channel: major(-1) minor(-1).
2005-09-16 22:17:54.593 mpeg program number: 12020
2005-09-16 22:17:54.594 DTVSM(0)::SetProgramNumber(12020): 
2005-09-16 22:17:54.594 SM(0)::RemoveFlags: Seen(PMT,) Match(PMT,) Wait()
2005-09-16 22:17:54.594 SM(0)::AddFlags: Seen() Match() Wait(PMT,)
2005-09-16 22:17:54.595 SM(0)::AddFlags: Seen() Match() Wait(PAT,PMT,)
2005-09-16 22:17:54.595 Successfully set up MPEG table monitoring.
2005-09-16 22:17:54.595 SM(0)::Start: begin
2005-09-16 22:17:54.597 SM(0)::Start: end
2005-09-16 22:17:54.597 DTVSM(0)::GetStatusList: WaitForPMT seen(0) matching(0)
2005-09-16 22:17:54.599 DVBSM(0)::UpdateValues: Signal Locked
2005-09-16 22:17:54.599 DVBSM(0)::UpdateValues: Waiting for table monitor to start
2005-09-16 22:17:54.600 DVBSM(0)::UpdateValues: Table monitor started
2005-09-16 22:17:54.615 DVBSM(0)::RunTableMonitor(): begin (# of pids 2)
2005-09-16 22:17:54.616 DVBSM(0)::AddPIDFilter(0x0): 
2005-09-16 22:17:54.619 DVBSM(0)::AddPIDFilter(0x1ffb): 
2005-09-16 22:17:54.625 SM(0)::AddFlags: Seen(PAT,) Match() Wait()
2005-09-16 22:17:54.626 SM(0)::AddFlags: Seen() Match(PAT,) Wait()
2005-09-16 22:17:54.626 CreatePATSingleProgram()
2005-09-16 22:17:54.626 PAT in input stream
2005-09-16 22:17:54.626 Program Association Table
 PSIP prefix(0x0) tableID(0x0) length(41) extension(0x441)
      version(21) current(1) section(0) last_section(0)
         tsid: 1089
 programCount: 8
  program number 0 has PID 0x  10   data  0x0 0x0 0x224 0x16
  program number 12003 has PID 0x  2c   data  0x46 0x227 0x224 0x44
  program number 12020 has PID 0x  2e   data  0x46 0x244 0x224 0x46
  program number 12040 has PID 0x  2d   data  0x47 0x8 0x224 0x45
  program number 12060 has PID 0x  2f   data  0x47 0x28 0x224 0x47
  program number 12090 has PID 0x  30   data  0x47 0x58 0x224 0x48
  program number 12080 has PID 0x  29   data  0x47 0x48 0x224 0x41
  program number 12095 has PID 0x  31   data  0x47 0x63 0x224 0x49

2005-09-16 22:17:54.626 desired_program(12020) pid(0x2e)
2005-09-16 22:17:54.626 pmt_pid(0x2e)
2005-09-16 22:17:54.626 PAT for output stream
2005-09-16 22:17:54.626 Program Association Table
 PSIP prefix(0x0) tableID(0x0) length(13) extension(0x441)
      version(21) current(1) section(0) last_section(0)
         tsid: 1089
 programCount: 1
  program number 1 has PID 0x  2e   data  0x0 0x1 0x224 0x46

2005-09-16 22:17:54.627 DVBSM(0)::AddPIDFilter(0x2e): 
2005-09-16 22:17:54.648 SM(0)::AddFlags: Seen(PMT,) Match() Wait()
2005-09-16 22:17:54.649 SM(0)::AddFlags: Seen() Match(PMT,) Wait()
2005-09-16 22:17:54.649 CreatePMTSingleProgram()
2005-09-16 22:17:54.649 PMT in input stream
2005-09-16 22:17:54.649 Program Map Table ver(18) pid(0x2e) pnum(12020)

 Stream #0 pid(0xa6) type(video-mpeg2  0x2)
 Stream #1 pid(0x80) type(audio-mp1-layer[1,2,3]  0x3)
     ISO-639 Language Descriptor (0xa) length(4)
 Stream #2 pid(0x457) type(private-sec  0x5)
     Application Signalling Descriptor (0x6f) length(3)
 Stream #3 pid(0x44) type(private-data  0x6)
     Teletext Descriptor (0x56) length(5)
 Stream #4 pid(0x44c) type(dsmcc-b std data  0x11)
     Unknown Descriptor (0x14) length(13)
     Unknown Descriptor (0x13) length(5)
     Stream Identifier Descriptor (0x52) length(1)
     Data Broadcast Identifier Descriptor (0x66) length(4)

2005-09-16 22:17:54.649 PMT for output stream
2005-09-16 22:17:54.649 Program Map Table ver(18) pid(0x2e) pnum(1)

 Stream #0 pid(0xa6) type(video-mpeg2  0x2)
 Stream #1 pid(0x80) type(audio-mp1-layer[1,2,3]  0x3)

2005-09-16 22:17:54.664 DTVSM(0)::GetStatusList: WaitForPMT seen(1) matching(1)
2005-09-16 22:17:54.665 SetSignalMonitoringRate(0, 0)
2005-09-16 22:17:54.665 TeardownSignalMonitor() -- begin
2005-09-16 22:17:54.665 DVBSM(0)::Stop: begin
2005-09-16 22:17:54.665 SM(0)::Stop: begin
2005-09-16 22:17:54.704 SM(0)::Stop: end
2005-09-16 22:17:54.705 DVBSM(0)::RunTableMonitor(): shutdown
2005-09-16 22:17:54.705 DVBSM(0)::RemovePIDFilter(0x0): 
2005-09-16 22:17:54.705 DVBSM(0)::RemovePIDFilter(0x2e): 
2005-09-16 22:17:54.706 DVBSM(0)::RemovePIDFilter(0x1ffb): 
2005-09-16 22:17:54.710 DVBSM(0)::RunTableMonitor(): end
2005-09-16 22:17:54.711 DVBSM(0)::Stop: end
2005-09-16 22:17:54.712 DVBSM(0)::Stop: begin
2005-09-16 22:17:54.712 SM(0)::Stop: begin
2005-09-16 22:17:54.712 SM(0)::Stop: end
2005-09-16 22:17:54.712 DVBSM(0)::Stop: end
2005-09-16 22:17:54.712 SM(0)::Stop: begin
2005-09-16 22:17:54.712 SM(0)::Stop: end
2005-09-16 22:17:54.712 TeardownSignalMonitor() -- end
2005-09-16 22:17:54.717 DVB#0 Closing DVB channel
2005-09-16 22:17:54.753 New DB scheduler connection
2005-09-16 22:17:54.759 mythbackend version: 0.19.20050712-1 www.mythtv.org
2005-09-16 22:17:54.760 Enabled verbose msgs : important general record channel siparser
2005-09-16 22:17:54.767 New DB connection, total: 4
2005-09-16 22:17:54.770 AutoExpire: Found 1 recorders w/max rate of 138 MiB/min
2005-09-16 22:17:54.772 AutoExpire: space: 3.0 GB w/freq: 10 min
2005-09-16 22:17:56.790 Reschedule requested for id -1.
2005-09-16 22:17:57.230 Scheduled 38 items in 0.4 = 0.26 match + 0.17 place
2005-09-16 22:17:57.246 Recording starts soon, AUTO-Startup assumed
2005-09-16 22:18:30.755 MainServer::HandleAnnounce Playback
2005-09-16 22:18:30.755 adding: mickey as a client (events: 0)
2005-09-16 22:18:30.763 Getting next free recorder after : -1
2005-09-16 22:18:30.765 Checking card 1. Best card so far 1
2005-09-16 22:18:30.776 MainServer::HandleAnnounce Playback
2005-09-16 22:18:30.776 adding: mickey as a client (events: 1)
2005-09-16 22:18:30.787 MainServer::HandleAnnounce Playback
2005-09-16 22:18:30.787 adding: mickey as a client (events: 0)
2005-09-16 22:18:30.805 MainServer::HandleAnnounce Playback
2005-09-16 22:18:30.805 adding: mickey as a client (events: 0)
2005-09-16 22:18:30.813 adding: mickey as a remote ringbuffer
2005-09-16 22:18:30.821 Changing from None to WatchingLiveTV
2005-09-16 22:18:30.844 Using profile 'Live TV' to record
2005-09-16 22:18:30.867 DummyDTVRecorder::StartRecording -- begin
2005-09-16 22:18:30.869 SetRecording(0x0)
2005-09-16 22:18:30.869 SetSignalMonitoringRate(50, 1)
2005-09-16 22:18:30.869 SetupSignalMonitor()
2005-09-16 22:18:30.869 DVB#0 Opening DVB channel
2005-09-16 22:18:30.877 DVB#0 Using DVB card 0, with frontend ST STV0299 DVB-S.
2005-09-16 22:18:31.027 DummyRec: Restart! Frames seen 11
2005-09-16 22:18:31.143 DummyRec: Restart! Frames seen 22
2005-09-16 22:18:31.191 DummyRec: Restart! Frames seen 33
2005-09-16 22:18:31.243 DummyRec: Restart! Frames seen 44
2005-09-16 22:18:31.292 DummyRec: Restart! Frames seen 55
2005-09-16 22:18:31.328 SetupSignalMonitor() -- DVB hack begin
2005-09-16 22:18:31.328 SetupSignalMonitor() -- DVB hack end
2005-09-16 22:18:31.329 SM(0)::AddFlags: Seen() Match() Wait(Sig,SNR,BER,UB,)
2005-09-16 22:18:31.329 DVBSM(0)::constructor(): initial flags 0x7400000
2005-09-16 22:18:31.331 signal monitor successfully created
2005-09-16 22:18:31.331 Setting up table monitoring.
2005-09-16 22:18:31.331 Not ATSC channel: major(-1) minor(-1).
2005-09-16 22:18:31.331 mpeg program number: 12020
2005-09-16 22:18:31.331 DTVSM(0)::SetProgramNumber(12020): 
2005-09-16 22:18:31.331 SM(0)::RemoveFlags: Seen(PMT,) Match(PMT,) Wait()
2005-09-16 22:18:31.331 SM(0)::AddFlags: Seen() Match() Wait(PMT,)
2005-09-16 22:18:31.336 SM(0)::AddFlags: Seen() Match() Wait(PAT,PMT,)
2005-09-16 22:18:31.337 Successfully set up MPEG table monitoring.
2005-09-16 22:18:31.337 SM(0)::Start: begin
2005-09-16 22:18:31.341 SM(0)::Start: end
2005-09-16 22:18:31.342 DTVSM(0)::GetStatusList: WaitForPMT seen(0) matching(0)
2005-09-16 22:18:31.344 DummyRec: Restart! Frames seen 66
2005-09-16 22:18:31.460 DummyRec: Restart! Frames seen 77
2005-09-16 22:18:31.513 DummyRec: Restart! Frames seen 88
2005-09-16 22:18:31.788 DummyRec: Restart! Frames seen 99
2005-09-16 22:18:32.066 DummyRec: Restart! Frames seen 110
2005-09-16 22:18:32.349 DummyRec: Restart! Frames seen 121
2005-09-16 22:18:32.626 DummyRec: Restart! Frames seen 132
2005-09-16 22:18:32.889 DummyRec: Restart! Frames seen 143
2005-09-16 22:18:33.149 DummyRec: Restart! Frames seen 154
2005-09-16 22:18:33.394 DummyRec: Restart! Frames seen 165
2005-09-16 22:18:33.658 DummyRec: Restart! Frames seen 176
2005-09-16 22:18:33.924 DummyRec: Restart! Frames seen 187
2005-09-16 22:18:34.181 DummyRec: Restart! Frames seen 198
2005-09-16 22:18:34.446 DummyRec: Restart! Frames seen 209
2005-09-16 22:18:34.721 DummyRec: Restart! Frames seen 220
2005-09-16 22:18:35.094 DummyRec: Restart! Frames seen 231
2005-09-16 22:18:35.369 DummyRec: Restart! Frames seen 242
2005-09-16 22:18:35.636 DummyRec: Restart! Frames seen 253
2005-09-16 22:18:35.914 DummyRec: Restart! Frames seen 264
2005-09-16 22:18:36.164 DummyRec: Restart! Frames seen 275
2005-09-16 22:18:36.450 DummyRec: Restart! Frames seen 286
2005-09-16 22:18:36.727 DummyRec: Restart! Frames seen 297
2005-09-16 22:18:36.797 TVRec::HandleStateChange() Abort starting recording -- begin
2005-09-16 22:18:36.811 SigMon Flags are: Seen() Match() Wait(PAT,PMT,Sig,SNR,BER,UB,)
2005-09-16 22:18:36.812 SML[0]: Name(slock) Val(0) thr(>=1) range(0,1) timeout(3000 ms) is set. Is NOT good.
2005-09-16 22:18:36.812 SML[1]: Name(signal) Val(32767) thr(>=-32768) range(-32768,32767) timeout(3000 ms) is set. Is good.
2005-09-16 22:18:36.812 SML[2]: Name(seen_pat) Val(0) thr(>=1) range(0,1) timeout(0 ms) is set. Is NOT good.
2005-09-16 22:18:36.812 SML[3]: Name(matching_pat) Val(0) thr(>=1) range(0,1) timeout(0 ms) is set. Is NOT good.
2005-09-16 22:18:36.812 SML[4]: Name(seen_pmt) Val(0) thr(>=1) range(0,1) timeout(0 ms) is set. Is NOT good.
2005-09-16 22:18:36.812 SML[5]: Name(matching_pmt) Val(0) thr(>=1) range(0,1) timeout(0 ms) is set. Is NOT good.
2005-09-16 22:18:36.812 SML[6]: Name(snr) Val(32767) thr(>=-32768) range(-32768,32767) timeout(0 ms) is set. Is good.
2005-09-16 22:18:36.812 SML[7]: Name(ber) Val(8744) thr(<=65535) range(0,65535) timeout(0 ms) is set. Is good.
2005-09-16 22:18:36.812 SML[8]: Name(ucb) Val(0) thr(<=65535) range(0,65535) timeout(0 ms) is set. Is good.
2005-09-16 22:18:36.813 TVRec: StartChannel() -- canceled
2005-09-16 22:18:36.813 SetSignalMonitoringRate(0, 0)
2005-09-16 22:18:36.813 TeardownSignalMonitor() -- begin
2005-09-16 22:18:36.813 DVBSM(0)::Stop: begin
2005-09-16 22:18:36.813 SM(0)::Stop: begin
2005-09-16 22:18:36.845 SM(0)::Stop: end
2005-09-16 22:18:36.845 DVBSM(0)::Stop: end
2005-09-16 22:18:36.845 DVBSM(0)::Stop: begin
2005-09-16 22:18:36.845 SM(0)::Stop: begin
2005-09-16 22:18:36.845 SM(0)::Stop: end
2005-09-16 22:18:36.845 DVBSM(0)::Stop: end
2005-09-16 22:18:36.846 SM(0)::Stop: begin
2005-09-16 22:18:36.846 SM(0)::Stop: end
2005-09-16 22:18:36.846 TeardownSignalMonitor() -- end
2005-09-16 22:18:36.846 DummyDTVRecorder::StopRecordingThread(void)
2005-09-16 22:18:36.850 DummyDTVRecorder::FinishRecording()
2005-09-16 22:18:36.854 DummyDTVRecorder::StartRecording -- end
2005-09-16 22:18:36.856 TVRec: StartRecorderPost(): canceled
2005-09-16 22:18:36.856 StartRecorderPost()::closeRecorder -- begin
2005-09-16 22:18:36.856 DummyDTVRecorder::StopRecordingThread(void)
2005-09-16 22:18:36.877 DVB#0 Closing DVB channel
2005-09-16 22:18:36.877 StartRecorderPost()::closeRecorder -- end
2005-09-16 22:18:36.877 TVRec::HandleStateChange() Abort starting recording -- end
2005-09-16 22:18:36.877 TVRec::HandleStateChange(): Null transition None to None
2005-09-16 22:18:36.878 StopLiveTV()::closeRecorder -- begin
2005-09-16 22:18:36.878 StopLiveTV()::closeRecorder -- end rbuffer(0)

If it's any important: I discovered revision 7026 to be the last one, NOT refusing to work because of such errors.

Greetings,
Daniel Danner

Attachments (1)

mythlogs.zip (14.4 KB) - added by adrian.wilkins@… 9 years ago.
mythbackend logs from a system with three DVB-T tuners

Download all attachments as: .zip

Change History (25)

comment:1 Changed 9 years ago by danielk

  • Resolution set to invalid
  • Status changed from new to closed

user error, you need a channel lock before you see any video

comment:2 Changed 9 years ago by daniel.danner@…

  • Resolution invalid deleted
  • Status changed from closed to reopened

Maybe I didn't explain the situation exactly enough...

My hardware works fine, as well as the kernel stuff. I get theses errors above when I try to watch LiveTV with 7266 as backend.

When I re-install 7026 directly after testing 7266, everything works fine and I especially don't need to wait until the end of days to get a signal lock.

So where's the "user error"?

comment:3 Changed 9 years ago by danielk

  • Resolution set to invalid
  • Status changed from reopened to closed

Did you read the commit log for 7226?

comment:4 Changed 9 years ago by daniel.danner@…

(you mean 7266, right?)

I read it know, and tried to increase the timeout values up to 3000/6000 without any success.

comment:5 Changed 9 years ago by danielk

  • Milestone set to 0.19
  • Resolution invalid deleted
  • Status changed from closed to reopened

Yep, I meant 7266..

This looks wierd but appears to be valid so I'm reopening it.

I'll look at the code, but meanwhile can you try setting them to 25000 and 60000
to elimintate timing threshold problems as the cause.

comment:6 Changed 9 years ago by anonymous

  • Milestone 0.19 deleted

Hmm...except that the "100%" doesn't flicker (somewhere between 80 and 100, but mostly 100) anymore, these values didn't improve the situation. :/

comment:7 Changed 9 years ago by anonymous

  • Milestone set to 0.19

Huh, milestone deleted? This didn't happened with intention...sorry.

comment:8 Changed 9 years ago by danielk

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [7267]) Fixes #343.

Looks like the signal and channel timeouts were reversed...

comment:9 Changed 9 years ago by daniel.danner@…

I don't dare to reopen the ticket, but I'm sorry to say that this changeset didn't fix anything for me.

comment:10 Changed 9 years ago by adrian.wilkins@…

  • Resolution fixed deleted
  • Severity changed from medium to high
  • Status changed from closed to reopened
  • Summary changed from 'Signal Lock' and no video with dvb-s, problems still remaining in rev 7266 to 'Signal 100% (l ) no lock' and no video with DVB-S and DVB-T

I dare! This also affects my DVB-T tuner, the Hauppague WinTV Nova-T USB 2.0

It was previously saying "Signal 0% (l ) no lock". Recent patches have amended this to "Signal 100% (l) no lock". Changing the timeout values to ludicrously high values does not resolve this.

This tuner previously worked perfectly with MythTV. It works just fine from the command line. I'm watching a programme streamed to disk over http to my laptop right now. Although there is some odd output from tzap ; I did post about this to the mailing list, but I'm not a member and I think it's still stuck in moderation. The succinct version is that tzap reports the "signal" value as 00000000 when the status is FE_HAS_LOCK. Which strikes me as odd, and I thought that was what was causing the report at the OSD of 0% signal. Now this has changed, I'm stumped again.

I'm happy to work with whoever to resolve this. I specifically got this tuner to replace a rather ropy USB 1.1 tuner (the bandwidth just isn't enough for some DVB streams), so I'm rather keen to see it work properly.

comment:11 Changed 9 years ago by adrian.wilkins@…

Now the USB 1.1 tuner isn't working either ; again, this tuner previously worked just fine. This one just says "Signal % no lock". Raising the timeouts does nothing.

This is a Hauppauge DEC 2000-t.

Since this now represents two-thirds of the tuners I have, this is something I am very keen to resolve. Largely my own fault because I didn't back up my database between version changes (oops). :-)

comment:12 Changed 9 years ago by asmythtv@…

adrian.wilkins@…:

Can you retest with -v all added to the startup for the backend?

Then post the relevant logs.

I had this problem as well, and finally tracked it to the antenna not being in the right position.

I would get a signal_lock - and yet no picture. Moving the antenna fixed it - so I don't see what's the point of a signal_lock, but anyway.

comment:13 Changed 9 years ago by anonymous

I'll grab those logs at the weekend, but I don't think it's down to antenna. The antenna in question is a loft antenna. It's passed through a four way signal amp, because the antenna is feeding four devices and I found the signal level dropped too much to feed them all.

The third tuner in my setup is a PCI Nova-T, MythTV works fine with this one.

Both of the USB devices work well at the command line ; I quantify this as

  • Card locks well using tzap -r
  • Am able to cat the card output from the dvr0 subdevice to a file on disc
  • This file subsequently plays perfectly in mplayer

So I find it unlikely that this is a signal issue, or at least, one that matters insofar as getting a good picture.

In addition, these devices worked just fine with older builds of MythTV ; I think the signal monitoring code is responsible for their non-functioning.

I will grab those logs though.

comment:14 Changed 9 years ago by danielk

  • Owner changed from ijr to danielk
  • Status changed from reopened to new

comment:15 Changed 9 years ago by daniel.danner@…

Although no explicit fix was submitted recently, I tried r7299 after there were so much changes made to the dvb parts.

Anyway...bad news: Nothing changed. :/

PS: If you need a new trace, tell me so.

Changed 9 years ago by adrian.wilkins@…

mythbackend logs from a system with three DVB-T tuners

comment:16 Changed 9 years ago by adrian.wilkins@…

Ok, the attached archive of logs is from my MythTV system.

Each log is the output of mythbackend --verbose record,channel,siparser, from build 7308. In each case, the card being tested was the only one configured. The test in each case was ;

  1. Start mythbackend.
  2. Select "Watch TV" from mythfrontend.
  3. Exit (after the picture shows, or after it obvious it isn't coming).

Configure output is included.

Also included are the tzap outputs from each tuner device for the UK channel "ITV1" from the uk-WinterHill? transmitter, as I feel these show up some anomalies that may help debug things.

  • dvb0 is a Hauppauge WinTV Nova-T PCI. This card works properly.
  • dvb1 is a Hauppauge WinTV Nova-T USB2. When watching LiveTV
    • The OSD shows "Signal 100% (l) No Lock"
    • No picture
    • Log shows dummy recorder is being used to provide blackscreen
  • dvb2 is a Hauppauge DEC2000-T (USB 1.1).
    • The OSD shows "Signal % (L) Partial Lock"
    • No picture
    • Log shows dummy recorder being used to provide blackscreen

All three cards work fine as command-line recorders (as defined above in this thread). Both USB tuners have been tried both with (as worked before) and without the "Use Hardware Decoder" setting checked. All three devices, as noted previously, worked just fine with MythTV.

I hope there is something helpful in there. The only lead I can suggest is that the tzap output looks a bit weird, (e.g. reporting 0% signal strength from a card that is tuned and streaming mpeg to disk at the time).

comment:17 Changed 9 years ago by malc@…

Hi,

I have
dvb1 is a Hauppauge WinTV Nova-T PCI.
dvb0 is a Hauppauge WinTV Nova-T USB2.

I'm on the WinterHill? transmitter

I have to up the timeouts on dvb0 to get it to lock, dvb1 works fine.

I have 30000 and 10000 for the DVB card (i.e. 30secs... sometimes it can take 25-30s to lock... other times it takes 5s.... don't ask me why).

You can prove it by using dvb-scan .. you have to use the "-5" option to increase the timeouts

i.e.

scan -5 -a 0 Uk-WinterHill?

to get a full scan, otherwise it will only get the first multiplex

comment:18 Changed 9 years ago by adrian.wilkins@…

malc, could you tell me which kernel version you are running?

The DVB driver architecture has undergone a bit of a revolution recently.

BTW, I tried 30000, 30000 for timeout values and no joy.

On the premise that the signal monitoring patch caused all my pain, I did patch SignalMonitor?.cpp to return "false" for IsSupported?() every time, and got a different set of errors ; "PMT NOT SET".

comment:19 Changed 9 years ago by malc@…

Hi,

I'm using a 2.6.9 kernel (Fedora derivative).

Interestingly the PCI card works fine 100% of the time, the USB card struggles sometimes. Seems to be about 50% of the time. Not associated with the presence of the second card, purely associated with the presence of the USB based tuner. (USB 2 Nova-T - DiBcom? tuner - Hauppauge branded). It worked fine with 0.18, with extended timeouts in the hardcoded values. The failures are purely random, 3 recordings of different episodes on the same channel resulted in only the second one working.

In addition this is purely associated with changes post 7266 (which I did 'cos I wanted to get both cards working in a single machine.. and I know there were problems with 2 DVB tuners).

Two thoughts

First this is a race condition - the timeout occurs after 20, 30 or even 60 secs but no tuning / channel selection occurs. Recording is cancelled.

Second the signal timeout I get lines like this, with "timeout (0 ms)" in them.

SML[2]: Name(seen_pat) Val(0) thr(>=1) range(0,1) timeout(0 ms) is set. Is NOT good.

Daniel, I know the core timeouts come from the DB and that the signal timeout should be less than the channel... but there also seems to be code that looks for device timeouts from a strucuture of device info... what's happening here? Is it possible not all devices / drivers are providing correct timeouts?

-malc-

comment:20 Changed 9 years ago by adrian.wilkins@…

I'm (now) using a rather recent -mm kernel, but my kernel upgrades of late have been in hope of fixing this issue ; I've previously had all three tuners working pretty reliably (oh why did I change Myth versions ;-) ).

I think your 2.6.9 kernel must have been patched, because I'm fairly sure that I had to upgrade my kernel from one newer than that in order to support my Nova-t USB2 (we have pretty much the same tuners, but I have a DEC2000-t as well).

If tzap reads it's output regarding signal parameters from the drivers, than this has always looked like a driver issue to me ;

using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0'
reading channels from file '/root/.tzap/channels.conf'
tuning to 834166670 Hz
video pid 0x0b86, audio pid 0x0b23
status 1b | signal 612f | snr 0000 | ber 001fffff | unc 0000ffff | FE_HAS_LOCK
status 1f | signal 6135 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr ffff | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr ffff | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr ffff | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr ffff | ber 00000000 | unc 00000000 | FE_HAS_LOCK

The channel chosen should have forced tuning to a different multiplex. If tzap is reading parameters from the driver, and the signal monitor is reading the same things, then while the ber (bit error rate) and unc (incorrected blocks) values are good, along with the snr (signal-noise ratio), the signal is reported as zero, which I'd regard as a bad sign if it weren't for the card being capable of recording perfectly at the command line in this condition. In addition, the first two lines of output usually represent the tuning pause ; on both my other cards, these two lines lack the FE_HAS_LOCK flag. The snr value would appear to agree with this ; it looks like the driver is misreporting the signal paramters.

You can see tzap output from all three of my cards in the archive attached to this thread. Only the dvb0, or the PCI card, has an output that I would consider consistent and sensible (and even that is not 100% right, because the signal value appears fixed even when tuning). dvb1 reports lock to tzap, but the log says that Myth does not see it (same bat-time, same bat-channel). And for dvb2, Myth reports that it cannot measure several signal parameters ; I'm not sure what tzap does if a driver genuinely does not report these values, but the output appears to show it as present. dvb2 then fails over PAT and PMT. This is also what dvb1 does when disabling signal monitoring by patching SignalMontitor::IsSupported?() to return false.

So point one is that the signal monitoring code is probably preventing dvb1 from working because it's falsely reporting bad values (either through bugs in driver or sigmon code). Alas, patching sigmon off does not fix dvb1 ; it then starts reporting PMT failures.

Perhaps the output from these USB devices isn't supporting PAT and PMT? Isn't it the case that it isn't even a full TS? I mean, for USB 1.1, a full TS is never going to cross the bus in a timely manner ; it's a struggle sometimes to get a single PS across it (esp. on high-bandwidth shows). Do the drivers even support TS, and if they do, are they retro-constructing a "poor mans" TS with no PAT/PMT?

To test this assumption later, I'll patch SignalMonitoring? off again, and then set dvb1 up with TS recording off - TS on has become the default (from the previous default of PS) and the option to configure it has been removed from the GUI. Anyone in the know could tell us whether this setting still actually has an effect :-)

comment:21 Changed 9 years ago by anonymous

Perhaps the output from these USB devices isn't supporting PAT and PMT? Isn't it the case that it isn't even a full TS? I mean, for USB 1.1, a full TS is never going to cross the bus in a timely manner ; it's a struggle sometimes to get a single PS across it (esp. on high-bandwidth shows). Do the drivers even support TS, and if they do, are they retro-constructing a "poor mans" TS with no PAT/PMT?


I think this may be the problem... and will be common to any USB based approach. You've jogged my memory.

From memory (check the linuxtv drivers board for more details), the drivers instruct the device to provide specific PIDS, and they construct the TS like stream. I'm not at home for the next few days, however I do remember the author of the drivers describing something like that.... yes it's a added to kernel (as in I downloaded the source and drivers and compiled a module to support USB, I think it went in in .11 or .12).

Also I think tuning is quick, but channel selection slow (would fit with your idead of reconstructing TS's).

Why it is unreliable rather than failing completely is beyond me... timing/race conditions, or timeouts seem the most likely.

-malc-

comment:22 Changed 9 years ago by adrian

Mine just fails every time.

Tested my hypothesis above ; alas, it seems that either PS recording is no longer supported, or requires PMT to be present, because I get PMT not set errors if I patch sigmon off and then set the card to dvb_tsrecord = 0

I might think about starting a thread on the DVB drivers list to discuss this, or maybe just direct them here :-)

comment:23 Changed 9 years ago by danielk

  • Resolution set to invalid
  • Status changed from new to closed

I'm closing this ticket because the tuning code has been changed completely.

But the USB recorder not inserting a PAT and PMT will still cause problems,
but this needs to be fixed in the USB recorder's drivers.

Please do not reopen this ticket.

If the your problem persists and is not a driver problem, please post to the dev list this week. If the problem persists after that create a new ticket.

comment:24 Changed 7 years ago by anonymous

I still have simular problems with the latest version and the PCI-NOVA-S card

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.