Opened 19 years ago
Closed 18 years ago
Last modified 17 years ago
#343 closed defect (invalid)
'Signal 100% (l ) no lock' and no video with DVB-S and DVB-T
Reported by: | 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)
Change History (25)
comment:1 Changed 19 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 Changed 19 years ago by
Resolution: | invalid |
---|---|
Status: | closed → 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 19 years ago by
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
Did you read the commit log for 7226?
comment:4 Changed 19 years ago by
(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 19 years ago by
Milestone: | → 0.19 |
---|---|
Resolution: | invalid |
Status: | closed → 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 19 years ago by
Milestone: | 0.19 |
---|
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 19 years ago by
Milestone: | → 0.19 |
---|
Huh, milestone deleted? This didn't happened with intention...sorry.
comment:8 Changed 19 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:9 Changed 19 years ago by
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 19 years ago by
Resolution: | fixed |
---|---|
Severity: | medium → high |
Status: | closed → reopened |
Summary: | 'Signal Lock' and no video with dvb-s, problems still remaining in rev 7266 → '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 19 years ago by
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 19 years ago by
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 19 years ago by
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 18 years ago by
Owner: | changed from Isaac Richards to danielk |
---|---|
Status: | reopened → new |
comment:15 Changed 18 years ago by
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 18 years ago by
Attachment: | mythlogs.zip added |
---|
mythbackend logs from a system with three DVB-T tuners
comment:16 Changed 18 years ago by
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 ;
- Start mythbackend.
- Select "Watch TV" from mythfrontend.
- 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 18 years ago by
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 18 years ago by
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 18 years ago by
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 18 years ago by
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 18 years ago by
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 18 years ago by
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 18 years ago by
Resolution: | → invalid |
---|---|
Status: | new → 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 17 years ago by
I still have simular problems with the latest version and the PCI-NOVA-S card
user error, you need a channel lock before you see any video