vdr

vdr@linuxtv.org

6731 discussions

VDSB since 1.3.37?
by Udo Richter 02 Dec '05

02 Dec '05

Hi list, Since Monday, I had two VDSB restarts while a recording started on my secondary TT-budget card. Both times I was watching a recording that time, but that may be a random coincidence. The point is: This never happened before. I'm using kernel 2.6.13.4 regularly for three weeks and occasionally for over 6 weeks, and not a single VDSB occurred before. The only noticeable change lately: VDR 1.3.37 on Sunday. Did any one else notice VDSB's since the update to 1.3.37? I'm not sure whether 1.3.37 is really the cause, but currently I have no idea what else may have caused this to appear. Cheers, Udo

5 5

Sound issues with three of the new DVB-t Spanish channels
by Javier Marcet 02 Dec '05

02 Dec '05

Hi guys, It's been already two whole day since Spain started the official transition to DVB-t. Before Nov. 30th, the 4 national analogue channels were being broadcasted on a single mux, while regional channels occupied another one. Last Wednesday, however, a few new channels began being broadcasted only through DVB-t. Now we have a few more transponders in use, and channels have been reorganized. Below is the entire list for Pontevedra: :DVB-T Pontevedra - TV TVE 1;(null):770000:M64B8T8G4Y0:T:27500:101:103,104:102:0:380:0:0:0 TVE 2;(null):770000:M64B8T8G4Y0:T:27500:201:203,204:202:0:381:0:0:0 Antena 3;(null):690000:M64B8T8G4Y0:T:27500:301:303:302:0:140:8916:13:0 CUATRO;SOGECABLE:666000:M64B8T8G4Y0:T:27500:160:80,81:32:0:1057:8916:11:0 Telecinco;(null):850000:C23D12M64B8T8G4Y0:T:27500:203:303:703:0:180:12289:0:0 LA SEXTA 1;(null):666000:M64B8T8G4Y0:T:27500:1501:0:0:0:340:8916:11:0 La Sexta 2;(null):690000:M64B8T8G4Y0:T:27500:1501:0:0:0:341:8916:13:0 24H TVE;(null):770000:M64B8T8G4Y0:T:27500:1001:1003:0:0:382:0:0:0 40 LATINO;SOGECABLE:666000:M64B8T8G4Y0:T:27500:162:88:0:0:1059:8916:11:0 A3.neox;(null):690000:M64B8T8G4Y0:T:27500:501:503:0:0:141:8916:13:0 A3.nova;(null):690000:M64B8T8G4Y0:T:27500:1001:1003:0:0:142:8916:13:0 CLAN/50 TVE;(null):770000:M64B8T8G4Y0:T:27500:1501:1503:0:0:383:0:0:0 CNN+;SOGECABLE:666000:M64B8T8G4Y0:T:27500:161:84:0:0:1058:8916:11:0 FLYMUSIC;(null):850000:C23D12M64B8T8G4Y0:T:27500:1501:1502:0:0:261:12289:0:0 NET TV;(null):834000:C23D12M64B8T8G4Y0:T:27500:1501:1502:0:0:300:12289:0:0 T5 Estrellas;(null):850000:C23D12M64B8T8G4Y0:T:27500:201:301:701:0:181:12289:0:0 T5 Sport;(null):850000:C23D12M64B8T8G4Y0:T:27500:202:302:702:0:182:12289:0:0 TELEDEPORTE;(null):834000:C23D12M64B8T8G4Y0:T:27500:101:103:0:0:100:12289:0:0 VEO TV;(null):834000:C23D12M64B8T8G4Y0:T:27500:1001:1002:0:0:260:12289:0:0 TVG;CRTVG:810000:C23D12M64B8T8G4Y0:T:27500:160:161,162:163:0:1569:12610:0:0 Galicia TV America;CRTVG:810000:C23D12M64B8T8G4Y0:T:27500:180:181,182:183:0:1571:12610:0:0 Galicia TV Europa;CRTVG:810000:C23D12M64B8T8G4Y0:T:27500:170:171,172:173:0:1570:12610:0:0 PROBAS RETEGAL;RETEGAL:810000:C23D12M64B8T8G4Y0:T:27500:320:321:0:0:1602:12610:0:0 :DVB-T Pontevedra - Radio RNE1;(null):770000:M64B8T8G4Y0:T:27500:0:2001:0:0:385:0:0:0 RNEC;(null):770000:M64B8T8G4Y0:T:27500:0:2011:0:0:386:0:0:0 RNE3;(null):770000:M64B8T8G4Y0:T:27500:0:2021:0:0:387:0:0:0 Radio Galega;CRTVG:810000:C23D12M64B8T8G4Y0:T:27500:0:200:0:0:1592:12610:0:0 R.Galega Musica;CRTVG:810000:C23D12M64B8T8G4Y0:T:27500:0:199:0:0:1593:12610:0:0 Son Galicia Radio;CRTVG:810000:C23D12M64B8T8G4Y0:T:27500:0:201:0:0:1594:12610:0:0 The first batch of bad news -- for me and anybody else having a single DVB-t tuner in Spain -- was that I cannot record all the available national channels at once, as I did before. At least until a get at least two more budget DVB-t cards. Worse than this, however, is that three of the above channels have sound problems. They are 'Telecinco', 'T5 Estrellas' and 'T5 Sport'. The three come from the same producer. The former one is not a new channel, It should have only changed frequency. At least, I guesses so. Yet, it seems something else changed. I'm using bitstreamout, and I get no sound from those channels. Neither from the SPDIF or the analogue outputs of the sound card. My surprise came when I saw that sound was actually recorded, but I only could hear it using mplayer -- yes, over the same FF DVB-s card I use vdr on --. After checking the language IDs and trying a few tricks (their language IDs are not identified as 'esl' or 'esp', the right ID for Spanish audio, but 'eng' which in theory means English). That doesn't seem to be the problem, though. Using the femon plugin, I saw that audio is encoded at 32Khz (at least the mpeg headers show that). Right after realizing where the problem lied, I verified sound was coming from the analog out of the FF DVB-s card. However. yet another issue aroused. Live viewing made perfect sound (OSS still muted). On the other hand, some recordings play just fine, while others make a smurf-like sound, which I inferred it means a pitch change is taking place due to incorrect 44/32KHz tagging. Using mplayer everything plays fine, hence it should not be that hard to fix, but I'll need help. I can send some raw sample recordings to anyone who might make good use of them :) Thanks for your help, sorry for the longish post, and of course a _big_ thank you to Klaus for ... everything :) -- Style may not be the answer, but at least it's a workable alternative. Javier Marcet <javier(a)marcet.info>

1 0

Re: [vdr] Remote/keyboard seen during configuration, but not during normal use
by Benji Mouse 01 Dec '05

01 Dec '05

> > When starting VDR, the info banner showing the channel, what's on, > > etc. is normally displayed for a few seconds. Well it just occurred > > to me that it's not being displayed at all. When I start VDR, I get > > the video playing, and that's it - no interface. > > > > I've also discovered that SVDRP isn't working. The log says that it's > > running on port 2001, but netstat doesn't show anything listening on > > 2001. > > > > I started looking through the code, and it looks like the input > > routines and the SVDRP socket construction are all tied to the > > interface class. This leads me to believe that fixing whatever is > > causing the interface not to show up may fix the input and SVDRP > > problems. > > > > Another interesting thing - If I don't load ANY plugins, SVDRP will > > start (netstat shows it listening on 2001). Of course it won't accept > > any input, but at least the socket is there. If I load a plugin > > (remote, for example, but I've verified it with others, also) the > > socket doesn't show up. > > > Hm - just a wild guess: Please verify that you have > export LD_ASSUME_KERNEL=2.4.1 > line in your start vdr script (runvdr or whatever you use). > I do. In fact, I looked into that once I discovered the above items. It does seem to lend itself to some kind of threading problem, though. I just can't imagine why. Benj

2 1

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

Re: [vdr] Remote/keyboard seen during configuration, but not during normal use
by Benji Mouse 01 Dec '05

01 Dec '05

>This looks like a perfect configuration. Should work. ;-) That's what I thought too :-/ >> 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? >Keyboard and remote control should be independent. >Let's try to simplify the configuration. Please test whether vdr can be >controlled using the keyboard if you do _not_ load the remote plugin. The behavior is the same - it works during the configuration step, but not afterward. I wonder what's different between the input handling of the remote configuration step, and the input handling of the running program, and what I could've done to make them behave differently. Any suggestions on where to go from here? >> 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? >I guess you saw the keymap of the remote plugin, not the keymap of the >keyboard: The remote plugin replaced your keymap because it wasn't >told to keep the pre-loaded keymap... That makes sense. Thanks. Benj

2 2

videgor ?
by Oliver Joa 01 Dec '05

01 Dec '05

hi, what do you think about: http://www.videgor.de/ i have 3 vdr at home and try to find a solution to share the timers between the vdr. at the moment i do it by the webfrontend, because one of the vdr is on the roof. i would like to have a solution so that the vdr automatically do this. i use one big network-filesystem, so that every vdr can see the recordings. the idea of videgor is exactly what i want, but i don't like to patch the vdr, because maybe the patch can not be used in a future version. i don't want to be dependent on a old version. is there any other solution to share the timers automatically amoung >1 vdr? klaus: do you plan to integrate some functionality like this? olli

7 7

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr