[linux-dvb] AW: wrong programs
-Ursprüngliche Nachricht- Von: Gernot A. Weber [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 27. Juni 2001 02:06 An: [EMAIL PROTECTED] Betreff: [linux-dvb] wrong programs Hi, now I'm able to run vdr. I can tune in to the Sailing Channel, which is on 11.946GHz. But I can't find it in the Channel list of Astra and I can't find any other channel distributed in the channel list. It is a dual sat dish to receive astra and eutelsat, but I don't think the card sends the signal to switch to eutelsat (and it would be the wrong frequency on eutelsat). How can I find the right frequencies to the channels? Hi, use 'dtv_scan', but make sure that you have the correct Diseqc setup for your system; another possibility would be to look in the 'dvbrc.[34]sats' coming with the DVB driver and convert parts of this file to channels.conf (there should exist a tool for that)... Regards, Rolf -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] DVD programm with complete menu ;-)
Hello, I just found: http://www.dtek.chalmers.se/groups/dvd/index.html which has some features that could be could to have in dvdplayer... Have a great day, Greg http://ulima.unil.ch/greg ICQ:16624071 mailto:[EMAIL PROTECTED] -- No attachments (even text) are allowed -- -- Type: application/pgp-signature -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Wrong data from Hauppauge NOVA
I had the same problem. I didn't investigate the problem that deeply. I modified remux.c to write the plain TS. Last weekend I tried the latest DVB driver and VDR 0.82. This version works without my modification. Anton -Original Message- From: Ralf Bauer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 27, 2001 9:02 AM To: [EMAIL PROTECTED] Subject: [linux-dvb] Re: Wrong data from Hauppauge NOVA They are not wrong. The normal WinTV DVB-S card does not deliver the original PES header for the channel which is currently display, only the elementary stream. The PES header and TS packaging you get from the driver is a reconstruction. I have no way to know the real ID used in the original TS. So, I use 0xe0, the first possible video ID. The Nova card delivers the original TS packets. It seems that some channels use other video Ids like 0xe1, which is allowed according to the specs. So, just change VDR to allow the whole range of video IDs. Strange that nobody else had the same problem, because VDR only knows of the E0 video ID. Maybe nobody else is watching SAT1 ;-) What do you mean with the whole range of video IDs, is it E0-EF? Ralf. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Wrong data from Hauppauge NOVA
The problem came in with the code for the stripping of the AC3 stream. Before that VDR didn't care about the video IDs. Maybe we should keep one eye on that piece of code in case we notice some other replay problems in the near future. ;-) Ralf. -Original Message- From: Anton Schegg [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 27, 2001 09:52 To: '[EMAIL PROTECTED]' Subject: [linux-dvb] Re: Wrong data from Hauppauge NOVA I had the same problem. I didn't investigate the problem that deeply. I modified remux.c to write the plain TS. Last weekend I tried the latest DVB driver and VDR 0.82. This version works without my modification. Anton -Original Message- From: Ralf Bauer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 27, 2001 9:02 AM To: [EMAIL PROTECTED] Subject: [linux-dvb] Re: Wrong data from Hauppauge NOVA They are not wrong. The normal WinTV DVB-S card does not deliver the original PES header for the channel which is currently display, only the elementary stream. The PES header and TS packaging you get from the driver is a reconstruction. I have no way to know the real ID used in the original TS. So, I use 0xe0, the first possible video ID. The Nova card delivers the original TS packets. It seems that some channels use other video Ids like 0xe1, which is allowed according to the specs. So, just change VDR to allow the whole range of video IDs. Strange that nobody else had the same problem, because VDR only knows of the E0 video ID. Maybe nobody else is watching SAT1 ;-) What do you mean with the whole range of video IDs, is it E0-EF? Ralf. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Getting TS again (was: VDR to MPEG)
Markku Leinio writes: At 12:44 24.6.2001 +0200, Marcus O.C. Metzler wrote: Due to the limitations of the DVB-s card we cannot get to the original TS coming from the transponder. The TS has to be recreated from the audio and video buffer of the card. That leads to problems with muxing and leaves us without a usable PCR. This makes it also difficult to transcode the TS into a PS. The TS stream from the Nova cards on the other hand is just as we get it from the transponder with PCR and everything. It should be much easier to make a usable PS from that. How about setting up a filter for PCR? I mean, in test_dvr.c there are set up two filters, one for audio (DMX_PES_AUDIO) and one for video (DMX_PES_VIDEO). There is, however, a constant named DMX_PES_PCR. Can that be used to get the PCR with the stream? Apparently n-tv sends PCR as a separate PID and not inside the video PID? Do you know the PID to be used? Video PID is 162 and audio is 96, at least with them I have got some kind of TS out of the /dev/ost/dvr. Strange thing is that every 12th (or so) TS packet is coming with the adaptation field set, but there is no information in the adaptation field, no flag is set. Why is that? Well, how many times do we have to say it? You cannot get the original TS packets from the AV7110. Everything you get from the driver is a reconstruction made from the available data which, in case of the currently watched program, is the video ES and PTS and the audio PES. Anything else like the adaptation field data is lost. Of course we still need (empty) adaptation fields to adapt (hence the name) to PES packets lengths not divisible by 184. Ralph -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Nice to have features for VDR ....
Hi! * Matthias Weingart [EMAIL PROTECTED] [20010626 17:34]: On Tue, 26 Jun 2001, Andreas 'Count' Kotes wrote: * [EMAIL PROTECTED] [EMAIL PROTECTED] [20010626 11:42]: 2. Allow to execute commands via shortcut. The first command could have the shortcut 001 (0 is for switching to the last programm ... but if it is followed by another number it could execute a shortcut to a command) btw, am I the only one who has problems with multi-diggit channels using lirc? I sometimes can't touch in the number fast enough, and get onto a wrong channel .. or some presses get lost .. I'm using a d-box remote control, maybe that is the problem? Enable DMA for your harddisc. (hdparm) uhm .. how should this change the behaviour of the lirc remote control? I'm playing via an smb mounted filesystem, by the way ... Count -- Andreas Kotes - UIN: 3741366 - The views expressed herein are (only) mine. You don't have to change the world... to change the world. You're either part of the problem, part of the solution, or part of the scenery. Only you decide. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Best DVB-s card
Hello, I'm just another newbie looking to bye a DVB-s card capable of using CI. Help me by the question which one?! Can you recomend a certain model (e.g. Siemens, Happauge, ...) and version, which seems to do best job for vdr and dvdplayer? Or, vice versa, which models/versions to avoid? Does somebody have information about better upcoming products? Is there also a hardware description for the IR-remote control supported from the vdr and dvdplayer somewhere on the net? Plese give me a hint! thank you Walter -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Nice to have features for VDR ....
On Wed, 27 Jun 2001, Andreas 'Count' Kotes wrote: btw, am I the only one who has problems with multi-diggit channels using lirc? I sometimes can't touch in the number fast enough, and get onto a wrong channel .. or some presses get lost .. I'm using a d-box remote control, maybe that is the problem? Enable DMA for your harddisc. (hdparm) uhm .. how should this change the behaviour of the lirc remote control? I'm playing via an smb mounted filesystem, by the way ... Other interrupts can block the IR-decoding routine. If they lasts to long in the interrupt thread, the IR routine will lose some characters - most commonly IDE-adapters have this behaviour, maybe other drivers too. With DMA enabled for the HD this should be better. Matthias -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] DVB-S in the US.
I'm using the Hauppauge DVB-S card with the DVB software, in the U.S..
My dish is aimed at Echostar 6:
http://www.lyngsat.com/echo6.shtml
(watch out for the pop-up adds.)
In using the libdvb/stest utility, I setup my TEST file as:
LNB ID 0 TYPE 0 DISEQCNR 0
SAT ID 119 NAME EchoStar 6 LNBID 0 FMIN 974000 FMAX 1411000
TRANSPONDER ID 0002 SATID 0119 TYPE 0 FREQ 989000 POL H SRATE
2000 FEC 2
TRANSPONDER ID 0003 SATID 0119 TYPE 0 FREQ 1003000 POL H SRATE
2000 FEC 2
TRANSPONDER ID 0006 SATID 0119 TYPE 0 FREQ 1047000 POL H SRATE
2000 FEC 2
TRANSPONDER ID 0008 SATID 0119 TYPE 0 FREQ 1076000 POL H SRATE
2000 FEC 2
TRANSPONDER ID 0009 SATID 0119 TYPE 0 FREQ 1091000 POL H SRATE
2000 FEC 2
TRANSPONDER ID 000a SATID 0119 TYPE 0 FREQ 1105000 POL H SRATE
2000 FEC 2
TRANSPONDER ID 000b SATID 0119 TYPE 0 FREQ 112 POL H SRATE
2000 FEC 2
TRANSPONDER ID 000c SATID 0119 TYPE 0 FREQ 1134000 POL H SRATE
2000 FEC 2
TRANSPONDER ID 000d SATID 0119 TYPE 0 FREQ 1149000 POL H SRATE
2000 FEC 2
TRANSPONDER ID 000e SATID 0119 TYPE 0 FREQ 1164000 POL H SRATE
2000 FEC 2
TRANSPONDER ID 0011 SATID 0119 TYPE 0 FREQ 1207000 POL H SRATE
2000 FEC 2
TRANSPONDER ID 0012 SATID 0119 TYPE 0 FREQ 1222000 POL H SRATE
2000 FEC 2
TRANSPONDER ID 0014 SATID 0119 TYPE 0 FREQ 1251000 POL H SRATE
2000 FEC 2
TRANSPONDER ID 0015 SATID 0119 TYPE 0 FREQ 1266000 POL H SRATE
2000 FEC 2
I figure we don't need the dual LNB baselines in the states, so I set
all that to zero, and work directly off the LNB frequency.
The FEC is reported to be 3/4. I don't know which dvb code this
corresponds to, but FEC code 2 and 3 work; 2 seems to work a
little better. I'm not sure what the type field is, it doesn't seem
to effect results anyway.
Running stest proves somewhiat unpredictable. Sometimes it finds
PAT/PMT data for a frequency, other times it doesn't. Sometimes the
channel ID's are all printed as for a given frequency,
sometimes the printout is fine.
I did find one error, where DVB.cc got confused and try to look at
cable data. In DVB::scan_tp:
if (!prog-prog_nr) {
dvb_nit_t *nit = (dvb_nit_t *)calloc (1, sizeof (dvb_nit_t));
if (GetNIT(nit) = 0) {
if (prog-prog.nit)
free(prog-prog.nit);
prog-prog.nit = nit;
} else
free(nit);
//if (fdvb = 0) osd.Text(64, 120, 2, 1, NIT);
cerr NIT\n;
// FIXME: fix NIT parsing
//if (front.type!=FRONT_DVBC)
tp.freq=(uint32_t) (100*nit-freq+0.5);
I commented out that last line, and it quit printing the wrong
frequency for found PAT/PMT's.
The output data from stest looks something like this:
LNB ID 0 TYPE 0 DISEQCNR 0
SAT ID 119 NAME EchoStar 6 LNBID 0 FMIN 974000 FMAX 1411000
TRANSPONDER ID 0002 SATID 0119 TYPE 1 FREQ 989000 POL H SRATE
2000 FEC 2
CHANNEL ID 0 NAME BET SATID 0119 TPID 2 SID 7c TYPE 1 VPID
1022 APID 1023 PCRPID 1022
CHANNEL ID 1 NAME HBO-E SATID 0119 TPID 2 SID 12c TYPE 1 VPID
1422 APID 1423 PCRPID 1422
CHANNEL ID 2 NAME GOLF SATID 0119 TPID 2 SID 191 TYPE 1 VPID
1822 APID 1823 PCRPID 1822
CHANNEL ID 3 NAME EVENT SATID 0119 TPID 2 SID 1c7 TYPE 1 VPID
1022 APID 1023 PCRPID 1022
CHANNEL ID 4 NAME CNNFN SATID 0119 TPID 2 SID ce TYPE 1 VPID
1422 APID 1423 PCRPID 1422
CHANNEL ID 5 NAME GLVSN SATID 0119 TPID 2 SID 110 TYPE 1 VPID
1822 APID 1823 PCRPID 1822
CHANNEL ID 6 NAME TECH SATID 0119 TPID 2 SID bf TYPE 1 VPID
1022 APID 1023 PCRPID 1022
CHANNEL ID 7 NAME COURT SATID 0119 TPID 2 SID cc TYPE 1 VPID
1422 APID 1423 PCRPID 1422
CHANNEL ID 8 NAME BRAVO SATID 0119 TPID 2 SID 81 TYPE 1 VPID
1022 APID 1023 PCRPID 1022
CHANNEL ID 9 SATID 0119 TPID 2 SID 8f01 TYPE 0 VPID 1422 APID
1423 PCRPID 1422
CHANNEL ID a NAME AUD01 SATID 0119 TPID 2 SID 39b TYPE 1 VPID
1822 APID 1823 PCRPID 1822
CHANNEL ID b NAME AUD13 SATID 0119 TPID 2 SID 3a8 TYPE 1 VPID
1022 APID 1023 PCRPID 1022
CHANNEL ID c NAME AUD16 SATID 0119 TPID 2 SID 3ab TYPE 1 VPID
1422 APID 1423 PCRPID 1422
CHANNEL ID d NAME METRO SATID 0119 TPID 2 SID 3a4 TYPE 1 VPID
1822 APID 1823 PCRPID 1822
Note how the vpid/apid data keeps repeating (for example, it says the
only audio PIDS for these 14 channels are 1022, 1422, and 1822). The
real PIDS can be seen here:
http://www.lyngsat.com/dig/dish119.shtml
(Again, sorry for any pop-up adds.)
Furthermore, stest doesn't find anything at the frequencies for about
half of the transponder ID's.
I found two flags pertaining to NTSC/PAL in the driver, but switching
them to
[linux-dvb] again, problem with insmod
First of all thank you all for helping me with my card; I'm here again with another problem. I recompiled my kernel 2.2.19, finally I got a working one (hope) :) Now I'm using that kernel, and still have sources in /usr/src/linux The problem occurs again when trying insmod after succesfully compiling the driver ver. 0.8.2 in /home/amalesan/DVB/driver: ... i2c-core.o: i2c core module dvb: no dvb(s) found! dvb.o init_module: Device or resource busy Hint: this error can be caused by incorrect module parameters, including invalid IO or IRQ parameters SIOCSSIFADDR: No such device dvb0: unknow interface: No such device make: *** [insmod] Error 255 Could it really be a problem of IRQs and IO? I have a 3com 905B net card IRQ 12 and my ISDN modem with IRQ 9. And, of course, the DVB card (Techsan Electronics, with Netsystem), which should be setted on IRQ 11 (according to lspci). ** cat /proc/interrupts CPU0 0: 164662 XT-PIC timer 1: 1463 XT-PIC keyboard 2: 0 XT-PIC cascade 8: 1 XT-PIC rtc 9: 1420 XT-PIC HiSax 12: 31005 XT-PIC eth0 13: 1 XT-PIC fpu 14: 46673 XT-PIC ide0 15: 7 XT-PIC ide1 NMI: 0 ERR: 0 ** cat /proc/ioports -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 02f8-02ff : serial(set) 0376-0376 : ide1 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(set) c800-c87f : eth0 f000-f007 : ide0 f008-f00f : ide1 Any idea? Thank you in advance, bye! Andrea -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] VDR 0.83 and today's cvs-driver?
Hi, has anybody else problems with vdr 0.83 and the today's cvs-driver? With the new card VDR stucks right after changing to the initial channel. No reaction. I had to kill -9 all threads and than I get: Jun 27 21:37:01 video kernel: commandrequest error Jun 27 21:37:06 video kernel: outcommand error 1 Jun 27 21:37:06 video kernel: dvb: ARM RESET Any hints? Meanwhile I'm back to pre-today driver, which works really good with the new card. Bye. -- Stefan Huelswitt | http://home.pages.de/~nathan [EMAIL PROTECTED] | IRC: nathan @ #nrw.de -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: VDR 0.83 and today's cvs-driver?
Stefan Huelswitt wrote: Hi, has anybody else problems with vdr 0.83 and the today's cvs-driver? [...] Any hints? Meanwhile I'm back to pre-today driver, which works really good with the new card. same thing here, Alfred -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: again, problem with insmod
Andrea Malesan wrote: [ ... ] i2c-core.o: i2c core module dvb: no dvb(s) found! dvb.o init_module: Device or resource busy Hint: this error can be caused by incorrect module parameters, including invalid IO or IRQ parameters SIOCSSIFADDR: No such device dvb0: unknow interface: No such device make: *** [insmod] Error 255 is CONFIG_PNP in tje kernel configuration enabled ? Alfred -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: VDR 0.83 and today's cvs-driver?
On 27 Jun 2001 Andreas Share [EMAIL PROTECTED] wrote: Any hints? Meanwhile I'm back to pre-today driver, which works really good with the new card. Same thing here. I will test to remove the dvb-net.o in the makefile, because this is new. Not for the current driver, it was added a few days ago. I think the buffer rearangements are a better candidate... -- Stefan Huelswitt | http://home.pages.de/~nathan [EMAIL PROTECTED] | IRC: nathan @ #nrw.de -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: DVB-S in the US.
Chris, I have the exact same setup here in the states too and I've been playing with both the TT software for 'doze 98 and the Linux driver/vdr since about March and have yet to have any success under Linux; I've covered much of the same ground you have on the linux side and can confirm: 1) I've never got a lock or video yet with dvb/vdr, using mainly T5 since there is plenty of fta there for us (USA). 2) The video out pre-lock has always been PAL for me too even after changing both code references and the driver startup option. 3) I haven't even gotten past the 2.1 'channel not sync'd' issue which many are having now with the current driver on both sides of the pond. 4) Under the TT/Win software there is definitely an issue with the current drivers/firmware and spectral_inversion settings. The auto setting which all the software ( TT Haup's ) default to only currently finds SI_OFF bouquets. This may be isolated to the Win firmware; I think dvb loads its own version of firmware, not sure on this. It looks like you are after dish programming; see if the transponders you can at least partially decode are all SI_ON per lyngsat and if those that won't lock are SI_OFF... ( I'll try this too on E6 in the next day or so and report back... ) Do you know if a CA board will work with dish and their access card??? If it does then I can expand my usefulness of dvb/vdr tremendously! ( once its working well! ) and maybe ditch my 301 box ( got a 501 pvr too.. not too shabby ) but to be able to record on the pc under my dish subscription is the holy grail!!!. I've finally been able to use this card reasonably since I got ahold of the new TT api that supports the 2.1's new frontend; this is how I was able to confirm the spectral inversion issue ( at least under all flavors of the TT or Haup software to-date ) I also added custom settings for Viterbi and, as you have also experienced, changing this seems to not stop locks or help locking when there are issues. Its almost like its always in VR_AUTO mode regardless of the forced setting. If the two platform's apis are the same then: VR_AUTO = 0,// DVB-S: automatic detection of viterbi rate VR_1_2 = 1,// DVB-S: viterbi rate: 1/2 VR_2_3 = 2,// DVB-S: viterbi rate: 2/3 VR_3_4 = 3,// DVB-S: viterbi rate: 3/4 VR_4_5 = 4,// DVB-S: viterbi rate: 4/5 VR_5_6 = 5,// DVB-S: viterbi rate: 5/6 VR_6_7 = 6,// DVB-S: viterbi rate: 6/7 VR_7_8 = 7,// DVB-S: viterbi rate: 7/8 VR_8_9 = 8,// DVB-S: viterbi rate: 8/9 I'll confirm this too later today and report back. Have you compared your results under Linux with the Win software? ( Just curious... ) You have actually gotten further with dvb/vdr under linux than I have to-date but I switched my experimenting to Win after I got the api and while the 2.1 driver support is still iffy. Please let me know about the dishnet CA support; I may need to place another order to get me a CA board! Bill Chris Worley wrote: I'm using the Hauppauge DVB-S card with the DVB software, in the U.S.. My dish is aimed at Echostar 6: http://www.lyngsat.com/echo6.shtml (watch out for the pop-up adds.) In using the libdvb/stest utility, I setup my TEST file as: LNB ID 0 TYPE 0 DISEQCNR 0 SAT ID 119 NAME EchoStar 6 LNBID 0 FMIN 974000 FMAX 1411000 TRANSPONDER ID 0002 SATID 0119 TYPE 0 FREQ 989000 POL H SRATE 2000 FEC 2 TRANSPONDER ID 0003 SATID 0119 TYPE 0 FREQ 1003000 POL H SRATE 2000 FEC 2 TRANSPONDER ID 0006 SATID 0119 TYPE 0 FREQ 1047000 POL H SRATE 2000 FEC 2 TRANSPONDER ID 0008 SATID 0119 TYPE 0 FREQ 1076000 POL H SRATE 2000 FEC 2 TRANSPONDER ID 0009 SATID 0119 TYPE 0 FREQ 1091000 POL H SRATE 2000 FEC 2 TRANSPONDER ID 000a SATID 0119 TYPE 0 FREQ 1105000 POL H SRATE 2000 FEC 2 TRANSPONDER ID 000b SATID 0119 TYPE 0 FREQ 112 POL H SRATE 2000 FEC 2 TRANSPONDER ID 000c SATID 0119 TYPE 0 FREQ 1134000 POL H SRATE 2000 FEC 2 TRANSPONDER ID 000d SATID 0119 TYPE 0 FREQ 1149000 POL H SRATE 2000 FEC 2 TRANSPONDER ID 000e SATID 0119 TYPE 0 FREQ 1164000 POL H SRATE 2000 FEC 2 TRANSPONDER ID 0011 SATID 0119 TYPE 0 FREQ 1207000 POL H SRATE 2000 FEC 2 TRANSPONDER ID 0012 SATID 0119 TYPE 0 FREQ 1222000 POL H SRATE 2000 FEC 2 TRANSPONDER ID 0014 SATID 0119 TYPE 0 FREQ 1251000 POL H SRATE 2000 FEC 2 TRANSPONDER ID 0015 SATID 0119 TYPE 0 FREQ 1266000 POL H SRATE 2000 FEC 2 I figure we don't need the dual LNB baselines in the states, so I set all that to zero, and work directly off the LNB frequency. The FEC is reported to be 3/4. I don't know which dvb code this corresponds to, but FEC code 2 and 3 work; 2 seems to work a little better. I'm not sure what the type field is, it doesn't seem to effect results anyway. Running stest proves somewhiat unpredictable. Sometimes it finds PAT/PMT data
[linux-dvb] Re: DVB-S in the US.
William E. Mrozinski wrote: 1) I've never got a lock or video yet with dvb/vdr, using mainly T5 since there is plenty of fta there for us (USA). I am getting a lock on the audio and teletext PIDS. The video is all ;) that's screwed up. 2) The video out pre-lock has always been PAL for me too even after changing both code references and the driver startup option. The two references I've tried are saa7146_core.c: /* insmod parameter: some programs (e.g. ´vic´) do not allow to specify the used video-mode, so you have to tell this to the modules by hand, 0 = PAL, 1 = NTSC */ static int mode = 1; (which is probably what you're changing from insmod) and dvb.c (line 5767): dvb-vidmode=VIDEO_MODE_NTSC; Yet, the output is still PAL. I'm beginning to think that the problem is an NTSC/PAL issue. I was expecting to see a screwed-up NTSC stream, not black... but maybe the hardware refuses to decode streams in the wrong mode. 3) I haven't even gotten past the 2.1 'channel not sync'd' issue which many are having now with the current driver on both sides of the pond. By 2.1, I'm guessing you mean a rev of the Hauppauge or Siemans board? Sorry to not have done my homework on this issue. I haven't seen a channel not sync'd problem. 4) Under the TT/Win software there is definitely an issue with the current drivers/firmware and spectral_inversion settings. The auto setting which all the software ( TT Haup's ) default to only currently finds SI_OFF bouquets. This may be isolated to the Win firmware; I think dvb loads its own version of firmware, not sure on this. Dvb definitely loads its own firmware. I'm not familiar with SI_OFF bouquets. Is this BAT table entries? It looks like you are after dish programming; That's just what we're currently aimed at... we're just looking for test streams for software developers to work with... we really don't care what we're aimed at. see if the transponders you can at least partially decode are all SI_ON per lyngsat and if those that won't lock are SI_OFF... ( I'll try this too on E6 in the next day or so and report back... ) Thanks for making me look again. I had the polarity wrong on all the transponders I wasn't picking up. Again, what's SI_OFF? I know what SI tables are, but I'm not sure what OFF is. Do you know if a CA board will work with dish and their access card??? My guess is, no. We have a Siemans card too, with the access card adapter. It takes a PCMCIA card, not a Smart Card. I think this is from some Open?? standard. I don't know if there's a smart card adapter or if there's a PCMCIA version of the smart card or if there's a PCMCIA sub-adapter for a smart card. VR_2_3 = 2,// DVB-S: viterbi rate: 2/3 VR_3_4 = 3,// DVB-S: viterbi rate: 3/4 Both these values worked for me; I had no clue as to the values for this table (I'm guessing this correlates to the FEC value in the .dvbrc file), so I just did it by trial and error. My guess was, 2 was correct since I more often got good channel data using a 2. Now that you've clarified this for me, 3 is the correct value. Go figure. Have you compared your results under Linux with the Win software? ( Just curious... ) RANT My company buys us DELL computers, which we immediately overwrite Windows with Linux (there no way to find a VAR that will supply us Linux machines; we have to pay the Microsoft tax). I was told to put Windows back on one of these machines to try this out. It seems these DELL machines have special Windows drivers for nearly every device embedded on the motherboard (even though they look like standard peripherals). Plus, the NT CD's sent with these machines (never opened) wouldn't install. It took me four days to get Windows back on the machine (The 7 disk SuSE set takes about 4 hours). My first attempts with the Hauppauge software didn't produce any results. Needing to make progress, I put the card in a Linux machine and haven't tried the Windows machine since. /RANT If we choose to use this sort of product (for software developers to use), I'll have to evaluate the Windows drivers eventually, but I'm not looking forward to that. Chris -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
