Project

General

Profile

Bug #825

DVB device initialization

Added by Jan Van Belle almost 13 years ago. Updated almost 8 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Hein Rigolo
Category:
DVB
Target version:
2.13
Start date:
2011-12-28
Due date:
% Done:

0%

Estimated time:
Found in version:
2.13
Affected Versions:

Description

Hello,

There's something wrong with the initialization of my Philips TDA10046H DVB-T device.
When trying it with VDR, I have a decent signal quality (60%).
The same is visible with the 'femon -H -ax' command (x = my adapter no.)

However, when I try it with tvheadend (head, git repo), I get no signal, Bursty FEC, Constant FEC and most important of all: no services are detected in the muxes configured.
Strange thing : the same is visible with the 'femon -H -ax' command.
So there must be something different in the device initialization.

Could it be an issue with the 'dual aspect' (DVB-T + analog tv) ?
When using an USB-stick tuner, there is no problem (except that it changes its adapter number ;-) )

Kind regards,

Jan

History

#1

Updated by Hein Rigolo almost 13 years ago

And you run vdr on the same machine/hardware as tvheadend?

#2

Updated by Jan Van Belle almost 13 years ago

Yes, of course. Otherwise it could just be a misconfiguration...

My setup is a gentoo-linux system, kernel 3.0.7 (for the moment, but same behaviour with 2.6.3x when I tried it the first time).
VDR version is currently 1.7.21

I already tried to compare the initialization sequence but I don't see that much difference.
I didn't search for hardware specific initialization sequences.

The DVB-T card mentioned above is based on the saa7134 chipset.
Below is a list of modules the card uses.
If you have an idea, I could try it myself (as I have the hardware ;-) )

Kind regards,

Jan

pvrGentoo ~ # lsmod | grep saa7134 -
saa7134_alsa 7984 0
saa7134_dvb 10652 10
tda10086 6452 1 saa7134_dvb
dvb_pll 7604 1 saa7134_dvb
videobuf_dvb 3508 1 saa7134_dvb
tda10048 8280 1 saa7134_dvb
tda1004x 11412 1 saa7134_dvb
tda8290 10472 2 saa7134_dvb,tuner
tda18271 42836 3 saa7134_dvb,tuner,tda8290
tda827x 7460 2 saa7134_dvb,tda8290
saa7134 140448 2 saa7134_alsa,saa7134_dvb
videobuf_dma_sg 5588 3 saa7134_alsa,saa7134_dvb,saa7134
videobuf_core 11476 3 videobuf_dvb,saa7134,videobuf_dma_sg
v4l2_common 3648 2 tuner,saa7134
videodev 57568 3 tuner,saa7134,v4l2_common
rc_core 10616 7 rc_asus_pc39,saa7134,rc_imon_pad,ir_lirc_codec,imon
tveeprom 12548 1 saa7134
snd_pcm 46296 6 saa7134_alsa,snd_pcm_oss,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd 39232 17 saa7134_alsa,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer

#3

Updated by Ole Sandum almost 13 years ago

I believe I'm seeing the exact this behaviour as well on an ASUS My Cinema P7131 Dual.

[root@streamboy ~]# lspci -vnn
01:0a.0 Multimedia controller [0480]: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d0)
    Subsystem: ASUSTeK Computer Inc. P7131 Dual [1043:4862]
    Flags: bus master, medium devsel, latency 84, IRQ 18
    Memory at fd0fe000 (32-bit, non-prefetchable) [size=2K]
    Capabilities: [40] Power Management version 2
    Kernel driver in use: saa7134
    Kernel modules: saa7134

Using tzap or getstream it will reliably lock on to the desired mux:

[streamer@streamboy ~]$ femon -H
FE: Philips TDA10046H DVB-T (DVBT)
(( idling here: ))
status   V   | signal  50% | snr  49% | ber 91880 | unc 0 | 
status   V   | signal  50% | snr  49% | ber 91880 | unc 0 | 
status   V   | signal  50% | snr  49% | ber 91880 | unc 0 | 
status   V   | signal  50% | snr  49% | ber 91880 | unc 0 | 
(( starting tzap here: ))
status       | signal   0% | snr  99% | ber 131070 | unc 0 | 
status S V   | signal  68% | snr  79% | ber 2218 | unc 77 | 
status SCVYL | signal  68% | snr  99% | ber 2080 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  68% | snr  99% | ber 3192 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  68% | snr  99% | ber 1742 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  68% | snr  99% | ber 2898 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  68% | snr  99% | ber 2050 | unc 0 | FE_HAS_LOCK
...

However, tvheadend will never get a lock:

...
status   V   | signal  50% | snr  49% | ber 65178 | unc 0 | 
status   V   | signal  50% | snr  49% | ber 65178 | unc 0 | 
status   V   | signal  50% | snr  49% | ber 65178 | unc 0 | 
status   V   | signal  50% | snr  49% | ber 65178 | unc 0 | 
(( starting tvheadend here: ))
status       | signal   0% | snr  99% | ber 131070 | unc 0 | 
status S V   | signal   0% | snr  76% | ber 54400 | unc -1 | 
status       | signal   0% | snr  71% | ber 131070 | unc 0 | 
status       | signal   0% | snr  68% | ber 131070 | unc 0 | 
status       | signal   0% | snr  69% | ber 131070 | unc 0 | 
status SCVYL | signal   0% | snr  58% | ber 131070 | unc -1 | FE_HAS_LOCK
status SCVYL | signal   0% | snr  58% | ber 131070 | unc -1 | FE_HAS_LOCK
status       | signal   0% | snr  85% | ber 131070 | unc 0 | 
status S     | signal   0% | snr  47% | ber 131070 | unc -1 | 
status SCVYL | signal   0% | snr  63% | ber 131070 | unc -1 | FE_HAS_LOCK
status SCVYL | signal   0% | snr  65% | ber 131070 | unc -1 | FE_HAS_LOCK
status S     | signal   0% | snr   0% | ber 131070 | unc -1 | 
status S     | signal   0% | snr  51% | ber 131070 | unc -1 | 
status SCVYL | signal   0% | snr  62% | ber 131070 | unc -1 | FE_HAS_LOCK
status SCVYL | signal   0% | snr  64% | ber 131070 | unc -1 | FE_HAS_LOCK
status       | signal   0% | snr  78% | ber 131070 | unc 0 | 
status SCVYL | signal   0% | snr  61% | ber 131070 | unc -1 | FE_HAS_LOCK
status SCVYL | signal   0% | snr  62% | ber 131070 | unc -1 | FE_HAS_LOCK
status       | signal   0% | snr  29% | ber 131070 | unc 0 | 
status       | signal   0% | snr  74% | ber 131070 | unc 0 | 
status SCVYL | signal   0% | snr  63% | ber 131070 | unc -1 | FE_HAS_LOCK
status SCVYL | signal   0% | snr  63% | ber 131070 | unc -1 | FE_HAS_LOCK
status S     | signal   0% | snr   2% | ber 131070 | unc 0 | 
status SCVYL | signal   0% | snr  62% | ber 131070 | unc -1 | FE_HAS_LOCK
status SCVYL | signal   0% | snr  67% | ber 131070 | unc -1 | FE_HAS_LOCK
status       | signal   0% | snr  71% | ber 131070 | unc 0 | 
status SCVYL | signal   0% | snr  65% | ber 131070 | unc -1 | FE_HAS_LOCK
status SCVYL | signal   0% | snr  66% | ber 131070 | unc 81 | FE_HAS_LOCK

tvheadend -d shows this:

[streamer@streamboy ~]$ tvheadend -d
[INFO]:dvb: Found adapter /dev/dvb/adapter0 (Philips TDA10046H DVB-T) via PCI
[DEBUG]:dvb: "/dev/dvb/adapter0" tuning to "730,000 kHz" (Initial autoscan)
[INFO]:v4l: /dev/video0: saa7134 ASUSTeK P7131 Dual PCI:0000:01:0a.0 capabilities: 0x05010015
[INFO]:v4l: /dev/video0: Standard #0: 000000000000b000 NTSC, frameperiod: 1001/30000, 525 lines
[INFO]:v4l: /dev/video0: Standard #1: 0000000000001000 NTSC-M, frameperiod: 1001/30000, 525 lines
[INFO]:v4l: /dev/video0: Standard #2: 0000000000002000 NTSC-M-JP, frameperiod: 1001/30000, 525 lines
[INFO]:v4l: /dev/video0: Standard #3: 0000000000008000 NTSC-M-KR, frameperiod: 1001/30000, 525 lines
[INFO]:v4l: /dev/video0: Standard #4: 00000000000000ff PAL, frameperiod: 1/25, 625 lines
[INFO]:v4l: /dev/video0: Standard #5: 0000000000000007 PAL-BG, frameperiod: 1/25, 625 lines
[INFO]:v4l: /dev/video0: Standard #6: 0000000000000008 PAL-H, frameperiod: 1/25, 625 lines
[INFO]:v4l: /dev/video0: Standard #7: 0000000000000010 PAL-I, frameperiod: 1/25, 625 lines
[INFO]:v4l: /dev/video0: Standard #8: 00000000000000e0 PAL-DK, frameperiod: 1/25, 625 lines
[INFO]:v4l: /dev/video0: Standard #9: 0000000000000100 PAL-M, frameperiod: 1001/30000, 525 lines
[INFO]:v4l: /dev/video0: Standard #10: 0000000000000200 PAL-N, frameperiod: 1/25, 625 lines
[INFO]:v4l: /dev/video0: Standard #11: 0000000000000400 PAL-Nc, frameperiod: 1/25, 625 lines
[INFO]:v4l: /dev/video0: Standard #12: 0000000000000800 PAL-60, frameperiod: 1001/30000, 525 lines
[INFO]:v4l: /dev/video0: Standard #13: 0000000000ff0000 SECAM, frameperiod: 1/25, 625 lines
[INFO]:v4l: /dev/video0: Standard #14: 0000000000010000 SECAM-B, frameperiod: 1/25, 625 lines
[INFO]:v4l: /dev/video0: Standard #15: 0000000000040000 SECAM-G, frameperiod: 1/25, 625 lines
[INFO]:v4l: /dev/video0: Standard #16: 0000000000080000 SECAM-H, frameperiod: 1/25, 625 lines
[INFO]:v4l: /dev/video0: Standard #17: 0000000000320000 SECAM-DK, frameperiod: 1/25, 625 lines
[INFO]:v4l: /dev/video0: Standard #18: 0000000000400000 SECAM-L, frameperiod: 1/25, 625 lines
[INFO]:v4l: /dev/video0: Standard #19: 0000000000800000 SECAM-Lc, frameperiod: 1/25, 625 lines
[INFO]:v4l: /dev/video0: Input #0: Television (Tuner), audio:0x1, tuner:0, standard:0000000000ffbfff, 
[INFO]:v4l: /dev/video0: Input #1: Composite1 (Camera), audio:0x1, tuner:0, standard:0000000000ffbfff, 
[INFO]:v4l: /dev/video0: Input #2: Composite2 (Camera), audio:0x1, tuner:0, standard:0000000000ffbfff, 
[INFO]:v4l: /dev/video0: Input #3: S-Video (Camera), audio:0x1, tuner:0, standard:0000000000ffbfff, 
[INFO]:v4l: /dev/video0: Format #0: 8 bpp gray [GREY] 
[INFO]:v4l: /dev/video0: Format #1: 15 bpp RGB, le [RGBO] 
[INFO]:v4l: /dev/video0: Format #2: 15 bpp RGB, be [RGBQ] 
[INFO]:v4l: /dev/video0: Format #3: 16 bpp RGB, le [RGBP] 
[INFO]:v4l: /dev/video0: Format #4: 16 bpp RGB, be [RGBR] 
[INFO]:v4l: /dev/video0: Format #5: 24 bpp RGB, le [BGR3] 
[INFO]:v4l: /dev/video0: Format #6: 24 bpp RGB, be [RGB3] 
[INFO]:v4l: /dev/video0: Format #7: 32 bpp RGB, le [BGR4] 
[INFO]:v4l: /dev/video0: Format #8: 32 bpp RGB, be [RGB4] 
[INFO]:v4l: /dev/video0: Format #9: 4:2:2 packed, YUYV [YUYV] 
[INFO]:v4l: /dev/video0: Format #10: 4:2:2 packed, UYVY [UYVY] 
[INFO]:v4l: /dev/video0: Format #11: 4:2:2 planar, Y-Cb-Cr [422P] 
[INFO]:v4l: /dev/video0: Format #12: 4:2:0 planar, Y-Cb-Cr [YU12] 
[INFO]:v4l: /dev/video0: Format #13: 4:2:0 planar, Y-Cb-Cr [YV12] 
[WARNING]:v4l: /dev/video0: Device lacks MPEG encoder, device skipped
[INFO]:dvr: Creating new configuration ''
[WARNING]:dvr: Output directory for video recording is not yet configured for DVR configuration "". Defaulting to to "/home/streamer". This can be changed from the web user interface.
[INFO]:CSA: Using SSE2 128bit parallel descrambling
[NOTICE]:START: HTS Tvheadend version git-7910c50 started, running as PID:3779 UID:501 GID:501, settings located in '/home/streamer/.hts/tvheadend'
[DEBUG]:AVAHI: Adding service 'Tvheadend'
[INFO]:AVAHI: Service 'Tvheadend' successfully established.
[DEBUG]:dvb: Philips TDA10046H DVB-T: FE_READ_UNCORRECTED_BLOCKS returns delta updates (delta=-1)
[DEBUG]:dvb: "730,000 kHz" on adapter "Philips TDA10046H DVB-T", status changed to Bursty FEC
[DEBUG]:dvb: "730,000 kHz" on adapter "Philips TDA10046H DVB-T", status changed to Constant FEC
[DEBUG]:dvb: "730,000 kHz" on adapter "Philips TDA10046H DVB-T", status changed to Faint signal
[DEBUG]:dvb: "730,000 kHz" on adapter "Philips TDA10046H DVB-T", status changed to Constant FEC
[DEBUG]:dvb: "730,000 kHz" on adapter "Philips TDA10046H DVB-T", status changed to Faint signal
[DEBUG]:dvb: "730,000 kHz" on adapter "Philips TDA10046H DVB-T", status changed to Constant FEC
[DEBUG]:dvb: "730,000 kHz" on adapter "Philips TDA10046H DVB-T", status changed to No signal
[DEBUG]:dvb: "730,000 kHz" on adapter "Philips TDA10046H DVB-T", status changed to Constant FEC
[DEBUG]:dvb: "730,000 kHz" on adapter "Philips TDA10046H DVB-T", status changed to No signal
[DEBUG]:dvb: "730,000 kHz" on adapter "Philips TDA10046H DVB-T", status changed to Constant FEC
[DEBUG]:dvb: "730,000 kHz" on adapter "Philips TDA10046H DVB-T", status changed to Faint signal
[DEBUG]:dvb: "730,000 kHz" on adapter "Philips TDA10046H DVB-T", status changed to Constant FEC
[DEBUG]:dvb: "730,000 kHz" on adapter "Philips TDA10046H DVB-T", status changed to No signal
[DEBUG]:dvb: "730,000 kHz" on adapter "Philips TDA10046H DVB-T", status changed to Constant FEC
[DEBUG]:dvb: "730,000 kHz" on adapter "Philips TDA10046H DVB-T", status changed to Faint signal
[DEBUG]:dvb: "730,000 kHz" on adapter "Philips TDA10046H DVB-T", status changed to Constant FEC
[DEBUG]:dvb: "730,000 kHz" on adapter "Philips TDA10046H DVB-T", status changed to Bad signal
^C[DEBUG]:EPG: Stored EPG data for 0 events on disk
[NOTICE]:STOP: Exiting HTS Tvheadend
#4

Updated by Jan Van Belle almost 13 years ago

that's exactly the card I have.
But I thought it would be more chipset-dependant and not only this card...

Jan

#5

Updated by Axel Gembe almost 13 years ago

I have a very similar problem with a Twinhan 1041 DVB-S2 card. When I use szap to tune a channel, I have very stable signal and most of the time BER is zero. When I use tvheadend to tune to the same channel and use femon to watch, the signal is very unstable, and I often have high BER and tvheadend complains about continuity counter errors. Other software is able to use it just fine. I am using revision fdf89b2768f131f16e3539757cb1cdd2e7ae5199 using the gentoo live ebuild.

#6

Updated by Axel Gembe almost 13 years ago

Ok, I got this fixed. I found out that when using szap it only tunes with a stepsize of 1MHz, whereas tvheadend uses steps inbetween. Strangely the stb0899 driver seems to reports a step size of 0 (which doesn't make any sense, should be at least 1). I modded the driver to use a 1KHz stepsize and now the problem is gone, totally stable signal strength.

Sadly I still get continuity errors with tvheadend. Strangely I cannot reproduce the same errors when using dvbsnoop, but that is another problem and I will open a ticket for it as soon as I have diagnosed it some more.

#7

Updated by Jan Van Belle almost 13 years ago

Did you change it in tvheadend or the linux driver itself?
Otherwise I'd have a look myself!

#8

Updated by Axel Gembe almost 13 years ago

I changed it in the driver itself. I have the patches in the mantis branch at git://deve.loping.net/linux.git

The change is in drivers/media/dvb/frontends/stb0899_drv.c, just change .frequency_stepsize from 0 to 1000.

Sadly the better signal strength had no effect at all for me, but that is because of the crappy mantis DMA mechanism. I've since changed to a Mystique Satix S2 Sky, which works very nice.

- Axel
#9

Updated by Trab Terual over 12 years ago

I had the same problems, and then I switched the antenna cable to the other connector and now everything works. Strange... The v4l wiki gave me the idea. It said that in Windows the ports could be switched between analog reception and DVB-T.

#10

Updated by Trab Terual over 12 years ago

Maybe superfluous, but the last message is about the ASUS P7131 Hybrid.

#11

Updated by Adam Sutton over 12 years ago

  • Status changed from New to Rejected

Guys, I've no idea if this is still a problem but its been 5 months since it was updated. If its still a problem please re-submit.

#12

Updated by Jan Van Belle about 12 years ago

I did a rebuild with the latest sources a few days ago.
It's working now!

Thanks,

Jan
#13

Updated by Dimitris k about 8 years ago

I also have Asus P7131 Hybrid. Tvheadend reports the tuner as Phillips tda10046h

$ lspci -vv
04:00.0 Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1)
Subsystem: ASUSTeK Computer Inc. My Cinema-P7131 Hybrid
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (21000ns min, 8000ns max)
Interrupt: pin A routed to IRQ 19
Region 0: Memory at f7c00000 (32-bit, non-prefetchable) [size=2K]
Capabilities: <access denied>
Kernel driver in use: saa7134
Kernel modules: saa7134

Every time I boot up, tvheadend works only on a specific frequency (DVB-T).
If I switch to another frequency, tvheadend tries to tune but it fails. No video as well.
The only solution I have found is to restart the tvheadend service (archlinux).
I've been using tvheadend for over 5 years now or more, and always I had to restart the service in order to be able to tune to all frequencies.

How can I provide more information?
I'm running git version of tvheadend, compiled a few days ago. HTS Tvheadend 4.1-2249~g747ed01

#14

Updated by Dimitris k almost 8 years ago

Well, it seems that tvheadend is starting before the firmware is loaded.
So delaying the launch of tvheadend service fixed my problem

Also available in: Atom PDF