[vdr] LNB settings - what should they be?
Hi My dvb-s LNB is a Ku-Band LNBG DKF-2024. The box says: Input 11.70-12.50 Ghz L.O. 10.75 Ghz Noise 0.6dB Gain 60dB If I set VDR up as follows: Use DiSEqC:no SLOF (MHz):10750 Low LNB frequency (MHz): 11700 High LNB frequency (MHz): 12500 When I change channels I get: Sep 25 21:15:18 localhost vdr: [2058] ERROR: frontend 0/0: Invalid argument Sep 25 21:15:18 localhost kernel: DVB: adapter 0 frontend 0 frequency 12456000 out of range (95..215) If I set it to Use DiSEqC:no SLOF (MHz):11300 Low LNB frequency (MHz): 11300 High LNB frequency (MHz): 11300 I don't get this error, but get: Sep 25 21:15:57 localhost vdr: [2058] frontend 0/0 timed out while tuning to channel 3, tp 112456 Sep 25 21:17:02 localhost vdr: [2058] frontend 0/0 timed out while tuning to channel 3, tp 112456 Sep 25 21:18:07 localhost vdr: [2058] frontend 0/0 timed out while tuning to channel 3, tp 112456 I'm using a dm1105 dvb-s card which works under Windows on the same box, but szap and VDR do not. I can scan channels though with: ./scan dvb-s/OptusB1-NZ -l 11300 -x 0 OptusB1-NZ being: S 12456000 H 2250 AUTO S 12483000 H 2250 AUTO Any suggestions? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] LNB settings - what should they be?
On 25 Sep 2010, at 10:20, Simon Baxter wrote: Hi My dvb-s LNB is a Ku-Band LNBG DKF-2024. The box says: Input 11.70-12.50 Ghz L.O. 10.75 Ghz Noise 0.6dB Gain 60dB If I set VDR up as follows: Use DiSEqC:no SLOF (MHz):10750 Low LNB frequency (MHz): 11700 High LNB frequency (MHz): 12500 When I change channels I get: Sep 25 21:15:18 localhost vdr: [2058] ERROR: frontend 0/0: Invalid argument Sep 25 21:15:18 localhost kernel: DVB: adapter 0 frontend 0 frequency 12456000 out of range (95..215) If I set it to Use DiSEqC:no SLOF (MHz):11300 Low LNB frequency (MHz): 11300 High LNB frequency (MHz): 11300 I don't get this error, but get: Sep 25 21:15:57 localhost vdr: [2058] frontend 0/0 timed out while tuning to channel 3, tp 112456 Sep 25 21:17:02 localhost vdr: [2058] frontend 0/0 timed out while tuning to channel 3, tp 112456 Sep 25 21:18:07 localhost vdr: [2058] frontend 0/0 timed out while tuning to channel 3, tp 112456 I'm using a dm1105 dvb-s card which works under Windows on the same box, but szap and VDR do not. I can scan channels though with: ./scan dvb-s/OptusB1-NZ -l 11300 -x 0 OptusB1-NZ being: S 12456000 H 2250 AUTO S 12483000 H 2250 AUTO Any suggestions? An 'it works for me' and a suggestion. - 'it works for me': I have a Universal LNB, I'm in the UK, my VDR settings are (setup.conf), LnbFrequHi = 10600 LnbFrequLo = 9750 LnbSLOF = 11700 - A Suggestion: From, http://www.satsig.net/cgi-bin/yabb/YaBB.pl?board=ivsat-asia;action=display;num=1142160105 Receivers typically accept L band signals in a range starting at 950 MHz. If you want to receive satellite signals starting at 10.7 GHz then you need a LNB LO of 9.75 GHz. Maybe Astro are starting some services in the band 10.7 - 10.95 GHz ? For satellite TV, 'universal' LNBs with switchable LO frequencies of 9.75 and 10.6 GHz seem to be common. For Ku band reception, LO frequencies of 10, 10.75 and 11.3 GHz are also available. No idea, just guessing, try rearranging your values in the same sort order a my 'it works for me' section, High LNB frequency (MHz): 11700 Low LNB frequency (MHz): 10750 SLOF (MHz):12500 Don't know if this will fry your silicon. ?? Ian. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] TechnoTrend T-3000 Hybrid works under VDR?
Hi, Anybody tested DVB-T TechnoTrend T-3000 Hybrid under VDR? I want to order two of this card for VDR installation, and I don't know if it will works well with VDR or not. Sincerely yours. A. Hoseini. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.16
VDR developer version 1.7.16 is now available at Klaus, we have an open bug [1] to all versions of VDR on gentoo we changed any weeks befor our default profiles to use LDFLAGS on compile prozesses. snipp news-info about this from 2010-08-01 -Wl,--as-needed has been added to the default profile's LDFLAGS. This option optimizes the linking process, only linking binaries to libraries that are trully needed. This way, fewer libraries are loaded at runtime and fewer packages need to be rebuilt after library updates. /snap For more information on --as-needed, read [2]. Plz. let us check is it possible to add a fix generally to the Makefile to respect the LDFLAGS or should i fixed always localy on gentoo Disti. fixed should it be in this part of Makefile -# The main program: - -vdr: $(OBJS) $(SILIB) -$(CXX) $(CXXFLAGS) -rdynamic $(OBJS) $(LIBS) $(LIBDIRS) $(SILIB) -o vdr +# The main program: + +vdr: $(OBJS) $(SILIB) +$(CXX) $(CXXFLAGS) -rdynamic $(LDFLAGS) $(OBJS) $(LIBS) $(LIBDIRS) $(SILIB) -o vdr [1] http://bugs.gentoo.org/show_bug.cgi?id=333493 [2] http://www.gentoo.org/proj/en/qa/asneeded.xml Thanks, best regards -- Regards Gentoo Developer Joerg Bornkessel hd_bru...@gentoo.org ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] cDvbDevice::Initialize
Hi,
I'm having a setup with 4 dvb cards, and I'm running 3 vdr instances.
I'm using an udev rules to make sure adapter numbers don't change.
I'm using the -D option the assign cards to vdr instances.
I've just discovered that vdr -D 3 would not use the adapter 3 if
adapter2 was missing from /dev/dvb/.
Here is the patch i'm testing to correct this issue, feel free to
comment.
--- dvbdevice.c.orig 2010-09-25 16:29:09.341396415 +0200
+++ dvbdevice.c 2010-09-25 16:25:37.087849316 +0200
@@ -786,29 +786,18 @@
new cDvbSourceParam('C', DVB-C);
new cDvbSourceParam('S', DVB-S);
new cDvbSourceParam('T', DVB-T);
- int Checked = 0;
int Found = 0;
- for (int Adapter = 0; ; Adapter++) {
- for (int Frontend = 0; ; Frontend++) {
- if (Exists(Adapter, Frontend)) {
- if (Checked++ MAXDVBDEVICES) {
-if (UseDevice(NextCardIndex())) {
- if (Probe(Adapter, Frontend))
- Found++;
- }
-else
- NextCardIndex(1); // skips this one
-}
- }
- else if (Frontend == 0)
- goto LastAdapter;
- else
- goto NextAdapter;
- }
- NextAdapter: ;
- }
-LastAdapter:
- NextCardIndex(MAXDVBDEVICES - Checked); // skips the rest
+ for (int Adapter = 0; Adapter = MAXDVBDEVICES; Adapter++) {
+ if (UseDevice(NextCardIndex())) {
+for (int Frontend = 0; Exists(Adapter, Frontend); Frontend++) {
+ if (Probe(Adapter, Frontend)) {
+ Found++;
+ }
+}
+ } else {
+NextCardIndex(1); // skips this one
+ }
+ }
if (Found 0)
isyslog(found %d DVB device%s, Found, Found 1 ? s : );
else
--
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] LNB settings - what should they be?
My dvb-s LNB is a Ku-Band LNBG DKF-2024. The box says: Input 11.70-12.50 Ghz L.O. 10.75 Ghz Noise 0.6dB Gain 60dB If I set VDR up as follows: Use DiSEqC:no SLOF (MHz):10750 Low LNB frequency (MHz): 11700 High LNB frequency (MHz): 12500 No idea, just guessing, try rearranging your values in the same sort order a my 'it works for me' section, High LNB frequency (MHz): 11700 Low LNB frequency (MHz): 10750 High LNB frequency (MHz): 12500 When I change channels I get: Sep 25 21:15:18 localhost vdr: [2058] ERROR: frontend 0/0: Invalid argument Sep 25 21:15:18 localhost kernel: DVB: adapter 0 frontend 0 frequency 12456000 out of range (95..215) Thanks - changed my settings to: Use DiSEqC:no SLOF (MHz):12500 Low LNB frequency (MHz): 10750 High LNB frequency (MHz): 11700 and I no longer the the out of range error which is progress I guess!! But I still get these errors and no picture on any channels: Sep 26 08:38:28 localhost vdr: [1531] switching to channel 2 Sep 26 08:38:30 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 2, tp 112456 Sep 26 08:39:35 localhost vdr: [1531] ERROR: /var/cache/vdr/epg.data.$$$: No such file or directory Sep 26 08:39:35 localhost vdr: [1531] ERROR (epg.c,1160): No such file or directory Sep 26 08:39:38 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 16, tp 112483 Sep 26 08:39:58 localhost vdr: [1531] switching to channel 3 Sep 26 08:40:08 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 3, tp 112456 Sep 26 08:40:08 localhost vdr: [1531] switching to channel 4 Sep 26 08:40:17 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 4, tp 112456 Sep 26 08:40:18 localhost vdr: [1531] switching to channel 5 Sep 26 08:40:26 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 5, tp 112456 Sep 26 08:40:27 localhost vdr: [1531] switching to channel 6 Sep 26 08:40:36 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 6, tp 112456 Sep 26 08:40:36 localhost vdr: [1531] switching to channel 7 Sep 26 08:40:45 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 7, tp 112456 Sep 26 08:40:46 localhost vdr: [1531] switching to channel 8 Sep 26 08:40:54 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 8, tp 112456 Sep 26 08:40:55 localhost vdr: [1531] switching to channel 9 Sep 26 08:41:03 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 9, tp 112456 Sep 26 08:41:04 localhost vdr: [1531] switching to channel 10 Sep 26 08:41:13 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 10, tp 112456 Sep 26 08:41:13 localhost vdr: [1531] switching to channel 11 Sep 26 08:41:22 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 11, tp 112456 Sep 26 08:41:23 localhost vdr: [1531] switching to channel 12 Sep 26 08:41:31 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 12, tp 112456 Sep 26 08:41:32 localhost vdr: [1531] switching to channel 13 Sep 26 08:41:41 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 13, tp 112456 Sep 26 08:41:41 localhost vdr: [1531] switching to channel 14 Sep 26 08:41:50 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 14, tp 112456 Sep 26 08:41:51 localhost vdr: [1531] switching to channel 15 Sep 26 08:41:59 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 15, tp 112456 Sep 26 08:42:00 localhost vdr: [1531] switching to channel 16 Sep 26 08:42:09 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 16, tp 112483 Sep 26 08:42:10 localhost vdr: [1531] switching to channel 17 Sep 26 08:42:19 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 17, tp 112483 Sep 26 08:42:19 localhost vdr: [1531] switching to channel 18 Sep 26 08:42:28 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 18, tp 112483 Sep 26 08:42:28 localhost vdr: [1531] switching to channel 19 Sep 26 08:42:37 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 19, tp 112483 Sep 26 08:42:38 localhost vdr: [1531] switching to channel 20 Sep 26 08:42:47 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 20, tp 112483 Sep 26 08:42:48 localhost vdr: [1531] switching to channel 21 Sep 26 08:42:56 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 21, tp 112483 Sep 26 08:42:56 localhost vdr: [1531] switching to channel 22 Sep 26 08:43:05 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 22, tp 112483 Sep 26 08:43:06 localhost vdr: [1531] switching to channel 23 Sep 26 08:43:15 localhost vdr: [1535] frontend 0/0 timed out while tuning to channel 23, tp 112483 My channels.conf is: TV3;TV Works:12456:hM2O0S0:S160.0E:22500:512=2:6...@4:712:0:1920:47:21:0 C4;TV
Re: [vdr] cDvbDevice::Initialize
Am 25.09.2010 16:38, schrieb syrius...@no-log.org: I'm having a setup with 4 dvb cards, and I'm running 3 vdr instances. I'm using an udev rules to make sure adapter numbers don't change. I'm using the -D option the assign cards to vdr instances. I've just discovered that vdr -D 3 would not use the adapter 3 if adapter2 was missing from /dev/dvb/. Here is the patch i'm testing to correct this issue, feel free to comment. This would still be wrong if adapter 2 is a dual or more frontend device, because if adapter 2 has two frontends, then -D 2 and -D 3 refer to adapter 2 and -D 4 is adapter 3. IMHO the -D numbers are a bit outdated anyway, and I would prefer a way to use /dev/dvb paths directly. Some concept ideas: vdr -D /dev/dvb/adapter0 - use only adapter 0 vdr -D /dev/dvb/adapter0/frontend1 - use only frontend 1 of adapter 0 - this could be tricky vdr -D /dev/dvb/adapter1 -D /dev/dvb/adapter0 - Swap ordering of devices vdr -D /dev/dvb/primary - follow a symlink primary - adapter0, like generated by udev vdr -D /dev/dvb/* - use all DVB devices vdr -D /dev/dvb/primary -D /dev/dvb/adapter* - Use primary first, then use all remaining devices. No duplicates. Implementing this needs some API changes, esp. since device plugins can decide to override the default receiver of VDR, and this interface just has adapter and frontend number. (dvbsddevice replaces the receive-only receiver that way.) Also, frontend numbers are more than parts of file names. If you swap frontend 0 and 1 in the file system, VDR cannot receive any more. (been there, done that.) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cDvbDevice::Initialize
Udo Richter udo_rich...@gmx.de writes: Hi ! Thanks for your answer ! Am 25.09.2010 16:38, schrieb syrius...@no-log.org: I'm having a setup with 4 dvb cards, and I'm running 3 vdr instances. I'm using an udev rules to make sure adapter numbers don't change. I'm using the -D option the assign cards to vdr instances. I've just discovered that vdr -D 3 would not use the adapter 3 if adapter2 was missing from /dev/dvb/. Here is the patch i'm testing to correct this issue, feel free to comment. This would still be wrong if adapter 2 is a dual or more frontend device, because if adapter 2 has two frontends, then -D 2 and -D 3 refer to adapter 2 and -D 4 is adapter 3. IMHO the -D numbers are a bit outdated anyway, and I would prefer a way to use /dev/dvb paths directly. Some concept ideas: sure, man page says: -D num, --device=num Use only the given DVB device (num = 0, 1, 2...). There may be several -D options (by default all DVB devices will be used). I was thinking adapter == device. i think you're right, it's kind of outdated. vdr -D /dev/dvb/adapter0 - use only adapter 0 agreed, or -D 666 or -D /dev/dvb/adapter666 (l...@usedevice) vdr -D /dev/dvb/adapter0/frontend1 - use only frontend 1 of adapter 0 - this could be tricky vdr -D /dev/dvb/adapter1 -D /dev/dvb/adapter0 - Swap ordering of devices i've stopped trying to understand how GetDevice decides... i guess it's outdated as well. vdr -D /dev/dvb/primary - follow a symlink primary - adapter0, like generated by udev vdr -D /dev/dvb/* - use all DVB devices vdr -D /dev/dvb/primary -D /dev/dvb/adapter* - Use primary first, then use all remaining devices. No duplicates. Implementing this needs some API changes, esp. since device plugins can decide to override the default receiver of VDR, and this interface just has adapter and frontend number. (dvbsddevice replaces the receive-only receiver that way.) Also, frontend numbers are more than parts of file names. If you swap frontend 0 and 1 in the file system, VDR cannot receive any more. (been there, done that.) ok, it's not going to change anytime soon. If we consider a device (man page) == an adapter, am I breaking things down ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
