[linux-dvb] Mythtv with NEXUS-S only
I was wondering is it possible to have Mythtv running with NEXUS-S FF card only, using it for capture _and_ tv-out MythTV site seems to be centered around PVR-card. -- [EMAIL PROTECTED] * Using HTML-mail is like breaking wind in a church * 60.2N 24.7E * it is not illegal, just extremely bad manners * ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mythtv with NEXUS-S only
On Sat, 26 Aug 2006 13:37:35 +0300 Lauri Tischler [EMAIL PROTECTED] wrote: I was wondering is it possible to have Mythtv running with NEXUS-S FF card only, using it for capture _and_ tv-out MythTV site seems to be centered around PVR-card. I don't believe so - that's what VDR is for. Myth grew up on analogue reception and playing DivX / NuppelVideo, etc. - the DVB support is only a more recent addition, but playback still runs through the Myth core relying on either software decode or the PVR250/350 cards, etc. A FF card doesn't have the features Myth needs (i.e. being a full 24-bit framebuffer). Cheers, Gavin. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mythtv with NEXUS-S only
Gavin Hamill wrote: On Sat, 26 Aug 2006 13:37:35 +0300 Lauri Tischler [EMAIL PROTECTED] wrote: I was wondering is it possible to have Mythtv running with NEXUS-S FF card only, using it for capture _and_ tv-out MythTV site seems to be centered around PVR-card. I don't believe so - that's what VDR is for. Myth grew up on analogue reception and playing DivX / NuppelVideo, etc. - the DVB support is only a more recent addition, but playback still runs through the Myth core relying on either software decode or the PVR250/350 cards, etc. A FF card doesn't have the features Myth needs (i.e. being a full 24-bit framebuffer). Older versions of mythtv did have a check box to enable FF hardware acceleration. This option was removed in recent cvs versions, but I dont know why. BR. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] SAA7146 (KNC ONE DVB-C): ber,str values reliable?
Thomas Börkel wrote:
HI!
thomas schorpp wrote:
Whatever I do (different cables, changing amplification, switching
channels), czap always reports a ber of 195000.
status SCVYL | signal 8b8b | snr f3f3 | ber 001e | unc |
FE_HAS_LOCK
status SCVYL | signal 8b8b | snr f2f2 | ber 001e | unc |
FE_HAS_LOCK
its static here too on every channel.
In the meantime, using Google, I found one other owner, that also has
exactly 195000. This seems pretty unlikely to me, if the ber value is
computed right.
At the moment, one card has constantly 195000 and the other 101d0. I
guess, when I reboot, it's back to 195000 (like it was once, when one
card had a ber of 10.
BTW, czap and femon show different values, if I use femon without a
tuning app (like czap) running parallel, is this normal?
$ czap das vierte -c channels.conf
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
151 DAS
VIERTE:76200:INVERSION_AUTO:690:FEC_NONE:QAM_64:2047:2048:1793
151 DAS VIERTE: f 76200, s 690, i 2, fec 0, qam 3, v 0x7ff, a 0x800
status 1f | signal 8484 | snr f4f4 | ber 00195000 | unc |
FE_HAS_LOCK
status 1f | signal 8484 | snr f3f3 | ber 00195000 | unc |
FE_HAS_LOCK
*CTRL-C*
$ femon
using '/dev/dvb/adapter0/frontend0'
FE: Philips TDA10021 DVB-C (CABLE)
status 1f | signal | snr | ber 00969696 | unc 000f |
FE_HAS_LOCK
status 1f | signal | snr | ber 00969696 | unc 000f |
FE_HAS_LOCK
ber from device and driver is ok, use dvbsnoop -s signal.
bug is from misadaption/accesssyncprobs in femon+czap:
tom1:/usr/src/linux# dvbsnoop
dvbsnoop - a dvb/mpeg2 stream analyzer tool
Version: 1.4.00/api-3 (Sep 25 2005 20:42:27)
http://dvbsnoop.sourceforge.net/
(c) 2001-2005 Rainer Scherg (rasc)
Aug 26 08:59:54 tom1 kernel: tda10021: Verbose Status:
Aug 26 08:59:54 tom1 kernel: tda10021: VAFC -1
Aug 26 08:59:54 tom1 kernel: tda10021: VAGC 0x7f
Aug 26 08:59:54 tom1 kernel: tda10021: AGCCONF 0x23
Aug 26 08:59:54 tom1 kernel: tda10021: AGCREF 0x5c
Aug 26 08:59:54 tom1 kernel: tda10021: PWMREF 0x48
Aug 26 08:59:54 tom1 kernel: tda10021: MSE 0x0c
Aug 26 08:59:54 tom1 kernel: tda10021: BER-RANGE 0 (inverted output 0...3
from sync register ber bits )
Aug 26 08:59:54 tom1 kernel: tda10021: SATNYQ 0x00
Aug 26 08:59:54 tom1 kernel: tda10021: SATADC 0x00
Aug 26 08:59:54 tom1 kernel: tda10021: HALFADC 0xb2
Aug 26 08:59:54 tom1 kernel: tda10021: SATDEC1 0x00
Aug 26 08:59:54 tom1 kernel: tda10021: SATDEC2 0x00
Aug 26 08:59:54 tom1 kernel: tda10021: SATDEC3 0x00
Aug 26 08:59:54 tom1 kernel: tda10021: CLKOFFSET 0x1c
Aug 26 08:59:54 tom1 kernel: tda10021: SATAAF 0x00
Aug 26 08:59:54 tom1 kernel: tda10021: EQCONF1 0x77
Aug 26 08:59:54 tom1 kernel: tda10021: EQSTEP 0x1a
Aug 26 08:59:54 tom1 kernel: tda10021: PLL 0x00
cycle: 95 d_time: 0.036 s Sig: 32639 SNR: 62708 BER: 1620 UBLK: 0 Stat:
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 96 d_time: 0.036 s Sig: 32639 SNR: 62708 BER: 1620 UBLK: 0 Stat:
0x1f [SIG CARR VIT SYNC LOCK ]
(256qam channel)
cycle: 265 d_time: 0.035 s Sig: 35723 SNR: 62451 BER: 20 UBLK: 0 Stat:
0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 266 d_time: 0.036 s Sig: 35723 SNR: 62451 BER: 20 UBLK: 0 Stat:
0x1f [SIG CARR VIT SYNC LOCK ]
(64qam)
1. czap (ctrl-z)
2. dvbsnoop
3. femon
4. fg
you may want to reportbug femon and czap, i see no driver issue in tda10021.c
what not seems to be reliable is Sig, cause 256qam channels come with +6db from our network
so VAGC must be inverse proportional to signalstrengh, not proportional, philips tuners respond to
rising VAGC (tuner loop) with rising gain, too.
so a reliable signal reading should be calculated from the tuner AGC loop, which is in detail unknown
to me.
you cant just use *strength = (gain 8) | gain;
cause AGC gain is usually -40dB...0dB/0...3.3(5)VAGC on philips tuners.
logarithmic dB calculation with VAGC,AGCREF or like should be done,
but not easy in a driver and without circuit knowlegde and in a universal driver and
tvapps dont need it.
but you should honor the proportionality with
static int tda10021_read_signal_strength(struct dvb_frontend* fe, u16* strength)
{
struct tda10021_state* state = fe-demodulator_priv;
u8 igain = ~tda10021_readreg(state, 0x17);
*strength = (igain 8) | igain;
return 0;
}
at least.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] VP7045 tuner doesn't work
I have just purchased a DigitalNow TwinDVB-T device, i.e. 2 x VP7045 DVB-T USB tuners. Although they both function correctly under Windows, I have found under Linux (2.6.15) (and under OS X) that one works and one does not. Both tuners are recognized correctly (and have the same vid=13d3 pid=3206) but one fails to produce any results with scan and tzap. Basically, the behaviour is as if no RF cable is plugged in and so the tuner has no signal. I was led to this mailing list to resolve the system freezes arising from multiple vp7045 tuners -- a problem that was solved in Feb but which evidently has not made it into the Ubuntu repositories. Hence I have since built v4l-dvb and dvb-apps from the latest sources and am now working with those. To cut a long story short, there is no obvious difference between the two tuners until I popped the lid off the 'tin cans'. There I found the working tuner with an MT352 chip and the non-working tuner with...a TDA10046. I can see from the source code that this is not what is expected, so I can understand the failure. I can also see that the TDA10046 is well-known around here, but don't really know what needs to be done to get the tuner working. Can anyone help? Thanks, Chris ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] kernel 2.6.17.xx budget_av || tda1004x stability tuning
Ronald Warsow wrote: hi i noticed some tuning and stability problems with kernels -gt 2.6.16 and my budget-card Terratec Cinergy 1200 DVB-T (frontend Philips TDA10046H). studying the script get_dvb_firmware and following the links i see that the provider of the firmware holds a newer one (version 219g), then mentioned in the script. tia ronald Ronald, I've tried this myself but get the following in the syslog: Aug 26 18:17:12 blackadder tda1004x: found firmware revision 0 -- invalid Aug 26 18:17:12 blackadder tda1004x: waiting for firmware upload (dvb-fe-tda10045.fw)... Aug 26 18:17:13 blackadder tda1004x: firmware upload complete Aug 26 18:17:13 blackadder tda1004x: found firmware revision 0 -- invalid Aug 26 18:17:13 blackadder tda1004x: firmware upload failed How did you get it to work? Cheers, Dave. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Hauppauge DVB-S-CI and Irdeto CAM
I've recently purchased a new CAM
(http://www.scmmicro.com/dvb/dvb_cam.html#Irdeto1.11) as my provider
(Austar here in Australia) changed something and my old CAM stopped
being able to decrypt programmes. The new CAM is also unable to decrypt
and data so I set about putting log statements into the kernel to see
where it was failing (see attached patch and resulting log). My card is
a Hauppage DVB-S-CI:
lspic -v:
08:0d.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: Technotrend Systemtechnik GmbH Technotrend-Budget /
Hauppauge WinTV-NOVA-CI DVB card
Flags: bus master, medium devsel, latency 64, IRQ 193
Memory at ddbffe00 (32-bit, non-prefetchable) [size=512]
uname -a:
Linux blackadder 2.6.17-gentoo-r5 #10 SMP Sat Aug 26 18:48:38 EST 2006
x86_64 Intel(R) Xeon(TM) CPU 3.00GHz GNU/Linux
The lines going wrong are 738-744 in dvb_ca_en50221.c:
/* check if interface is still free */
if ((status = ca-pub-read_cam_control(ca-pub, slot,
CTRLIF_STATUS)) 0)
goto exit;
if (!(status STATUSREG_FR)) {
/* it wasn't free = try again later */
status = -EAGAIN;
goto exit;
}
Upon further checks status is 0 and therefore it always returns -EAGAIN
and exits the loop at the end of the timeout (which I tried increasing
by 4 times). I also tried commenting out this if statement to see what
happened, but it just complained about write errors earlier than it got
before.
I have tried new firmware for my DVB-S card rather than the firmware
specified in the get_dvb_firmware script (coincidently someone else just
posted the list about this) but I couldn't get it to upload it.
Is my CAM just incompatible with my card or is this a bug? If I should
buy a new card, can anyone recommend a good card that will work with
this CAM?
All help gratefully appreciated.
Cheers,
Dave.
--- drivers/media/dvb/dvb-core/dvb_ca_en50221.c 2006-08-26 18:48:02.0
+1000
+++ drivers/media/dvb/dvb-core/dvb_ca_en50221.c.debug 2006-08-26
18:19:19.0 +1000
@@ -718,55 +718,74 @@
// sanity check
- if (bytes_write ca-slot_info[slot].link_buf_size)
+ if (bytes_write ca-slot_info[slot].link_buf_size) {
+ printk(dvb_ca adapter %d: bytes_write (%d) greater than buffer
(%d)\n, ca-dvbdev-adapter-num, bytes_write,
ca-slot_info[slot].link_buf_size);
return -EINVAL;
+ }
/* check if interface is actually waiting for us to read from it, or if
a read is in progress */
- if ((status = ca-pub-read_cam_control(ca-pub, slot, CTRLIF_STATUS))
0)
+ if ((status = ca-pub-read_cam_control(ca-pub, slot, CTRLIF_STATUS))
0) {
+ printk(dvb_ca adapter %d: Could not get CAM status\n,
ca-dvbdev-adapter-num);
goto exitnowrite;
+ }
if (status (STATUSREG_DA | STATUSREG_RE)) {
status = -EAGAIN;
+ printk(dvb_ca adapter %d: CAM is already reading\n,
ca-dvbdev-adapter-num);
goto exitnowrite;
}
/* OK, set HC bit */
if ((status = ca-pub-write_cam_control(ca-pub, slot, CTRLIF_COMMAND,
-IRQEN | CMDREG_HC)) != 0)
+IRQEN | CMDREG_HC)) != 0) {
+ printk(dvb_ca adapter %d: Failed to write HC\n,
ca-dvbdev-adapter-num);
goto exit;
+ }
/* check if interface is still free */
- if ((status = ca-pub-read_cam_control(ca-pub, slot, CTRLIF_STATUS))
0)
+ if ((status = ca-pub-read_cam_control(ca-pub, slot, CTRLIF_STATUS))
0) {
+ printk(dvb_ca adapter %d: Could not get CAM status, check
2\n, ca-dvbdev-adapter-num);
goto exit;
+ }
if (!(status STATUSREG_FR)) {
/* it wasn't free = try again later */
status = -EAGAIN;
+ printk(dvb_ca adapter %d: CAM is already reading, check 2\n,
ca-dvbdev-adapter-num);
goto exit;
}
/* send the amount of data */
- if ((status = ca-pub-write_cam_control(ca-pub, slot,
CTRLIF_SIZE_HIGH, bytes_write 8)) != 0)
+ if ((status = ca-pub-write_cam_control(ca-pub, slot,
CTRLIF_SIZE_HIGH, bytes_write 8)) != 0) {
+ printk(dvb_ca adapter %d: Failed to write data high\n,
ca-dvbdev-adapter-num);
goto exit;
+ }
if ((status = ca-pub-write_cam_control(ca-pub, slot, CTRLIF_SIZE_LOW,
-bytes_write 0xff)) != 0)
+bytes_write 0xff)) != 0) {
+ printk(dvb_ca adapter %d: Failed to write data low\n,
ca-dvbdev-adapter-num);
goto exit;
+ }
/* send the buffer */
for (i = 0; i bytes_write; i++) {
- if ((status = ca-pub-write_cam_control(ca-pub,
Re: [linux-dvb] Mythtv with NEXUS-S only
Gavin Hamill wrote: On Sat, 26 Aug 2006 13:37:35 +0300 Lauri Tischler [EMAIL PROTECTED] wrote: I was wondering is it possible to have Mythtv running with NEXUS-S FF card only, using it for capture _and_ tv-out MythTV site seems to be centered around PVR-card. I don't believe so - that's what VDR is for. Myth grew up on analogue reception and playing DivX / NuppelVideo, etc. - the DVB support is only a more recent addition, but playback still runs through the Myth core relying on either software decode or the PVR250/350 cards, etc. A FF card doesn't have the features Myth needs (i.e. being a full 24-bit framebuffer). A pity, I like the client/server architecture of Myth, thats about the only thing I like about it :) Maybe VDR has similar client/server capability someday. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] kernel 2.6.17.xx budget_av || tda1004x stability tuning
hi dave it's crazy: as i tried it just right now i get the same log entries: see below. this is the complete log: here i test dvb tuning problems with the old kernel (firmware 217g): Aug 26 01:41:56 obelix kernel: Linux version 2.6.16-1.2133_FC5 ([EMAIL PROTECTED]) (gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) #1 Tue Jun 6 00:52:14 EDT 2006 ... Aug 26 01:42:01 obelix kernel: Linux video capture interface: v1.00 Aug 26 01:42:01 obelix kernel: saa7146: register extension 'budget_av'. Aug 26 01:42:01 obelix kernel: ACPI: PCI Interrupt :00:0e.0[A] - GSI 19 (level, low) - IRQ 18 Aug 26 01:42:01 obelix kernel: saa7146: found saa7146 @ mem e0918000 (revision 1, irq 18) (0x153b,0x1157). Aug 26 01:42:01 obelix kernel: DVB: registering new adapter (Terratec Cinergy 1200 DVB-T). Aug 26 01:42:01 obelix kernel: adapter failed MAC signature check Aug 26 01:42:01 obelix kernel: encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff Aug 26 01:42:01 obelix kernel: nvidia: module license 'NVIDIA' taints kernel. Aug 26 01:42:01 obelix kernel: budget-av: ci interface initialised. Aug 26 01:42:01 obelix kernel: KNC1-0: MAC addr = 00:0a:ac:01:e9:72 Aug 26 01:42:01 obelix kernel: DVB: registering frontend 0 (Philips TDA10046H DVB-T)... trying to tune to stations(with no luck): Aug 26 02:07:31 obelix kernel: tda1004x: setting up plls for 53MHz sampling clock Aug 26 02:07:31 obelix kernel: tda1004x: found firmware revision 20 -- ok Aug 26 02:10:12 obelix kernel: tda1004x: setting up plls for 53MHz sampling clock Aug 26 02:10:12 obelix kernel: tda1004x: found firmware revision 20 -- ok Aug 26 02:10:41 obelix kernel: tda1004x: setting up plls for 53MHz sampling clock Aug 26 02:19:22 obelix kernel: tda1004x: found firmware revision 20 -- ok Aug 26 02:21:50 obelix kernel: tda1004x: setting up plls for 53MHz sampling clock Aug 26 02:21:51 obelix kernel: tda1004x: found firmware revision 20 -- ok Aug 26 02:22:36 obelix kernel: tda1004x: setting up plls for 53MHz sampling clock Aug 26 02:22:36 obelix kernel: tda1004x: found firmware revision 20 -- ok ... hence i tried the new firmware (219g) (i definitivly know the time, cause i saved the firmware in a another directory also. [- ls -l: -rw-r--r-- 1 root root24478 Aug 26 02:53 219g-dvb-fe-tda10046.fw the trailing 219g- is only to distinguish it from 217g- (same sized files) --] Aug 26 03:01:40 obelix kernel: saa7146: unregister extension 'budget_av'. Aug 26 03:01:45 obelix kernel: saa7146: register extension 'budget_av'. Aug 26 03:01:45 obelix kernel: ACPI: PCI Interrupt :00:0e.0[A] - GSI 19 (level, low) - IRQ 18 Aug 26 03:01:45 obelix kernel: saa7146: found saa7146 @ mem e08fa000 (revision 1, irq 18) (0x153b,0x1157). Aug 26 03:01:45 obelix kernel: DVB: registering new adapter (Terratec Cinergy 1200 DVB-T). Aug 26 03:01:45 obelix kernel: adapter failed MAC signature check Aug 26 03:01:45 obelix kernel: encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff Aug 26 03:01:45 obelix kernel: budget-av: ci interface initialised. Aug 26 03:01:45 obelix kernel: KNC1-0: MAC addr = 00:0a:ac:01:e9:72 Aug 26 03:01:45 obelix kernel: DVB: registering frontend 0 (Philips TDA10046H DVB-T) ... and tuning: Aug 26 03:05:28 obelix kernel: tda1004x: setting up plls for 53MHz sampling clock Aug 26 03:05:28 obelix kernel: tda1004x: found firmware revision 20 -- ok Aug 26 03:05:34 obelix kernel: tda1004x: setting up plls for 53MHz sampling clock Aug 26 03:05:34 obelix kernel: tda1004x: found firmware revision 20 -- ok Aug 26 03:26:12 obelix kernel: tda1004x: setting up plls for 53MHz sampling clock Aug 26 03:26:13 obelix kernel: tda1004x: found firmware revision 20 -- ok Aug 26 03:29:08 obelix kernel: tda1004x: setting up plls for 53MHz sampling clock Aug 26 03:40:33 obelix kernel: tda1004x: setting up plls for 53MHz sampling clock Aug 26 03:40:33 obelix kernel: tda1004x: found firmware revision 20 -- ok Aug 26 03:44:59 obelix kernel: tda1004x: setting up plls for 53MHz sampling clock Aug 26 03:44:59 obelix kernel: tda1004x: found firmware revision 20 -- ok Aug 26 03:47:12 obelix kernel: tda1004x: setting up plls for 53MHz sampling clock Aug 26 03:47:12 obelix kernel: tda1004x: found firmware revision 20 -- ok Aug 26 03:48:10 obelix kernel: tda1004x: setting up plls for 53MHz sampling clock Aug 26 03:48:10 obelix kernel: tda1004x: found firmware revision 20 -- ok next my tests with kernel 2.6.17: Aug 26 03:49:49 obelix kernel: Linux version 2.6.17-1.2174_FC5 ([EMAIL PROTECTED]) (gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) #1 Tue Aug 8 15:30:55 EDT 2006 ... Aug 26 03:49:54 obelix kernel: ACPI: PCI Interrupt :00:0e.0[A] - GSI 19 (level, low) - IRQ 201 Aug 26 03:49:54 obelix kernel: saa7146: found saa7146
Re: [linux-dvb] SAA7146 (KNC ONE DVB-C): ber,str values reliable?
HI! thomas schorpp wrote: Whatever I do (different cables, changing amplification, switching channels), czap always reports a ber of 195000. ber from device and driver is ok, use dvbsnoop -s signal. dvbsnoop reports the same as czap and femon here. dvbsnoop reports 195000 (hex), then it reports 0a, later again 195000. Without changing something with the hardware. unc is always 0. 1. czap (ctrl-z) 2. dvbsnoop 3. femon 4. fg What's fg? you may want to reportbug femon and czap, i see no driver issue in tda10021.c OK, but why does it jump from 195000 to 0a and back? Thanks! Thomas ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] SAA7146 (KNC ONE DVB-C): ber,str values reliable?
HI! thomas schorpp wrote: you may want to reportbug femon and czap, i see no driver issue in tda10021.c Please forget what I wrote in my last mail. You're absolutely right. When I do not use czap at all, but tune with MythTV, then femon and dvbsnoop report a ber between 0 and 10. Thanks for your help. I'll try to report this to czap. Thomas ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
