[vdr] transponder moving
ARD swaps transponder 2nd June. With VDR that seems to be difficult? Exsample: ARD is now at say Channel 5 the new ARD Channels are detected at Channel 1200 ff... VDR allows to mark Channel 1200 and move it 1204 lines back wards via cursor. (Channel table does no wrapp, there are 1700 channel entries totally so the other way arround would be only 500 lines...)) OK, Channel lists can be sorted by transponder owners. That way old and new ARD channels are side-byside, but in that mode move does not work anymore... OK, so let's move the 1204 lines so the new channel will become Channel 6 Now simply delete channel 5... Oops, does not work as there are active timers. OK, lets go the timers, and move them first. No way to sort them by Channels, and not really attractive to change every timer manually. I can't imagine that this is really the intended way if a buque swaps transponders Please tell me what i made wrong? Why is there no exchange or direct renumber? BTW: The new ARD channels will be on lo-Band. A further reason to make the single LNB patch part of VDR... Rainer---= Vertraulich // Key-ID:38F34C59 // =--ocholl, Kiel, Germany ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvb-ttpci: ARM crashed @ card 1
[EMAIL PROTECTED](Udo Richter) 16.02.08 12:01 Rainer Zocholl wrote: until he learned that every card in the system MUST have a -good- antenna signal, regardless if the card is used or not... because EPG scan would use every card and that VDR behaves -unexpectable- sick without -good- antenna signals. I cannot confirm that. My VDR always had strange tuning problems that are caused by mysterious hardware problems (including some time on VDR 1.4.7), so having no signal on DVB-S is not un-typical for my system. 1.4.3 had the problem to restart vdr in such cases, beraking all other recording(*). This restart is not very noticable in the recording. Only some 10sec are missing, similar to an intented directors cut. If one does not watch live via VDR he would not surely notice that there is a problem at all. I also had no issues while experimenting with DVB-T - which typically includes having no signal. ;) So why i had no live image but OSD? Isn't the ARM not required for the OSD? I never had a restart due to EPG scan (at least not directly *), Me too (*) :-) I have to disable EPG scan because i have 3 Cards but only a single LNB! And, the Single-LNB-Patch did still not made its may into the release, so if EPG scan starts after an unpredictable time it will try to switch polarization, what fails and leads to no a signal condition witch is not detected to the EPGscan. So it again and again try to switch to that channel (see log in last mail) instead of skipping it. At least the logfile entries gives that impression. and a missing signal for live viewing never caused more than a black screen. I never had ARM crashes because of signal quality. The crash was detected after i selected a replay, not because of the (EPG)selected channel dead DVB-T. I assume that was the reason for the black screen. Step by step: I saw VDR box was running what should not be at that time. I turned on the TV-set Nothing but a black screen was shown, too no sound. I selected channel 1 (DVB-S, ARD) I saw the program info in the OSD The time was OK, and the Info was current. Went into the OSD VDR menu Restart VDR (not the box!) Nothing changed: Still no live video I selected a reecording Replay starts with image and sound I stopped the replay Now live was displayed including audio! Asking: What exactly happend? Why solves a replay the black screen problem? After that i turned on ssh and grabbed the log i mailed yesterday. Saw that for hours VDR tried to swicth to channel 87, what's DVB-T Found ARM crashed message during the replay phase. Hope it becomes more clearer now? Restarts only happened for me if a recording got no signal. VDR restart did not help. IOW: During a VDR restart the crashed ARM was not detected and the black screeen state not healed. (* I had some times where tuning card 1 to channel X because of EPG scan would cause the recording card 0 to loose signal) Maybe you need the single-LNB patch too? ;-) Rainer---= Vertraulich // // =--ocholl, Kiel, Germany ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB-T card on the move
[EMAIL PROTECTED](Udo Richter) 16.02.08 12:12 Once upon a time Udo Richter shaped the electrons to say... Rainer Zocholl wrote: This unloading leads to ACPI interrupr errors On the VDR console i could see 3 line ACPI disabling interupt This is not an error. If a DVB driver is unloaded, its IRQ is unused and ACPI disables this IRQ line. Ah, thanks. good to know. As soon as the driver gets loaded again, the ACPI IRQ will be enabled again. For me, this is shown in syslog like this: kernel: ACPI: PCI interrupt for device :00:13.0 disabled kernel: saa7146: unregister extension 'budget dvb'. [...] kernel: ACPI: PCI Interrupt :00:13.0[A] - Link [LNKA] - GSI 11 (level, low) - IRQ 11 kernel: saa7146: register extension 'budget dvb'. So that does not explain the problem. Sad ;-( ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to avoid: VPS-Aufnahme beginnt in K�rze
[EMAIL PROTECTED](Klaus Schmidinger) 16.02.08 16:54 vdr:/var/lib/vdr# cat timers.conf | grep -n -e \-S:2000: -e \-S:19 11:1:S19.2E-1-1079-28007:--S:1910:1959:50:7:R: 12:5:S19.2E-1-1079-28006:--S:1930:2014:50:6:E: 13:5:S19.2E-1-1101-28112:--S:2000:2017:50:68:A: 75:5:S19.2E-1-1101-28109:--S:2000:2010:50:7:K: I tried this with VDR 1.5.13 (AFAICS there was no change regarding VPS recordings in vdr.c since 1.4.7) by programming 4 recordings on 2 transponders, all with VPS. I had to increase the VPS margin to have them all within the VPS margin, but the live channel was never switched away. What will happen it there was a third VPS recording already running on a third transponder? BTW: Meanwhile i did not see that switching away again. Does your system have 3 DVB-S cards? You wrote DVT-S, so I'm wondering if this was just a typo. I have 3 FF-DVB-S on one LNB and one DVB-T but i found that the 1350Ghz AMD Duron K7S8XE+ is overlaoded with 3 simlutanions recordings. Too i found that channel hopping on 1.4.7 so noticable slower than 1.4.3 but that may be a DVB-driver problem too as i run a 2.6 kernel now which has a known worser memory performance than 2.4. Too i see a noticable delay/skew between cursor movement and selection. (i press down, the cursor left moves 200ms later to next line, the higlight right moves approc. 300ms delayed.) Can all your DVB-S cards be tuned independent of each other? IIRC you're using the lnb sharing patch, which might interfere here. Ooops.. does VPS (now) cause channel switching as EGP scan? That would not be good because i currently use the unpatched orginal debian/elchi package because baking patches under debian is not very easy to automate. (OK, on vertical are only the garbage programs like RTL+ which do not support VPS and are not worth recording) Rainer lspci -v .. 00:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1 Flags: bus master, medium devsel, latency 64, IRQ 5 Memory at cfff6e00 (32-bit, non-prefetchable) [size=512] 00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) Subsystem: Avermedia Technologies Inc AverMedia AVerTV DVB-T 771 Flags: bus master, medium devsel, latency 64, IRQ 10 Memory at cecfe000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 00:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) Subsystem: Avermedia Technologies Inc AverMedia AVerTV DVB-T 771 Flags: bus master, medium devsel, latency 64, IRQ 10 Memory at cecff000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 00:0b.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1 Flags: bus master, medium devsel, latency 64, IRQ 5 Memory at cfff6c00 (32-bit, non-prefetchable) [size=512] 00:0d.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Siemens/Technotrend/Hauppauge DVB card rev1.3 or rev1.5 Flags: bus master, medium devsel, latency 64, IRQ 5 Memory at cfff6a00 (32-bit, non-prefetchable) [size=512] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Fix primary display in multi FF card/budget card environment
[EMAIL PROTECTED](Malte Forkel) 05.02.08 08:11 So how can i nail this moving DVB-T card to a fixed postition? You might try to blacklist the driver modules used for the cards in /etc/modprobe.d/blacklist and then enter them in /etc/modules in an order of your liking. If you can read German, have a look at http://www.vdr-wiki.de/wiki/index.php/Reihenfolge_der_DVB-Treiber_fest legen. Thanks. does not really help. (See other mail too) Maybe someone is enligthend by this kernel log: 6:31 vdr kernel: Linux agpgart interface v0.102 6:31 vdr kernel: pci_hotplug: PCI Hot Plug PCI Core version: 0.5 6:31 vdr kernel: agpgart: Detected SiS chipset - id:1862 6:31 vdr kernel: agpgart: AGP aperture is 32M @ 0xd000 6:31 vdr kernel: shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 6:31 vdr kernel: Linux video capture interface: v2.00 6:31 vdr kernel: FDC 0 is a post-1991 82077 6:31 vdr kernel: ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10 6:31 vdr kernel: ACPI: PCI Interrupt :00:02.7[C] - Link [LNKC] - GSI 10 (level, low) - IRQ 10 6:31 vdr kernel: input: Power Button (FF) as /class/input/input1 6:31 vdr kernel: ACPI: Power Button (FF) [PWRF] 6:31 vdr kernel: input: Power Button (CM) as /class/input/input2 6:31 vdr kernel: ACPI: Power Button (CM) [PWRB] 6:31 vdr kernel: bttv: driver version 0.9.17 loaded 6:31 vdr kernel: bttv: using 8 buffers with 2080k (520 pages) each for capture 6:31 vdr kernel: intel8x0_measure_ac97_clock: measured 61257 usecs 6:31 vdr kernel: intel8x0: clocking to 48000 6:31 vdr kernel: bttv: Bt8xx card found (0). 6:31 vdr kernel: ACPI: PCI Interrupt :00:0a.0[A] - Link [LNKC] - GSI 10 (level, low) - IRQ 10 6:31 vdr kernel: bttv0: Bt878 (rev 17) at :00:0a.0, irq: 10, latency: 64, mmio: 0xcecfe000 6:31 vdr kernel: bttv0: detected: AVermedia AverTV DVB-T 771 [card=123], PCI subsystem ID is 1461:0771 6:31 vdr kernel: bttv0: using: AVerMedia AVerTV DVB-T 771 [card=123,autodetected] 6:31 vdr kernel: bttv0: tuner absent 6:31 vdr kernel: bttv0: registered device video0 6:31 vdr kernel: bttv0: registered device vbi0 6:31 vdr kernel: bttv0: PLL: 28636363 = 35468950 .. ok 6:31 vdr kernel: bttv0: add subdevice dvb0 6:31 vdr kernel: input: bttv IR (card=123) as /class/input/input3 6:31 vdr kernel: bt878: AUDIO driver version 0.0.0 loaded 6:31 vdr kernel: bt878: Bt878 AUDIO function found (0). 6:31 vdr kernel: ACPI: PCI Interrupt :00:0a.1[A] - Link [LNKC] - GSI 10 (level, low) - IRQ 10 6:31 vdr kernel: bt878_probe: card id=[0x7711461],[ AVermedia AverTV DVB-T 771 ] has DVB functions. 6:31 vdr kernel: bt878(0): Bt878 (rev 17) at 00:0a.1, irq: 10, latency: 64, memory: 0xcecff000 6:31 vdr kernel: input: ImPS/2 Generic Wheel Mouse as /class/input/input4 6:31 vdr kernel: parport_pc 00:0a: reported by Plug and Play ACPI 6:31 vdr kernel: parport0: PC-style at 0x378, irq 7 [PCSPP] 6:31 vdr kernel: DVB: registering new adapter (bttv0) 6:31 vdr kernel: DVB: registering frontend 0 (Zarlink MT352 DVB-T)... 6:31 vdr kernel: Adding 1510068k swap on /dev/sdc6. Priority:-1 extents:1 across:1510068k 6:31 vdr kernel: EXT3 FS on sdc5, internal journal 6:31 vdr kernel: loop: module loaded 6:31 vdr kernel: powernow-k8: Processor cpuid 681 not supported 6:31 vdr kernel: saa7146: register extension 'dvb'. 6:31 vdr kernel: ACPI: PCI Interrupt :00:09.0[A] - Link [LNKB] - GSI 5 (level, low) - IRQ 5 6:31 vdr kernel: saa7146: found saa7146 @ mem e0cc4e00 (revision 1, irq 5) (0x13c2,0x0003). 6:31 vdr kernel: DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-S rev2.X) 6:31 vdr kernel: adapter has MAC addr = 00:d0:5c:20:30:9b 6:31 vdr kernel: dvb-ttpci: gpioirq unknown type=0 len=0 6:31 vdr kernel: dvb-ttpci: info @ card 1: firm f0240009, rtsl b0250018, vid 71010068, app 80002622 6:31 vdr kernel: dvb-ttpci: firmware @ card 1 supports CI link layer interface 6:31 vdr kernel: dvb-ttpci: adac type set to 0 @ card 1 6:31 vdr kernel: saa7146_vv: saa7146 (0): registered device video1 [v4l2] 6:31 vdr kernel: saa7146_vv: saa7146 (0): registered device vbi1 [v4l2] 6:31 vdr kernel: DVB: registering frontend 1 (ST STV0299 DVB-S)... 6:31 vdr kernel: input: DVB on-card IR receiver as /class/input/input5 6:31 vdr kernel: dvb-ttpci: found av7110-0. 6:31 vdr kernel: ACPI: PCI Interrupt :00:0b.0[A] - Link [LNKD] - GSI 5 (level, low) - IRQ 5 6:31 vdr kernel: saa7146: found saa7146 @ mem e0cf0c00 (revision 1, irq 5) (0x13c2,0x0003). 6:31 vdr kernel: DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-S rev2.X) 6:31 vdr kernel: adapter has MAC addr = 00:d0:5c:20:78:9e 6:31 vdr kernel: dvb-ttpci: gpioirq unknown type=0 len=0 6:31 vdr kernel: dvb-ttpci: info @ card 2: firm f0240009, rtsl b0250018, vid 71010068, app 80002622 6:31 vdr kernel: dvb-ttpci: firmware @ card 2 supports CI link layer interface 6:31 vdr kernel: dvb-ttpci: Crystal audio DAC @ card 2 detected 6:31 vdr kernel: saa7146_vv: saa7146 (1): registered device video2 [v4l2] 6:31 vdr kernel: saa7146_vv:
Re: [vdr] DVB-T card on the move
(Halim Sahin) 06.02.08 in /SPAMDETEC:
Hi,
A dirty but working solution is to unload and load the modules in the
right order in startvdr skript.
Thanks, but
I tried it:
The results were very bad.
vdr do not cold start any more
The drivers/module do not seem to like been unloaded and
reloaded in the right order.
This unloading leads to ACPI interrupr errors
On the VDR console i could see 3 line
ACPI disabling interupt
tried using noacpi: do not help.
I really very frustrated as i ran the hard since years
with 1.4.3 without any problem.
(recently the new 500GB sata Samsung HD500 had developed a bad block)
Any help available?
a how-to
Or at least some one reading here? ;-)
Is see only a hardware solution:
Removing the DVB-T card!
I assume all other users will have done that way, as there seems to be
no *working* help anywhere! Atleat non to be found with teh word
i gave google/yahoo.
This patch sems to lead into a desaster (= no dvb found)
vdr:~# diff -Nau /usr/sbin/runvdr runvdr.mod
--- /usr/sbin/runvdr2008-01-14 21:56:11.0 +0100
+++ runvdr.mod 2008-02-14 23:22:35.0 +0100
@@ -19,6 +19,8 @@
MODULES=`lsmod | grep dvb-core | cut -d'[' -f2 | cut -d']' -f1`
[ $MODULES ] MODULES=$MODULES dvb-core
fi
+logger $MODULES
+
}
function set_permissions()
@@ -39,6 +41,8 @@
get_modulenames
else
if [ $MODULES ]; then
+modprobe dvb-ttpci /dev/null 21 #2.4
+modprobe dvb_ttpci /dev/null 21 #2.6
for MODULE in $MODULES; do
modprobe $MODULE /dev/null 21
done
@@ -67,9 +71,28 @@
VDR_ERR=`mktemp -p /tmp vdr-err.XX`
+
+#revolve that senseless automatic PrimaryDVB = 2
+grep -v ^PrimaryDVB /var/lib/vdr/setup.conf $VDR_ERR
+echo PrimaryDVB = 1 $VDR_ERR
+mv $VDR_ERR /var/lib/vdr/setup.conf
+:$VDR_ERR
+
+
get_modulenames
+logger -t runvdrz unload
+unload_dvb_modules
+sleep 2
+logger -t runvdrz unloaed
+lsmod | grep dvb | logger -t runvdrz
+
+logger -t runvdrz load
[ -z $MODULES ] load_dvb_modules
+logger -t runvdrz loadied
+lsmod | grep dvb | logger -t runvdrz
+
+ echo $MODULES | logger -t runvdrzm
if [ $VDSB_WORKAROUND = yes ] [ -x /usr/bin/szap ] ; then
channel=àwk '/^[^:]/ {print NR; exit}' /var/lib/vdr/channels.conf`
@@ -81,6 +104,7 @@
killall szap
fi
+
while (true) do
set_permissions
Feb 15 19:31:15 vdr runvdr: stopping after fatal fail (vdr: warning - cannot
set dumpable: Invalid argument vdr: error while reading
'/var/lib/vdr/setup.conf' vdr: no primary device found - using first device!)
Feb 15 19:32:00 vdr vdr: [4332] no DVB device found
Rainer
--
Transparency International definiert Korruption als
Missbrauch von anvertrauter Macht zum privaten Nutzen oder Vorteil. [...]
Corruption is operationally defined as the misuse of entrusted power for
private gain. [...]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] dvb-ttpci: ARM crashed @ card 1
Hello Just found vdr 1.4.7 running instead of beeing switched off. No audio no live image, but OSD works OK! I can switch between channels, OSD displays the current(!) EPG Info! But no live image/sound! Restarting VDR via OSD does not change anything. But: Starting replaying a record make the TV live angain. But: VDR now states -errornous- dvb-ttpci: ARM crashed @ card 1 how can the OSD work with a crashed ARM? I found: only the antenna signal was bad! (terristrical antenna dismounted long time ago, because no one uses DVB-T ...) Nothing had crashed, no reason to stop recording or to restart VDR (what would not have helped!) Since i upgraded to 1.4.7 ctvdr i have to fiddle every evening on the box to make (em, try to ) it run reliable again- it's annoying and frustrating! What happend to vdr between 1.4.3 and 1.4.7? It seems to have become worser, not better. (ARM crashed i had 6 years ago in the beginningof the VDT with the -broken by design- 1.3 cards, but there only 2.x cards which ran flawlessly with 1.4.3.). Are developpers happy with such mulish(?) behaviour of the software? break down entrirely if there is no antenna signal on one of 4(!) cards. vdr:~# vdr:~# tail /var//log/messages 29:07 vdr vdr: [3721] frontend 0 timed out while tuning to channel 87, tp 762 WTF tuned to channel 87 at this time? (EPG scan, after 5h!) chanel 87 is on DVB-T. DVT-T has no antenna in the moment. Why does VDR have a problem with that state and does not handle ist benign? It forgot to start recordings because EPG scan(!) tunes to a card without antenna! A colleage who tried VDR became almost mad after he plugged in a second DVB-S: vdr contious to restart after a short while! You laugh? He he was not laughing because he already wasted an entire weekingend in swapping cards etc. until he learned that every card in the system MUST have a -good- antenna signal, regardless if the card is used or not... because EPG scan would use every card and that VDR behaves -unexpectable- sick without -good- antenna signals. sevaral hours agao, EPG scan, which was on because of a reinstallation. Why is EPG scan enabled by default? It not needed for work, it ist only a nice to have because 1sec -in words one second- is saved after a program switch until the info is shown. It's not worth the trouble it made to turn it on by default! 29:24 vdr vdr: [3728] channel 7 (MDR FERNSEHEN) event Sat 16.02.2008 01:50-02:30 (VPS: 16.02 01:50) 'Brisant' status 1 29:24 vdr vdr: [3728] channel 7 (MDR FERNSEHEN) event Sat 16.02.2008 02:30-02:45 (VPS: 16.02 02:30) 'Tagesthemen' status 2 30:10 vdr vdr: [3721] frontend 0 timed out while tuning to channel 87, tp 762 30:16 vdr vdr: [3728] channel 7 (MDR FERNSEHEN) event Sat 16.02.2008 02:30-02:45 (VPS: 16.02 02:30) 'Tagesthemen' status 4 31:13 vdr vdr: [3721] frontend 0 timed out while tuning to channel 87, tp 762 32:16 vdr vdr: [3721] frontend 0 timed out while tuning to channel 87, tp 762 33:19 vdr vdr: [3721] frontend 0 timed out while tuning to channel 87, tp 762 34:22 vdr vdr: [3721] frontend 0 timed out while tuning to channel 87, tp 762 35:25 vdr vdr: [3721] frontend 0 timed out while tuning to channel 87, tp 762 Staringting the recording: 41:27 vdr vdr: [4211] loading /var/lib/video.00/11.000_Meter_unter_den_Meeren/Fernsehfilm_Kanada_2006_(Race _to_Mars)/2008-02-09.20.40.50.07.rec//marks.vdr 41:27 vdr vdr: [4238] TS buffer on device 2 thread ended (pid=4211, tid=4238) 41:27 vdr vdr: [4237] buffer stats: 0 (0%) used 41:27 vdr vdr: [4237] receiver on device 2 thread ended (pid=4211, tid=4237) 41:28 vdr vdr: [4240] dvbplayer thread started (pid=4211, tid=4240) 41:28 vdr vdr: [4241] non blocking file reader thread started (pid=4211, tid=4241) 41:28 vdr vdr: [4240] setting audio track to 1 (0) stopped replay after few seconds 41:37 vdr kernel: dvb-ttpci: ARM crashed @ card 1 41:37 vdr kernel: dvb-ttpci: gpioirq unknown type=0 len=0 41:37 vdr kernel: dvb-ttpci: adac type set to 0 @ card 1 41:37 vdr vdr: [4221] frontend 1 lost lock on channel 1, tp 111837 41:37 vdr vdr: [4221] frontend 1 regained lock on channel 1, tp 111837 41:56 vdr vdr: [4222] changing pids of channel 159 from 901+901:902:204 to 701+701:702:204 42:10 vdr vdr: [4241] non blocking file reader thread ended (pid=4211, tid=4241) 42:10 vdr vdr: [4240] dvbplayer thread ended (pid=4211, tid=4240) 42:11 vdr vdr: [4211] switching to channel 1 42:11 vdr vdr: [4211] buffer stats: 0 (0%) used 42:12 vdr vdr: [4211] max. latency time 3 seconds 42:12 vdr vdr: [4243] receiver on device 2 thread started (pid=4211, tid=4243) 42:12 vdr vdr: [4244] TS buffer on device 2 thread started (pid=4211, tid=4244) Rainer---= Vertraulich // // =--ocholl, Kiel, Germany ___ vdr mailing list vdr@linuxtv.org
Re: [vdr] DVB-T card on the move
[EMAIL PROTECTED](Udo Richter) 05.02.08 22:51 Theunis Potgieter wrote: udev rules Any good rules that could be used as a starting point? I thought of doing this with udev, but there are some obstacles for that: First, a DVB device has several device files, not just one. vdr:~# ll /dev/dvb/adapter0/ insgesamt 0 crw-rw 1 root video 212, 1 2008-02-11 20:19 audio0 crw-rw 1 root video 212, 6 2008-02-11 20:19 ca0 crw-rw 1 root video 212, 4 2008-02-11 20:19 demux0 crw-rw 1 root video 212, 5 2008-02-11 20:19 dvr0 crw-rw 1 root video 212, 3 2008-02-11 20:19 frontend0 crw-rw 1 root video 212, 7 2008-02-11 20:19 net0 crw-rw 1 root video 212, 8 2008-02-11 20:19 osd0 crw-rw 1 root video 212, 0 2008-02-11 20:19 video0 vdr:~# vdr:~# ll /dev/dvb/adapter1/ insgesamt 0 crw-rw 1 root video 212, 65 2008-02-11 20:19 audio0 crw-rw 1 root video 212, 70 2008-02-11 20:19 ca0 crw-rw 1 root video 212, 68 2008-02-11 20:19 demux0 crw-rw 1 root video 212, 69 2008-02-11 20:19 dvr0 crw-rw 1 root video 212, 67 2008-02-11 20:19 frontend0 crw-rw 1 root video 212, 71 2008-02-11 20:19 net0 crw-rw 1 root video 212, 72 2008-02-11 20:19 osd0 crw-rw 1 root video 212, 64 2008-02-11 20:19 video0 vdr:~# ll /dev/dvb/adapter3/ insgesamt 0 crw-rw 1 root video 212, 196 2008-02-11 20:42 demux0 crw-rw 1 root video 212, 197 2008-02-11 20:42 dvr0 crw-rw 1 root video 212, 195 2008-02-11 20:42 frontend0 crw-rw 1 root video 212, 199 2008-02-11 20:42 net0 And second, the usual trick to add a custom name as symlink doesn't work since VDR only accepts /dev/dvb/adapterX/, so /dev/dvb/myprimarycard/ is out. In setup.conf there is a variable: vdr:~# grep Prim /var/lib/vdr/setup.conf PrimaryDVB = 1 PrimaryLimit = 0 (PrimaryLimit seems to have no sense anymore?) What's the problem of a string there: PrimaryDVB = /dev/dvb/myprimarycard/ Currently there is stored where the last time the first FF card was found, what is not allways working good vdr:~# dmesg | grep frontend DVB: registering frontend 0 (Zarlink MT352 DVB-T)... DVB: registering frontend 1 (ST STV0299 DVB-S)... DVB: registering frontend 2 (ST STV0299 DVB-S)... DVB: registering frontend 3 (ST STV0299 DVB-S)... will lead to PrimaryDVB = 2 After fidling arround i could manage (somettimes) to get: vdr:~# dmesg | grep frontend DVB: registering frontend 0 (ST STV0299 DVB-S)... DVB: registering frontend 1 (ST STV0299 DVB-S)... DVB: registering frontend 2 (ST STV0299 DVB-S)... DVB: registering frontend 3 (Zarlink MT352 DVB-T)... Wow! but the box does not work anymore...no video, no audio, no OSD. PrimaryDVB = 2 now points to frontend 1 where no TV/Sound hardware is connected. So this automatic does not really work, and makes configuration more complicate. (If *i* said: use PrimaryDVB = 2, the box must do. If this is wrong, VDR could/should issue a warning, but not change the recommended PrimaryDVB. It would be easier if there could be a symlink be used instead/addition to the single digit. Remember the history: This PrimaryDVB = 2 stems from a time, when there were only badly working FF cards (with severe(!)hardware bugs). No budgets, no DVB-T to be mixed because not supported or not existing! A card found at slot1 stays at the index... But today? With udev? Why not use both? (to be compatible) If 1 or 2 Digits than old else take as device path. Rainer---= Vertraulich // // =--ocholl, Kiel, Germany ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Wakeup methods
[EMAIL PROTECTED](Kartsa) 10.02.08 10:37 What different wakeupmethods are there? I've built a few vdr boxes and I've been forced to use different motherboards and they do not all work the same. I've used nvram-wakeup on some and acpi on others when nvram-wakeup has not worked. Now I have Biostar 945GZ 775 SE with which I'm having trouble in starting on timers. What problems? Be spezific. What methods are people using with VDR? IMHO nvram is obsolete for modern boards (not older than 6..7 years) My first attempt would always be acpi! Pay attention to the noted booby traps! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Wakeup methods
[EMAIL PROTECTED](Lars Bläser) 10.02.08 14:59 you could use the WOL feature of the system the vdr sends the wakeup time to a system thats always on (linux router?) and this machine sends a WOL packet to your vdr http://www.vdr-portal.de/board/thread.php?postid=694894 (-babelfish) WOL needs more standby power than the simple RTC! You need power for LAN switch too. The second continously running PC wastes power too. As more componentes are involved as more can/will break. It had never been long term successful to correct a broken software with a hardware patch. use ACPI wakeup. Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Old schedule / old timers
Hello after upgrading from 1.4.3 to 1.4.5 i found that the schedule does not contain any old events. The current event is marked, but it is always the top of the list. What's the sense of tagging the current, when it's always at the top line and can't be scrolled back? That is very annoying because i sometimes found a programm worth to be timed, but the schedule entry is not available anymore. Too, long time ago one time timers were not deleted automatically. That has the advantage that if i found that one time worth to be recorded again, it was easy by editing that old used one time timer. Manually deleting the superflous used timers was much easier than to wait for EPG to show that event in future. How i can, user, select this featuers? - EPG history (at least) 4 hours, 1 day or 2 days back - Manually delete one timer timers/delete after 7 days/4 weeks Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
How to avoid: VPS-Aufnahme beginnt in K�rze
Hello after upgrading from 1.4.3 to 1.4.5 i am sometimes kicked off the live view with warning VPS-Aufnahme beginnt in Kürze I can switch back to channel i want to see, but not for long. I have 3 FF cards so usually there would be a free card to get the VPS signal. After the VPS recording has started, the card seems to be free. I rember that at 1.4.3 a short discussion occurs. One said: That the good way, simply don't use VPS the other said: I have a patch, the only disadvantage: Your screen will blank for fractions of a second at some/every start of recording. Of cause only the second solution would be the least annoying, but obvioulsy, VDR choose the non-user-compatible way? :-( What do have to do to avoid this annoying card locking in the VPS-margin? (See below only 2 transponders are involved, the system has 3(!) DVT-S FF cards.) 58:03 : [3595] timer 13 (16 2000-2017 VPS 'A') entered VPS margin 58:04 : [3595] switching to channel 16 58:05 : [3754] channel 1 (Das Erste) event Son 10.02.2008 19:20-20:00 (VPS: 10.02 19:20) 'Weltspiegel' status 1 58:05 : [3595] info: VPS-Aufnahme beginnt in Kürze! 58:05 : [3754] channel 10 (SWR Fernsehen BW) event Son 10.02.2008 19:58-20:00 (VPS: 10.02 19:58) 'Baden-Württemberg Wetter' status 4 58:05 : [3754] channel 1 (Das Erste) event Son 10.02.2008 20:00-20:15 (VPS: 10.02 20:00) 'Tagesschau' status 2 58:07 : [3595] timer 75 (18 2000-2010 VPS 'K') entered VPS margin 58:18 : [3754] channel 12 (hr-fernsehen) event Son 10.02.2008 19:58-20:00 (VPS: 10.02 19:58) 'hessenschauwetter' status 4 58:20 : [3595] switching to channel 5 58:29 : [3595] switching to channel 16 58:30 : [3595] info: VPS-Aufnahme beginnt in Kürze! 58:52 : [3595] switching to channel 5 58:58 : [3595] switching to channel 15 59:00 : [3595] timer 11 (3 1910-1959 'R') stop 59:01 : [3595] switching to channel 16 59:01 : [3595] info: VPS-Aufnahme beginnt in Kürze! vdr:/var/lib/vdr# cat timers.conf | grep -n -e \-S:2000: -e \-S:19 11:1:S19.2E-1-1079-28007:--S:1910:1959:50:7:R: 12:5:S19.2E-1-1079-28006:--S:1930:2014:50:6:E: 13:5:S19.2E-1-1101-28112:--S:2000:2017:50:68:A: 75:5:S19.2E-1-1101-28109:--S:2000:2010:50:7:K: ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB-T card on the move
(Halim Sahin) 06.02.08 in /SPAMDETEC:
Hi,
A dirty but working solution is to unload and load the modules in the
right order in startvdr skript.
What is the right order?
How do i know which modules to load at all/at least?
It seems to be impossible to move the Zarlink away from frontend 0,
but after i upgrade VDR (debian) i have the ugly state:
picture and sound are coming of the right card (as frontend 1...)
but i don't have no visible OSD!
(LIRC works, control plugin shows the OSD info on port 2002,
but not the OSD)
I can't find any hint where to turn screws,
it's very frustrating!
BTW:
What does the 2 mean in:
Feb 10 22:59:24 vdr vdr: [3621] setting primary device to 2
Frontend 2
/dev/adapther2
no, it seems to be frontend 1
Why isit nummbered 2?
vdr:~# lsmod | awk '/^dvb_core/ {gsub(/,/,\n, $4); print $4}'
budget_ci
budget_core
dvb_ttpci
stv0299
dvb_bt8xx
dst_ca
dst
or51211
lgdt330x
vdr:~# dmesg | grep fronte
DVB: registering frontend 0 (Zarlink MT352 DVB-T)...
DVB: registering frontend 1 (ST STV0299 DVB-S)...
DVB: registering frontend 2 (ST STV0299 DVB-S)...
DVB: registering frontend 3 (ST STV0299 DVB-S)...
vdr:~# lsmod | grep ^dvb_core
dvb_core 75688 9
budget_ci,budget_core,dvb_ttpci,stv0299,dvb_bt8xx,dst_ca,dst,or51211,lgdt330x
vdr:~# dmesg | grep frontend
DVB: registering frontend 0 (Zarlink MT352 DVB-T)...
DVB: registering frontend 1 (ST STV0299 DVB-S)...
DVB: registering frontend 2 (ST STV0299 DVB-S)...
DVB: registering frontend 3 (ST STV0299 DVB-S)...
# cat /etc/modules
...
dvb_ttpci
stv0299
budget_ci
dvb_bt8xx
lgdt330x
or51211
dst
dst_ca
bttv
vdr:~# cat /etc/hotplug/blacklist.d/vdr
dvb_core
dvb_ttpci
budget_core
budget_ci
dvb_bt8xx
stv0299
lgdt330x
or51211
dst
dst_ca
bttv
cat /etc/modprobe.d/blacklist
#don't load the dvb drivers automatically
blacklist dvb_core
blacklist budget_core
blacklist budget_ci
blacklist dvb_ttpci
blacklist b2c2_flexcop_pci
blacklist stv0299
blacklist dvb_ttpci
blacklist lgdt330x
blacklist or51211
blacklist dst
blacklist dst_ca
blacklist dvb_bt8xx
blacklist mt352
blacklist stv0299
blacklist bttv
vdr 2.6.23x2 #2 SMP PREEMPT Sat Oct 20 03:08:47 CEST 2007 i686 GNU/Linux
vdr:~# lsmod | awk '/^dvb_core/ {gsub(/,/,\n, $4); print $4}'
dvb_ttpci
stv0299
dvb_bt8xx
dst_ca
dst
or51211
lgdt330x
vdr:~# modprobe dvb-ttpci
vdr:~# lsmod | awk '/^dvb_core/ {gsub(/,/,\n, $4); print $4}'
dvb_ttpci
stv0299
c't VDR: 1.4.7-4ctvdr1
Kernel : 2.6.23x2
Patches:
--
liemikuutio
jumpplay
subtitles-ttxtsubs
audioindexer
iptv
disableDoubleEpgEntrys
noepg
wareagle-icons
rotor
yaepg
sourcecaps
graphtft-0.1
cuttime
Plugins (APIVERSION 1.4.5):
( N = Native Plugin )
( ! = Falscher Patchlevel )
( - = Deaktiviert )
--
vdr-plugin-autotimeredit (0.1.8-19)
vdr-plugin-console (0.6.0-33)
vdr-plugin-control (0.0.2a-33)
vdr-plugin-epgsearch (0.9.24~beta3-5) conflictcheckonly
vdr-plugin-epgsearch (0.9.24~beta3-5)
vdr-plugin-examples (1.4.7-4ctvdr1) hello
vdr-plugin-examples (1.4.7-4ctvdr1) osddemo
vdr-plugin-examples (1.4.7-4ctvdr1) skincurses
vdr-plugin-examples (1.4.7-4ctvdr1) status
vdr-plugin-examples (1.4.7-4ctvdr1) svccli
vdr-plugin-examples (1.4.7-4ctvdr1) svcsvr
vdr-plugin-examples (1.4.7-4ctvdr1) svdrpdemo
vdr-plugin-femon (1.1.4-1)
vdr-plugin-osdpip (0.0.8-30)
vdr-plugin-osdteletext (0.5.1-31)
vdr-plugin-sky (1.4.7-4ctvdr1)
vdr-plugin-undelete (0.0.6-20)
Addon-Packages:
--
vdr-addon-acpiwakeup (0.0.6)
vdr-addon-noad (0.6.0-8)
vdr-addon-tvmovie2vdr (0.5.14-1)
vdr-genindex (0.1.3-1)
vdr-xpmlogos (0.0.1-3)
Rainer
--
Transparency International definiert Korruption als
Missbrauch von anvertrauter Macht zum privaten Nutzen oder Vorteil. [...]
Corruption is operationally defined as the misuse of entrusted power for
private gain. [...]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB-T card on the move
[EMAIL PROTECTED](serge pecher) 07.02.08 00:23 For who knows french, there is an interresting thread about udev on the dvbkivabien forum. I did use it to have my nexus always as primary device http://dvbkivabien2.info/viewtopic.php?f=21t=11255 Vous devez tre inscrit et connect pour pouvoir consulter le contenu de ce forum. I assume in english this would be translated as forget it :-( Not at all, you just need to register ! Yes, i understand french but: I don't register just to read something. What for should it be good? Too that noread locks search engines out. Why should i want to write to a forum when my posting can't be found by others with the same problem? Thanks, anyway. Nice try. Maybe you can forward the data you think which would solve the problem. TIA. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB-T card on the move
[EMAIL PROTECTED](Malte Forkel) 05.02.08 08:11
So how can i nail this moving DVB-T card to a fixed postition?
You might try to blacklist the driver modules used for the cards in
/etc/modprobe.d/blacklist and then enter them in /etc/modules in an
order of your liking. If you can read German, have a look at
http://www.vdr-wiki.de/wiki/index.php/Reihenfolge_der_DVB-Treiber_fest
legen.
Tried hacking blacklist
After reboot i got:
vdr:~# dmesg |grep -i front
DVB: registering frontend 0 (Zarlink MT352 DVB-T)...
DVB: registering frontend 1 (ST STV0299 DVB-S)...
DVB: registering frontend 2 (ST STV0299 DVB-S)...
DVB: registering frontend 3 (ST STV0299 DVB-S)...
that's stable but not really what i want ;-)
BTW:
Sometimes i got the note recording starts in 5 minutes
and my livs display is switched to that transponder.
I can only zapp betwen the channles on this transponder
if i switch the transponder, it is tunned back after a few seconds.
Is that caused by that bad hardware handling of linux?
vdr:~# lsmod |awk '/^dvb_core/ {i=split($4, arr, /,/); for (;i1;i--) printf
%s ,arr[i];print arr[1]}'
lgdt330x or51211 dst dst_ca dvb_bt8xx stv0299 dvb_ttpci budget_core budget_ci
vdr:~#
vdr:~#
vdr:~# lsmod
Module Size Used by
ipv6 243364 18
ac 6660 0
battery13320 0
lirc_serial15508 1
lirc_dev 15236 1 lirc_serial
aoe26144 0
budget_ci 18948 0
budget_core12164 1 budget_ci
tda1004x 15364 1 budget_ci
dvb_ttpci 94152 50
lnbp21 3328 2 budget_ci,dvb_ttpci
l64781 7812 1 dvb_ttpci
saa7146_vv 46464 1 dvb_ttpci
saa714619848 4 budget_ci,budget_core,dvb_ttpci,saa7146_vv
ves1820 7300 1 dvb_ttpci
tda8083 6788 1 dvb_ttpci
sp8870 7820 1 dvb_ttpci
stv0297 8192 2 budget_ci,dvb_ttpci
ves1x93 7300 1 dvb_ttpci
ttpci_eeprom3584 2 budget_core,dvb_ttpci
stv029910888 2 budget_ci,dvb_ttpci
hwmon_vid 3968 0
k8temp 6656 0
eeprom 8208 0
i2c_nforce2 7424 0
cpufreq_ondemand9356 0
freq_table 6432 1 cpufreq_ondemand
loop 18436 0
tsdev 9280 0
dvb_bt8xx 15876 2
nxt6000 8068 1 dvb_bt8xx
mt352 7172 1 dvb_bt8xx
dvb_pll11396 1 dvb_bt8xx
sp887x 8068 1 dvb_bt8xx
dst_ca 13952 1 dvb_bt8xx
dst28040 2 dvb_bt8xx,dst_ca
or51211 8836 1 dvb_bt8xx
zl10353 7048 1 dvb_bt8xx
lgdt330x9220 1 dvb_bt8xx
dvb_core 75688 9
budget_ci,budget_core,dvb_ttpci,stv0299,dvb_bt8xx,dst_ca,dst,or51211,lgdt330x
bt878 12008 2 dvb_bt8xx,dst
cx24110 8580 1 dvb_bt8xx
parport_pc 35620 0
parport35528 1 parport_pc
bttv 168948 2 dvb_bt8xx,bt878
video_buf 24708 2 saa7146_vv,bttv
firmware_class 10752 8
budget_ci,tda1004x,dvb_ttpci,sp8870,dvb_bt8xx,sp887x,or51211,bttv
ir_common 35204 2 budget_ci,bttv
compat_ioctl32 2432 1 bttv
i2c_algo_bit7044 1 bttv
psmouse37520 0
btcx_risc 5896 1 bttv
tveeprom 16144 1 bttv
i2c_core 24832 28
budget_ci,budget_core,tda1004x,dvb_ttpci,lnbp21,l64781,ves1820,tda8083,sp8870
,stv0297,ves1x93,ttpci_eeprom,stv0299,eeprom,i2c_nforce2,dvb_bt8xx,nxt6000,mt
352,dvb_pll,sp887x,dst,or51211,zl10353,lgdt330x,cx24110,bttv,i2c_algo_bit,tve
eprom
snd_intel8x0 33180 0
button 9360 0
snd_ac97_codec 92192 1 snd_intel8x0
serio_raw 7812 0
ac97_bus3456 1 snd_ac97_codec
videodev 28032 2 saa7146_vv,bttv
floppy 55908 0
v4l2_common17792 3 saa7146_vv,bttv,videodev
snd_pcm73476 2 snd_intel8x0,snd_ac97_codec
snd_timer 22404 1 snd_pcm
snd50020 4 snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer
soundcore 9056 1 snd
snd_page_alloc 11272 2 snd_intel8x0,snd_pcm
rtc13848 0
v4l1_compat13572 3 saa7146_vv,bttv,videodev
shpchp 32276 0
pci_hotplug29856 1 shpchp
sis_agp10244 1
agpgart32972 1 sis_agp
evdev 10624 0
ext3 127112 5
jbd68276 1 ext3
dm_mirror 23168 0
dm_snapshot18088 0
dm_mod 54208 2 dm_mirror,dm_snapshot
generic 5892 0 [permanent]
sd_mod 28672 8
sis551313192 0 [permanent]
ide_core
Re: [vdr] DVB-T card on the move
[EMAIL PROTECTED](serge pecher) 06.02.08 17:39 Once upon a time serge pecher shaped the electrons to say... For who knows french, there is an interresting thread about udev on the dvbkivabien forum. I did use it to have my nexus always as primary device http://dvbkivabien2.info/viewtopic.php?f=21t=11255 Vous devez tre inscrit et connect pour pouvoir consulter le contenu de ce forum. I assume in english this would be translated as forget it :-( ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB-T card on the move
[EMAIL PROTECTED](Malte Forkel) 05.02.08 08:11
So how can i nail this moving DVB-T card to a fixed postition?
You might try to blacklist the driver modules used for the cards in
/etc/modprobe.d/blacklist and then enter them in /etc/modules in an
order of your liking. If you can read German, have a look at
http://www.vdr-wiki.de/wiki/index.php/Reihenfolge_der_DVB-Treiber_fest
legen.
Good luck, Malte
Thanks. the link sounds good, and can era german (and sometimes
understand it ;-)
I too had funny effect with:
RemotePlugin Mplayer
because of that move.
I ran 1.4.3 in
http://www.vdr-portal.de/board/thread.php?postid=479909#post479909
is stated that vdr_1.4.0-1ctvdr2_i386 had fixed the problem.
They recommand to hack /usr/sbin/runvdr
function get_modulenames()
{
if [ $KVERS_2_6 ]; then
MODULES=`lsmod | awk '/^dvb_core/ {gsub(/,/,\n, $4); print $4}' | tac`
[ $MODULES ] MODULES=$MODULES dvb_core
else
MODULES=`lsmod | grep dvb-core | cut -d'[' -f2 | cut -d']' -f1`
[ $MODULES ] MODULES=$MODULES dvb-core
fi
}
RAINER---= Vertraulich
//
//
=--ocholl, Kiel, Germany
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB-T card on the move
[EMAIL PROTECTED](Theunis Potgieter) 05.02.08 06:13 udev rules Yes, i know ;-) can i pin the card to the MAC address like any other network card? If how? Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] DVB-T card on the move
Hello for years i was running VDR 1.4.3. Now i felt forced to use ctvdr and 1.4.7 with a Linux 2.6.23x2 #2 SMP PREEMPT on a Main Board: K7S8XE+ AMI BIOS P1.70 (04/27/2004) and an AMD Duron(tm) 1350MHz (under clocked from 1500) with 512MB RAM i found this miracle(?): The systen has 4 cards: vdr:~# dmesg | grep -i frontend DVB: registering frontend 0 (Zarlink MT352 DVB-T)... DVB: registering frontend 1 (ST STV0299 DVB-S)... DVB: registering frontend 2 (ST STV0299 DVB-S)... DVB: registering frontend 3 (ST STV0299 DVB-S)... with setup.conf PrimaryDVB = 2 i got sound and live screen After a slight (benign) change reboot i have no live image and no sound anymore. Panic! What happend? vdr:~# dmesg | grep front DVB: registering frontend 0 (ST STV0299 DVB-S)... DVB: registering frontend 1 (ST STV0299 DVB-S)... DVB: registering frontend 2 (ST STV0299 DVB-S)... DVB: registering frontend 3 (Zarlink MT352 DVB-T)... Mystery... another warm reboot without any change: vdr:~# dmesg | grep front DVB: registering frontend 0 (ST STV0299 DVB-S)... DVB: registering frontend 1 (Zarlink MT352 DVB-T)... DVB: registering frontend 2 (ST STV0299 DVB-S)... DVB: registering frontend 3 (ST STV0299 DVB-S)... And again: vdr:~# dmesg | grep front DVB: registering frontend 0 (ST STV0299 DVB-S)... DVB: registering frontend 1 (ST STV0299 DVB-S)... DVB: registering frontend 2 (ST STV0299 DVB-S)... DVB: registering frontend 3 (Zarlink MT352 DVB-T)... vdr:~# lspci 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 746 Host (rev 10) 00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SG86C202 00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS964 [MuTIOL Media IO] (rev 36) 00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev 01) 00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0) 00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) 00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) 00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) 00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller 00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 90) 00:05.0 RAID bus controller: Silicon Integrated Systems [SiS] RAID bus controller 180 SATA/PATA [SiS] (rev 01) 00:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 00:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev11) 00:0b.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 00:0d.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400/G450 (rev 85) vdr:~# So how can i nail this moving DVB-T card to a fixed postition? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PANIC: watchdog timer expired - exiting
[EMAIL PROTECTED](Klaus Schmidinger) 02.12.07 14:47 On 12/02/07 14:34, Darren Salt wrote: I demand that Klaus Schmidinger may or may not have written... [snip] While testing this, I found that on my system the monotonic clock only has a resolution of 4000250 ns (about 4 ms), which in your original patch would have caused VDR not to use the monotonic clock. That suggests that your kernel is built with HZ=250 (CONFIG_HZ in /proc/config.gz). I'm running the default SUSE 10.2 kernel. Are there actually systems that have a 1 ms resolution? Any with HZ=1000, I expect :-) Ok, I see. I'll make it a 5 ms limit then, to allow default kernels to work. http://tldp.org/HOWTO/IO-Port-Programming-4.html For delays of under about 50 milliseconds (depending on the speed of your processor and machine, and the system load), giving up the CPU takes too much time, because the Linux scheduler (for the x86 architecture) usually takes at least about 10-30 milliseconds before it returns control to your process. Due to this, in small delays, usleep(3) usually delays somewhat more than the amount that you specify in the parameters, and at least about 10 ms. So i assume it's not just a problem of the ticks intervall. Too it might be required to differ between wall clock and time delays. VDR is (IMOH) a strong(hard?) real time application, not just another file manager with a video interface ;-) I wonder why linux high resolution timer can't be used for timeout and delay timings. I assume that those timer uses CPU/ACPI counters and not the good old interrupt ticker which origins in a time when a tick faster than 10ms would allocate the entire CPU and were never intented to be used in real time applications. See http://www.opengroup.org/rtforum/jan2002/slides/linux/mehaffey.pdf etc. So 10ms sleep would always be a 10ms sleep. not a 0ms or 5ms or 15ms or 20ms, depending when the last tick occured and whichintervall was choosen. Another question: What if the CPU clock is modulated to save power? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Not good behaviour from vdr
[EMAIL PROTECTED](VDR User) 30.09.07 13:37 On 9/30/07, Jouni Karvo [EMAIL PROTECTED] wrote: VDR User wrote: I like these ideas... NO SIGNAL image in recording during no signal. Or that if no signal then no writing to disk. And a warning in the log about a possible incomplete recording cuz of lost signal + identified in recordings menu by a special char like ? maybe. I do not like the idea of an NO SIGNAL image. I don't want any subliminal messages for short losses of video. In any normal recording currently you would not realize that there is missing anything (except(maybe): music). So a no signal combined with Signal information would be helpful. If you want to cut it no adds will be able to find these breaks. Currently no adds will not detect the interruptions! No chance! If you really want to pad the video, then either using the last frame of a black picture should be enough. That's not exactly subliminal and it could easily be optional. Some guys will prefer it and some won't. For example it would be an easy indicator to identify what exact time in the recording the loss occured. Once uppon a time i wondered why some days some recordings were broken resp. where not done. After weeks i realized that this happen only when an recording using the DVB-T card. That was caused because someone removed the terristic anntenna: We ara all using sat ;-) If the recordings would consist of no stream and zero signal level or massbe BER the problem would have been obious. I see no bad reason these options can't be added, and no good reason they shouldn't be. ACK. Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Not good behaviour from vdr
[EMAIL PROTECTED](Ludwig Nussel) 01.10.07 14:28 Klaus Schmidinger wrote: On 09/29/07 09:30, Timothy D. Lenz wrote: I don't know about it restarting. The crashing with loss of signal is suposed to be a safe guard against creating blank recordings. Seems like a bad idea to me to. Just delete the bad recordings, don't crash the system. Well, let me just comment on the nomenclature here ;-) When VDR does an emergency exit because there is no video data for a while, this is a *controlled* action that shall allow the driver to be reloaded. Full featured cards sometimes have the problem that they completely lock up, That's long time ago and IMHO only a problem on unmodded v1.3 cards or not perfect ARM firmware at that time, 3 or more years ago (At least i got rid of the problem by -expensive- upgrading to 2.0 cards. (Someone interessted in 1.3 cards, 220E each?)). (see http://vdr-wiki.de/wiki/index.php/SpannungsMod). So it maybe only a problem for the unlucky owers of unmodded 1.3. In a multi card system it would be possible to check if other cards are are having a stream and not to reboot while they are successfully recording. In a single card system a check if other recordings (on the same transponder) are working would be a strong indication that a reset would not solve the problem and would make the problem worse my breaking the other recording too. If no other recording is running a tuning attempt to a well known good working transponder/programm would allow to determine a broken driver/card from a missing antena oder broken hardware, where a reboot will usally not help. and reloading the driver fixes this. I wonder whether reloading modules is still an appropriate action. That hard way has only historical reasons AFAIK. Once there was a time, when the hardware(!) tends to hang. (ARM bugs, bad power supply filtering, design errors of the card) Nowadays it's possible for example to bind/unbind drivers to/from specific devices. Ie if you have multiple dvb-ttpci cards it should be possible to reset a specific one. Maybe the PCI powermanagement can used to powerdown the one hanging card. Maybe it would even be possible to implement some kind of reset ioctl in the kernel drivers so vdr doesn't need to rely on external scripts at all. It would be very help full. The first big step would be if it would be possible to suppress the restart process finally issued by VDR to reanimate dead cards. At least users of 2.0 cards will be made very happy on bad weather conditions! (Which usually cause VDR to restart/reboot making replay implassinble too. Too it is not possible to quickly dectivate the time for that recording: 60sec are too short to trigger that window (may i assume VDR blocks RC command processing during detecting a broken stream?)) Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Building debain plugin packages
Hello Tobias made real help pages at e-tobi.net. Thanks a lot. Really very helpful! Now i am trying to make my next VDR using debian packaging. I can't use precompiled vdr because i need the lnbsharing patch. But when i apply that patch, all binary plugins are rejected. That's OK. Building vdr it self works so far, but. But: How should a compile all these tons of plugins? Is there somewhere a list (like patches) or script or have i to download each plugin, complie it, install it and than do the next as shown in the script? Is that the intended way to go? Any hints? The script debian/vdraptrefresh seems to be something but it ia actually not... Currenty i use these steps to make a debian package according to http://www.e-tobi.net/blog/articles/2004/09/21/das-vdr-quelltextpaket vdr:~# cd /usr/src/vdr vdr:/usr/src/vdr# cat ../vdrgetsources #!/bin/sh # last version. VER=1.4.7 # make sure paths exists. mkdir --parents /usr/src/vdr mkdir --parents /usr/src/vdr-plugin-mp3 # remove all old files cd /usr/src/vdr rm ver_$VDR*.dsc # get new files apt-get source vdr apt-get build-dep vdr # get vdr-plugin (???---) cd /usr/src/vdr-plugin-mp3 apt-get source vdr-plugin-mp3 apt-get build-dep vdr-plugin-mp3 # Expand packages cd /usr/src/vdr for i in $(ls -1 vdr_$VER*dsc) do dpkg-source -x $i done # compile vdr cd /usr/src/vdr/vdr-$VER #check and display new patches if any. diff -Nau ../../00list.ref ./debian/patches/00list ../../00list.new cat ../../00list.new #generate patch list patch with my patch selection diff -Nau ../../00list.ref ../../00list ../../00list.diff cat ../../00list.diff | patch ./debian/patches/00list #exit dpkg-buildpackage -tc # show rejected files if patches failed find . -name *.rej # store the package data in the local repository cd /usr/src/vdr mkdir --parents /var/lib/vdr-repository rsync -p *.deb /var/lib/vdr-repository/ # bind the package cd /var/lib/vdr-repository/ echo Archive: stable Component: main Origin: Meins! Label: Mein persoenliches Debian repository $(date --iso=seconds) Architecture: i386 Release dpkg-scanpackages ./ /dev/null | gzip -9c Packages.gz #patch /etc/apt/sources echo deb file:/var/lib/vdr-repository ./ ls -al vdr*.deb #install the package (may faill die to wrong plugins! echo dpkg -i vdr-dev_$VER.deb #EOF ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Thunderstorm over Munich
[EMAIL PROTECTED](Stefan Taferner) 28.05.07 14:22 Once upon a time Stefan Taferner shaped the electrons to say... On Monday 28 May 2007 10:38:50 Marko Myllymaa wrote: On Sun, 27 May 2007, Andrew Herron wrote: I have to say that I agree with both of you... constructive criticism is best! As a quiet 'user' of vdr, for about a year, I agree with the sentiments in Martin's post. It is very frustrating that vdr exits when reception is less than perfect. I personally would prefer it if vdr announced on screen that there was a bad signal condition. This is particularly frustrating if at the time you are just watching a perfectly good recording. I agree, with all. I would suggest to handle viewing recording or running a plugin (dvd plugin or mp3/mplayer etc.) would get a priority, for example 90. Then every recording that has lower priority would not cause emergency exits, no matter what. But if recording has higher priority, it can cause restarts. Hmm... IMO it is good that vdr tries to fix the recording problem with a restart. I think that's historical When VDR (and me?) were young, there were tons of problems with the driver, with firmware, with multithreading, reentrance and real hardware bugs etc. (remember: the drivers are mostly based on reverse engineerings! And the early baords tent to hang causd by bad Vcc filtering and desgin errors.) At that time it was the only way to reload the driver by resetting the entire box, because it was impossible to determine where the problem actually was. Today i would ask: Why can't VDR read out the signal (strength/quality) information? As long as there is a bit level, there is no reason to reboot, tho no video stream might be decodable. If I have the choice between a corrupted recording and being interrupted by a restart, I would choose the restart. The recording is corrupt anyway. And if you have more than one card, and record more than one transponder at the same time both(!) recordings will be broken tho only one transponders had problems... Not really an option, or? At least me would prefere to have only 1 broken recording instead of 4...i would not choose to restart. We had this thread all 12/18 month the last 5 years ;-) (Thunder storms in summer and snow in winter) Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Still problem with ASUS Punidt-R P4R8L2 and nvram-wakeup
[EMAIL PROTECTED](Philipp Flesch) 18.12.06 09:11 Hi! Although I tried to use guess-helper to get a working configfile nvram-wakeup failed :-( Setting a time only crashes the systemtime... I also tried directisa Any other ideas? Have you tried the acpi way? pwroff: ... WAKETIME=`date -d 1970-01-01 UTC $1 sec -5 min +%Y-%m-%d %H:%M:%S` echo $WAKETIME /proc/acpi/alarm ... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Switch box (was: Re: [vdr] Doubling my available VDR disk space without cost or loss of convenience.)
[EMAIL PROTECTED](Norbert Goebel) 13.09.06 18:21 Matthias Schniedermeyer wrote: Not excatly. I would call it semy-online-storage. Normaly the HDDs are switched off. But as they are connected to USB-Power-Switches they can be switched on/off automatically by the computer.(*) Hi, I just got interested when I read USB-Power-Switches and the possibility to switch on/off the hdds automatically by the computer. As a quick google search only showed rubbish on the first 3 pages searching for usb power switches it would be nice if you could post some links to such products. Those devices are relatively expensive. Typically 50E per Plug. I found that combo USB Devices with firewire and USB often allows spindown using sdparm. (If found *no* USB-Only 3,5 external case which supports spin down!) If you insist on a power switch try: http://www.heise.de/ct/ftp/projekte/netz-schalter/ Too you will find such devices at lindy http://www.heise.de/kiosk/archiv/ct/2002/17/84 Cheaper would be bying RF/IR-remote switches like Aldi offen for 15 Euro for 4(!) and modding the transmitter to be used by a PC. Or simly move to the USA. There energy is so cheap (thank to brain dead George Warmonger Bush) it would make no ense to waste time in optiimize power consumption... Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
