vdr November 2005

vdr@linuxtv.org

144 participants
178 discussions

Patch for timeline-0.9.0 (vdr-1.3.23)
by cwieninger＠gmx.de 12 Dec '05

12 Dec '05

Hi, I've made a small patch for timeline-0.9.0 to make it work with vdr- 1.3.23 (I hope Jürgen doesn't mind, but its one of the most important plugins for me). BR, Christian Wieninger Der folgende Teil dieser Nachricht enthält einen Anhang im sogenannten Internet MIME Nachrichtenformat. Wenn Sie Pegasus Mail oder ein beliebiges anderes MIME-kompatibles Email-System verwenden, sollte Sie den Anhang mit Ihrem Email-System speichern oder anzeigen können. Anderenfalls fragen Sie Ihren Administrator. The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- Datei Information/File information ----------- Datei/File: timeline-0.9.0-vdr-1.3.23-patch.diff Datum/Date: 25 Mar 2005, 11:07 Größe/Size: 3684 bytes. Typ/Type: Unbekannt

4 8

noad bugs...
by Jouni Karvo 04 Dec '05

04 Dec '05

hi, I use the current Noad version and have experienced a couple of bugs. Here the first one: If another noad is started before the previous ends, the earlier seems to segfault: Sep 21 21:25:00 vdr noad[20105]: noad called with 'before' and online=1 and liverecording is no Sep 21 21:25:00 vdr noad[20105]: nothing to do yet Sep 21 21:25:52 vdr noad[15366]: noad aborted by signal Segmentation fault Sep 21 21:25:52 vdr noad[15366]: [bt] Execution path: Sep 21 21:25:52 vdr noad[15366]: [bt] /usr/local/bin/noad [0x805b223] Sep 21 21:25:52 vdr noad[15366]: [bt] /usr/local/bin/noad [0x8057a47] Sep 21 21:25:52 vdr noad[15366]: [bt] [0xffffe420] Sep 21 21:25:52 vdr noad[15366]: [bt] /usr/local/bin/noad [0x804e4a3] Sep 21 21:25:52 vdr noad[15366]: [bt] /usr/local/bin/noad [0x80504f7] Sep 21 21:25:52 vdr noad[15366]: [bt] /usr/local/bin/noad [0x805081e] Sep 21 21:25:52 vdr noad[15366]: [bt] /usr/local/bin/noad [0x8051430] Sep 21 21:25:52 vdr noad[15366]: [bt] /usr/local/bin/noad [0x8052e36] Sep 21 21:25:52 vdr noad[15366]: [bt] /usr/local/bin/noad [0x8053182] Sep 21 21:25:52 vdr noad[15366]: [bt] /usr/local/bin/noad [0x805773d] Sep 21 21:25:52 vdr noad[15366]: [bt] /usr/local/bin/noad [0x8058060] Sep 21 21:25:52 vdr noad[15366]: [bt] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xf0) [0xb7bd0970] Sep 21 21:25:52 vdr noad[15366]: [bt] /usr/local/bin/noad(avcodec_register_all+0x41) [0x8049be1] yours, Jouni -- http://www.tkk.fi/%7ekex

3 4

a little delete recordings doubt
by Leo Márquez 03 Dec '05

03 Dec '05

Hi, When I delete recordings via osd or vdradmin the time remaining are not updated. What time have I to wait to see the free time available updated? Can I force this refresh? Thanks

5 5

VDR HLCI support ; was Re: [vdr] Twinhan VisionPlus DVB with CI: CAM doesn't support link layer interface [Fwd: Re: [linux-dvb] Re: A suggestion required...]
by Manu Abraham 01 Dec '05

01 Dec '05

Hi, In case somebody is interested in adding support to VDR a reference to the discussion that we had earlier on this aspect. If somebody needs to add support, applications that can be referenced at the moment are [1] ca_zap in dvb-apps [2] VLC (CVS version) If some body needs some help on this, would be glad to help on the specifics. Manu -------- Original Message -------- Subject: Re: [linux-dvb] Re: A suggestion required... Date: Sat, 12 Mar 2005 19:07:33 +0100 From: Klaus Schmidinger <Klaus.Schmidinger(a)cadsoft.de> Organization: CadSoft Computer GmbH To: linux-dvb <linux-dvb(a)linuxtv.org> References: <4232DB9D.6060601(a)kromtek.com> <20050312172423.GD16421(a)linuxtv.org> <4233265C.5090707(a)cadsoft.de> <423329B9.8010009(a)kromtek.com> Manu Abraham wrote: > Klaus Schmidinger wrote: > >> Johannes Stezenbach wrote: >> >>> Manu Abraham wrote: >>> >>>> I have been working on the Twinhan and Twinhan clone card drivers, i >>>> mean both FTA and CI based ones.. >>>> >>>> >>>> The FTA cards do look like most standard cards, whereas the CI based >>>> cards are a bit different from others.. >>>> >>>> The reason why the CI based cards do differ from the others is that >>>> there is no Transport Layer visible to the driver, but does exists >>>> in some form in the Firmware, and nothing can be done about it .. >>>> >>>> So here i am at a point, ready to write a layer/library that would >>>> make it more adaptable to DVB applications.. >>> >>> >>> >>> >>> Since you Cc'd Klaus: VDR already contains a CI library, and I guess >>> he's not eager to include another one. It would be nice if you >>> could point out to him what needs to be changed in VDR to support >>> Twinhan-style CI, or maybe even send him a patch. But you >>> better sort that out on the vdr mailing list. >>> >>> Johannes >> >> >> >> I wouldn't like to implement a special method of CI handling just > > > That would mean i have to make my own hardware ? Damn.. > >> for one particular hardware. You should make the interface behave > > > It is not one single hardware, but it is an entire family of cards.. > >> just like the existing one - then you can use VDR right out of the box. >> > > It is not a special method, but only thing is that everything is in > Application layer, rather than Transport layer. > I was not looking at using it straight out of the box.. > > Anyway, thanks for replying.. > > Manu Maybe you should describe in more detail where exactly the difference is with respect to how VDR's CI handling is done now. If it just means that everything VDR does in its cCiTransport* stuff is not needed for your card, I guess it shouldn't be too much trouble to handle things on the cCiSession level. What would be necessary then, though, would be some of of having the driver API tell the application which method to use (maybe that's already there and I just didn't use it ;-). And please post to the list and don't CC: me - this only tears threads apart. Klaus _______________________________________________ linux-dvb mailing list linux-dvb(a)linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

2 1

How to change xine default VDR location ?
by Gregoire Favre 01 Dec '05

01 Dec '05

Hello, I would like to have xine VDR button looks after /blablabla/vdr-xine. What's shoud I edit ? And BTW: current CVS don't patch : patching file src/post/planar/expand.c Hunk #3 FAILED at 68. Hunk #4 FAILED at 76. Hunk #5 succeeded at 92 with fuzz 2 (offset 4 lines). Hunk #6 succeeded at 118 (offset 4 lines). Hunk #7 FAILED at 165. Hunk #8 succeeded at 181 (offset 5 lines). Hunk #9 FAILED at 228. Hunk #10 FAILED at 240. Hunk #11 FAILED at 254. Hunk #12 succeeded at 344 (offset 8 lines). Hunk #13 succeeded at 376 (offset 8 lines). 6 out of 13 hunks FAILED -- saving rejects to file src/post/planar/expand.c.rej Thank you very much, -- Gr/'egoire FAVRE

2 2

Error in cPalette::Take (osd.c) ?
by Eike Edener 30 Nov '05

30 Nov '05

Udo Richter wrote: > Imho you can just pass on the color you don't want to change, > eg. like this: > > cOsd::DrawBitmap(x,y,bitmap,bitmap.Color(1),myBackground,replace) Yes, you are right. I was too blind to find the "bitmap.Color()"- function :-( . Thank you, Eike

1 0

Error in cPalette::Take (osd.c) ?
by Eike Edener 30 Nov '05

30 Nov '05

Hi, I'm currently writing my own plugin (VDR 1.3.37) using - cBitmap::LoadXpm() to load a bitmap and - cOsd::DrawBitmap() to draw it with changed background color (NOT changed foreground color). Because I neither want to change the foreground color nor know the foreground color value (tColor), I think it is good to change this part in cPalette::Take() (osd.c line 77-82): if (ColorFg || ColorBg) { switch (i) { case 0: Color = ColorBg; break; case 1: Color = ColorFg; break; } } to if (i == 0 && ColorBg) Color = ColorBg; if (i == 1 && ColorFg) Color = ColorFg; Eike

2 1

Re: vdr Digest, Vol 10, Issue 85
by Benji Mouse 30 Nov '05

30 Nov '05

Hi Oliver. I was hoping you would see this. Thanks for your reply. > Are you sure that you posted the correct logs and remote.conf? I think so, but I've tweaked and tested so much that it's entirely possible that I've crossed something somewhere. > Does this configuration work if you remove the av7110_loadkeys command? No luck. Here are my steps: removed and reloaded dvb-ttpci (and my frontend module) DID NOT run av7110_loadkeys deleted all of the remote-event0 entries from remote.conf started VDR DID NOT press a key to load a keymap Configured the remote Remote no longer working, stopped VDR Started VDR for fresh log. (did not unload or reload any modules, keymaps, etc.) Here's the log from VDR startup. This time the "remote-event0: keymap loaded '/proc/av7110_ir' flags 001f4000" is present like you said it should be. Nov 30 09:12:48 localhost vdr[2288]: VDR version 1.3.20 started Nov 30 09:12:48 localhost vdr[2288]: loading plugin: ./PLUGINS/lib/libvdr-remote.so.1.3.20 Nov 30 09:12:48 localhost vdr[2288]: loading /vdr_video/setup.conf Nov 30 09:12:48 localhost vdr[2288]: loading /vdr_video/sources.conf Nov 30 09:12:48 localhost vdr[2288]: loading /vdr_video/diseqc.conf Nov 30 09:12:48 localhost vdr[2288]: loading /vdr_video/channels.conf Nov 30 09:12:48 localhost vdr[2288]: loading /vdr_video/ca.conf Nov 30 09:12:48 localhost vdr[2288]: loading /vdr_video/remote.conf Nov 30 09:12:48 localhost vdr[2288]: probing /dev/dvb/adapter0/frontend0 Nov 30 09:12:48 localhost vdr[2291]: tuner on device 1 thread started (pid=2291, tid=16386) Nov 30 09:12:48 localhost vdr[2292]: Section handler thread started (pid=2292, tid=32771) Nov 30 09:12:48 localhost vdr[2288]: probing /dev/dvb/adapter1/frontend0 Nov 30 09:12:48 localhost vdr[2288]: found 1 video device Nov 30 09:12:48 localhost vdr[2288]: initializing plugin: remote (0.3.3): Remote control Nov 30 09:12:48 localhost vdr[2288]: setting primary device to 1 Nov 30 09:12:48 localhost vdr[2288]: SVDRP listening on port 2001 Nov 30 09:12:48 localhost vdr[2288]: loading /vdr_video/themes/classic-default.theme Nov 30 09:12:48 localhost vdr[2288]: starting plugin: remote Nov 30 09:12:48 localhost vdr[2288]: remote: using '/dev/input/event0' Nov 30 09:12:48 localhost vdr[2288]: remote-event0: autorepeat supported Nov 30 09:12:48 localhost vdr[2288]: remote-event0: exclusive access granted Nov 30 09:12:48 localhost vdr[2288]: remote-event0: keymap loaded '/proc/av7110_ir' flags 001f4000 Nov 30 09:12:48 localhost vdr[2288]: loading /vdr_video/themes/classic-default.theme Nov 30 09:12:48 localhost vdr[2294]: KBD remote control thread started (pid=2294, tid=65541) Nov 30 09:12:48 localhost vdr[2288]: remote control remote-event0 - keys known Nov 30 09:12:48 localhost vdr[2288]: remote control KBD - keys known Nov 30 09:12:48 localhost vdr[2288]: switching to channel 177 Nov 30 09:12:48 localhost vdr[2288]: setting audio track to 1 Here's part of the remote.conf: remote-event0._Setup /proc/av7110_ir 00000000 31 remote-event0.Up 0000000100010021 remote-event0.Down 0000000100010022 remote-event0.Menu 000000010001000E remote-event0.Ok 0000000100010026 remote-event0.Back 0000000100010020 remote-event0.Left 0000000100010012 remote-event0.Right 0000000100010011 The keyboard exhibits the same behavior as the remote (works through config, but not after). Unless the keyboard is somehow dependant on the remote keymap, wouldn't this indicate something more than just a remote keymap issue? This morning, I noticed something curious regarding evtest, but I'm not sure if it's related. For all I know, it might even be normal behavior. When I load dvb-ttpci and run av7110_loadkeys with hauppauge_grey, evtest says it sees a 'DVB on-card IR receiver' and displays the keymay for the remote. Fine. Once I start VDR, do the remote setup, and exit, evtest still shows 'DVB on-card IR receiver' , but the keymap displayed is for the keyboard. Is this expected? Thanks, Benj

2 1

Twinhan VisionPlus DVB with CI: CAM doesn't support link layer interface
by Stefan Hußfeldt 30 Nov '05

30 Nov '05

Hello, i've a Twinhan VisionPlus DVB with CI and AlphaCrypt light (linux-2.6.14, vdr-1.3.37). When i start vdr, syslogs says: |Nov 30 10:19:53 localhost kernel: dst_put_ci: Put Command |Nov 30 10:19:53 localhost kernel: ca_get_slot_caps: -->dst_put_ci SUCCESS ! |Nov 30 10:19:53 localhost kernel: ca_get_slot_caps: Slot cap = [5] |Nov 30 10:19:53 localhost kernel: =================================== |Nov 30 10:19:53 localhost kernel: 18 64 0 0 2 11 0 5 |Nov 30 10:19:53 localhost kernel: dst_ca_ioctl: -->CA_GET_CAP Success ! |Nov 30 10:19:53 localhost vdr[4107]: CAM doesn't support link layer interface |Nov 30 10:19:53 localhost kernel: dst_ca_release: Device closed. Is it a driver or a vdr problem and can it be solved? The CAM works fine in a FuSi DVB-C card. -- Und Tschüss. Stefan ### Kilroy was here ### 4855 10:40:00 up 19 days

5 9

Remote/keyboard seen during configuration, but not during normal use
by Benji Mouse 30 Nov '05

30 Nov '05

Hi folks. I recently lost the hard disk in my year-old VDR system and have had to rebuild from almost scratch. Everything is working except for the remote/keyboard. I've gone over things time and time again, but don't see anywhere that I've made a mistake. I've done quite a bit of searching (web and mailing list) and haven't found anything really helpful. I'm hoping someone here can point me in the right direction. Like I said in the subject, VDR will see the remote and keyboard long enough to create the remote.conf file, but when configuration is complete and VDR switches to normal 'show video' mode, both the remote and keyboard are ignored. Note that evtest output is normal, and that with IR debugging enabled, the remote keypresses show up in the log as expected. Installation details (note- I've tried to rebuild the system the same as it was prior to the crash): * Vanilla installation of Debian Sarge, 2.6.8 kernel recompiled from Debian-provided sources using the kernel config from the original (working) system. * In-kernel (non-CVS) DVB driver * Full featured Nexus card with the grey remote * VDR 1.3.20 compiled from source * Remote plugin version 0.3.3 * Loading hauppauge_grey.rc5 via av7110_loadkeys after inserting dvb-ttpci, prior to running VDR * Running VDR from the command line (not as a daemon) via ssh and screen. I don't see anything out of place in the syslog: Nov 29 22:13:31 localhost vdr[3539]: VDR version 1.3.20 started Nov 29 22:13:31 localhost vdr[3539]: loading plugin: ./PLUGINS/lib/libvdr- remote.so.1.3.20 Nov 29 22:13:31 localhost vdr[3539]: loading /vdr_video/setup.conf Nov 29 22:13:31 localhost vdr[3539]: loading /vdr_video/sources.conf Nov 29 22:13:31 localhost vdr[3539]: loading /vdr_video/diseqc.conf Nov 29 22:13:31 localhost vdr[3539]: loading /vdr_video/channels.conf Nov 29 22:13:31 localhost vdr[3539]: loading /vdr_video/ca.conf Nov 29 22:13:31 localhost vdr[3539]: loading /vdr_video/remote.conf Nov 29 22:13:31 localhost vdr[3539]: probing /dev/dvb/adapter0/frontend0 Nov 29 22:13:31 localhost vdr[3542]: tuner on device 1 thread started (pid=3542, tid=16386) Nov 29 22:13:31 localhost vdr[3543]: Section handler thread started (pid=3543, tid=32771) Nov 29 22:13:31 localhost vdr[3539]: probing /dev/dvb/adapter1/frontend0 Nov 29 22:13:31 localhost vdr[3539]: found 1 video device Nov 29 22:13:31 localhost vdr[3539]: initializing plugin: remote (0.3.3): Remote control Nov 29 22:13:31 localhost vdr[3539]: setting primary device to 1 Nov 29 22:13:31 localhost vdr[3539]: SVDRP listening on port 2001 Nov 29 22:13:31 localhost vdr[3539]: loading /vdr_video/themes/classic- default.theme Nov 29 22:13:31 localhost vdr[3539]: starting plugin: remote Nov 29 22:13:31 localhost vdr[3539]: device /dev/input/event0: DVB on-card IR receiver Nov 29 22:13:31 localhost vdr[3539]: remote: using '/dev/input/event0' Nov 29 22:13:31 localhost vdr[3539]: remote-event0: autorepeat supported Nov 29 22:13:31 localhost vdr[3539]: remote-event0: exclusive access granted Nov 29 22:13:31 localhost vdr[3539]: loading /vdr_video/themes/classic- default.theme Nov 29 22:13:31 localhost vdr[3545]: KBD remote control thread started (pid=3545, tid=65541) Nov 29 22:13:31 localhost vdr[3539]: remote control remote-event0 - keys known Nov 29 22:13:31 localhost vdr[3539]: remote control KBD - keys known Nov 29 22:13:31 localhost vdr[3539]: switching to channel 177 Nov 29 22:13:31 localhost vdr[3539]: setting audio track to 1 Here are some keypresses from the log - Nov 29 22:28:08 localhost kernel: #########000007e5######### addr 31 data 0x25 (keycode 38) Nov 29 22:28:08 localhost kernel: #########00000fe0######### addr 31 data 0x20 (keycode 33) Nov 29 22:28:09 localhost kernel: #########000007e1######### addr 31 data 0x21 (keycode 34) Nov 29 22:28:09 localhost kernel: #########00000fd1######### addr 31 data 0x11 (keycode 18) Nov 29 22:28:10 localhost kernel: #########000007d0######### addr 31 data 0x10 (keycode 17) And the related entries from remote.conf remote-event0._Setup /proc/av7110_ir 00000000 31 remote-event0.Ok 0000000100010026 remote-event0.Up 0000000100010021 remote-event0.Down 0000000100010022 remote-event0.Left 0000000100010012 remote-event0.Right 0000000100010011 I'm really running into a wall here. What am I missing? Thanks, Benj

3 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr November 2005