Re: [linux-dvb] Multiproto ???
On 01/16/08 14:51, Stephen Rowles wrote: A long time ago multiproto was said to be integrated in *near* future... to my great disapointment it still isn't, which is certainly not a good thing for the user at least... Could we hope to be *near* inclusion now ? In the meantime I am really thankfull to all who made multiproto available, and I hope the problems of the past could be forgiven. I would like to add a note to this, for those that haven't heard the BBC will be starting a new satellite service soon, spring 08 according to their website http://www.freesat.co.uk/home.php. This will be DVB-S2 transmissions including HD content, and will use the Eurobird 1 satellite situated at 28.5° east (from what I can find on the web). Once this service launches I imagine there will be lots of people (me included!) who will want to upgrade their Linux based media centres and therefore get HD content. As I understand it the Multiproto stuff is a pre-req in a chain required to get DVB-S2 working, so I expect that there will soon be a large number of people from the UK wanting to have this working so they can upgrade their media centres and get HD programs. I also find the current situation rather confusing. What exactly is *the* multiproto driver I should use when (soon) starting to adopt the various patches to VDR regarding DVB-S2 etc.? It would be nice if ther was a central repository (at linuxtv.org?) where *the* driver could be downloaded, just as it was in the good old days... Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [scan patch] do not set ca field to 1 for vdr
On 09/27/07 16:33, Christoph Pfister wrote: Can somebody offical from vdr confirm this patch (sorry, I don't know the who's-who there)? Because only vdr output format is affected and I don't think people use that format for other purposes than vdr, I don't see any reason against applying it (the actual changes are vdr's beer, not mine :) Christoph Setting the CA value to 0 (zero) is perfectly ok for VDR versions = 1.3. Klaus Am Samstag 22 September 2007 schrieb Anssi Hannula: Since VDR 1.3 series (released about 3-5 years ago I think), VDR updates the ca field of channels.conf entry automatically. However, value 1 has a special meaning to VDR. It will force the use of DVB card 1 to receive the channel, and will not update the ca field to its proper value. However, scan defaults to setting ca value to 1 on encrypted channels, which does not make sense. The attached patch adds a new default value -1 to -x parameter and sets vdr default version to 3 instead of the now obsolete 2. With the new value -1 scan will set ca field of all channels to 0 and let VDR update the field properly. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: Re : Re : [linux-dvb] Working DVB-S + CAM question
Dominique Dumont wrote: ... For low level CI API, i.e. Hauppauge TT cards), the CI stack is ~90% implemented in software in the DVB application. For high level CI (i.e Twinhan and clones), the stack is half implemented in firmare (i.e. bugs can't be fixed) and half in software in the application. AFAIK, vdr can't handle high-level CI API. From what I can see in http://linuxtv.org/wiki/index.php/CI all that VDR would have to do in order to use the high level API would be to go from the application layer directly to the CAM. However, I don't know of any driver API for this. Can you give me a hint how the high level API should be accessed through the LinuxDVB driver? Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Missing dependencies in *.ko files
Trent Piepho wrote: On Sun, 7 Jan 2007, Klaus Schmidinger wrote: If I use the latest driver from http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-refactoring there are apparently dependencies missing in some *.ko files, so my script can't find out which additional modules to load. For example, /sbin/modinfo -F depends dvb-ttpci.ko returns dvb-core,saa7146,i2c-core,saa7146_vv,dvb-core,ttpci-eeprom,firmware_class while in the driver version as of 2006-11-04 it returns dvb-core,saa7146,stv0299,i2c-core,saa7146_vv,dvb-core,ttpci-eeprom,ves1x93,stv0297,sp8870,tda8083,ves1820,firmware_class,l64781,lnbp21 Is there something wrong, or am I missing something here? There is a new system called dvb_attach() that makes those front-end module dependencies dynamic. They don't show up in the list of module dependencies from modinfo and don't need to be loaded before the module is loaded. Instead, dvb-ttpci will dynamically load the front-end modules that it needs, and only the modules that it needs for your particular card. If you are trying to auto-load the modules without installing them you can disable dvb_attach and get static dependencies back. Thanks, that helped. Just for completeness: the line in the config file is CONFIG_DVB_CORE_ATTACH=y Setting this to 'n' gives me back the full dependencies. Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] How to handle multiple frontends?
Manu Abraham wrote: ... There are 2 different cases (1) multiple frontends sharing the same TS interface (2) multiple frontends, each having it's own TS interface. Maybe those should be handled like one multi-protocol frontend? Not sure if Manu's multi-proto stuff would also handle this across different tuners. We would need another layer of abstraction. Or should just the demuxes lock against each other? So, if one demux has filters set, the other one will not accept any. I guess the frontends themselve work at the same time, they just share the same TS input? for (1), they just share the same TS interface which is already implemented, but when we have a derivative of (2) multiple frontends, we can have say for example 4 frontends with 2 TS interfaces or 3 TS interfaces. So I guess for VDR it will be ok to assume that a device with several frontends can only actually use one frontend at a time. Otherwise there would have to be some way of querying the device how many of the frontends can be used in parallel. But AFAIK there is no such facility in the current DVB driver API, or is there? Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] How to handle multiple frontends?
I'm wondering how an application is supposed to handle devices with multiple frontends. Let's assume a device that provides dvb/adapter0/frontend0DVB-S dvb/adapter0/frontend1DVB-T so that it can receive both DVB-S and DVB-T. Does this mean that it can simultaneously receive one DVB-S transponder and one DVB-T transponder? Or can it receive either a DVB-S *or* a DVB-T transponder, but not both at the same time? Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Missing dependencies in *.ko files
I'm using a modified version of the v4l/scripts/rmmod.pl script to be able to state only the high level driver modules I know I need to load, and have the script find out what other modules these depend on and automatically load them, too, as in rmmod.pl load dvb-ttpci budget for a system with full featured and budget DVB cards. See ftp://ftp.cadsoft.de/vdr/Developer/rmmod.pl for my version of the script If I use the latest driver from http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-refactoring there are apparently dependencies missing in some *.ko files, so my script can't find out which additional modules to load. For example, /sbin/modinfo -F depends dvb-ttpci.ko returns dvb-core,saa7146,i2c-core,saa7146_vv,dvb-core,ttpci-eeprom,firmware_class while in the driver version as of 2006-11-04 it returns dvb-core,saa7146,stv0299,i2c-core,saa7146_vv,dvb-core,ttpci-eeprom,ves1x93,stv0297,sp8870,tda8083,ves1820,firmware_class,l64781,lnbp21 Is there something wrong, or am I missing something here? Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Pre-packaged vdr 1.4.3 decrypting fails?
Otto J. Makela wrote: Klaus Schmidinger wrote: There is no CAM message in your log. There should be a line like Nov 17 17:38:20 video vdr: [2906] CAM: AlphaCrypt, 01, 4A20, 4A20 which indicates that VDR has established communication with the CAM. True, not in that log, but it does appear in some other restart logs, without seeming to help much: ... Nov 18 02:03:41 piglet kernel: dvb-ttpci: firmware @ card 0 supports CI link layer interface ... Nov 18 02:03:42 piglet vdr: [10643] VDR version 1.4.3-1 started ... Nov 18 02:03:44 piglet vdr: [10643] switching to channel 44 Actually VDR should wait at this point until all CAMs are ready,... ... Nov 18 02:03:44 piglet vdr: [10643] timer 3 (44 0050-0210 'Is It Real?: Exorcism') start Nov 18 02:03:44 piglet vdr: [10643] record /srv/vdr/Is_It_Real#3F#3A_Exorcism/2006-11-18.00.50.80.99.rec Nov 18 02:03:48 piglet vdr: [10643] stopping recording due to modification of channel 44 Nov 18 02:03:48 piglet vdr: [10643] timer 3 (44 0050-0210 'Is It Real?: Exorcism') stop Nov 18 02:03:48 piglet vdr: [10643] retuning due to modification of channel 44 Nov 18 02:03:48 piglet vdr: [10643] switching to channel 44 Nov 18 02:03:48 piglet vdr: [10643] timer 3 (44 0050-0210 'Is It Real?: Exorcism') start Nov 18 02:03:48 piglet vdr: [10643] record /srv/vdr/Is_It_Real#3F#3A_Exorcism/2006-11-18.00.50.80.99.rec Nov 18 02:03:59 piglet vdr: [10647] CAM: Conax 4.00e, 01, 0B00, 04B1 ...but the CAM only gets ready here, when the timer has already started recording. Are there any patches involved that might disturb this? Have you tried plain vanilla VDR, yet? Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Pre-packaged vdr 1.4.3 decrypting fails?
Otto J. Makela wrote: I'm using the pre-packaged vdr-1.4.3-3.fc5 and vdr-subtitles-0.4.0-6.fc5 from //fedora.redhat.com/pub/fedora/linux/extras/5/i386/ It seems this pre-packaged vdr fails to work with a full-feature Technotrend with a CAM, it just fails with no useful data seen when it tries to record stuff from an encrypted channel (with the properly working decoder card in the CAM in the CI module). Anyone else trying to use this? I am beginning to suspect the ready-compiled version is somehow miscompiled, but if so, I'd really like to be able to fix it. There is no CAM message in your log. There should be a line like Nov 17 17:38:20 video vdr: [2906] CAM: AlphaCrypt, 01, 4A20, 4A20 which indicates that VDR has established communication with the CAM. Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] hdtv scanning
Nico Sabbi wrote: Andrea Venturi wrote: Klaus Schmidinger wrote: No - and it won't. TS is for broadcasting, and PES is for recording. is this just a personal opinion? me, actually i can see a great move toward TS also for storing.. i think about the HDV storage cassette; there is a TS inside the tape. the forecoming blu ray technology has a TS inside the optical diskette (but i have to say there's a PS inside the HD-DVD disk; who's going to win, i dont know..) really? I thught it would use TS, too. Do you have any specification? IMHO i believe that in the medium term there's no space for two different storage standards: to hassle to maintain both up to date the TS is going to succeed because: - it's where all the development for newer services is going to be done - you can store the broadcast straight on the disk - the bucks per storage byte index is going lower and lower.. bye andrea venturi agree, and the overhead of ts over pes is going to be insignificant with the typically used bitrates. Anyway, Klaus, you can repack the pmt as a psm in the .vdr stream and keep the same informations about codec, language, and so on I'll cross that bridge when I get there. The whole HDTV thing is of no interest to me until there is a DVB card that can actually replay HDTV in hardware. Until then I'm not going to spend any time on this. And by looking at what great lengths broadcasters are going to just to make sure nobody sees (let a lone records) their HDTV programmes, it's even questionable if this will ever become interesting for VDR. Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: hdtv scanning
Benny Amorsen wrote: KS == Klaus Schmidinger [EMAIL PROTECTED] writes: KS The whole HDTV thing is of no interest to me until there is a DVB KS card that can actually replay HDTV in hardware. Why would it have to be the DVB card doing it? That seems to be the job of the graphics card and the CPU. Well, call me old-fashioned, but I believe that for normal live tv viewing a DVB card should be able to do the job entirely on its own. VDR just tells it which channel to tune to and that's it. It's this take some old PC, put in a DVB card and have a digital video recorder thing ;-). Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] hdtv scanning
matthieu castet wrote: matthieu castet wrote: Hi, Does somebody know why scan dvb-util or vdr failed to parse video pid of hdtv stream ? Why a patch like the attached one couldn't be added ? After some reflexion, a new category (video hd) should be created : dvb apps using channel file need to know if it is a mpeg2 or h264 video as they already does it for audio (mp2 vs ac3). We don't need that, because there is always only *one* video track, as opposed to audio, where there can be both mpeg and ac3. Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] hdtv scanning
matthieu castet wrote: Klaus Schmidinger wrote: matthieu castet wrote: matthieu castet wrote: Hi, Does somebody know why scan dvb-util or vdr failed to parse video pid of hdtv stream ? Why a patch like the attached one couldn't be added ? After some reflexion, a new category (video hd) should be created : dvb apps using channel file need to know if it is a mpeg2 or h264 video as they already does it for audio (mp2 vs ac3). We don't need that, because there is always only *one* video track, as opposed to audio, where there can be both mpeg and ac3. Yes but in order to know the video type we need the PMT. But IIRC the current policy is to use the PMT only to make channel.conf and then to use channel.conf. So etheir you add more information in channel.conf (video encoding), etheir a more sane solution (which is done by mythtv AFAIK) is to put in channel.conf only tuning information + service_id + extra information (name, ...) and when you swith to a channel, you use PAT to discover your channel PMT pid, and you use PMT to discover media (video, audio, ...) pids and types (mpeg2, h264, ...). I don't like that because when I switch to a channel I don't want to first have to parse all kinds of tables, that would slow down channel switching. The second solution is also usefull when recording channel, because player will need PMT or something that describe the content of the stream. Is the fact that a stream is coded in H.264 not stored on the (P)ES data? PS : do you plan something for VDR ? Sure, once the driver supports DVB-S2 ;-) Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] hdtv scanning
Nico Sabbi wrote:
Klaus Schmidinger wrote:
Hmm, I would have expected that information to be in there somewhere.
The decoder should be able to detect the encoding of the data stream
by itself, without the application having to tell it what the data
actually is.
Klaus
from an application point of view it makes more sense to follow the model:
decode_pat()
foreach program
{
decode_pmt() == identify the codec used by the stream_type
}
Moreover, the pes headers in mpeg2 are already overbloated with 90% of
useless crap;
adding more stuff would have been a bad choice, IMO.
Well, that might be feasible for live viewing, but what
about replaying a recording? There is no PAT/PMT in a
recording.
Klaus
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] hdtv scanning
Nico Sabbi wrote: Klaus Schmidinger wrote: Well, that might be feasible for live viewing, but what about replaying a recording? There is no PAT/PMT in a recording. Klaus there is if you save the TS, rather than that funny .vdr aka pes. Can VDR save the TS now? No - and it won't. TS is for broadcasting, and PES is for recording. Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] hdtv scanning
Michael Müllner wrote: Klaus Schmidinger schrieb: matthieu castet wrote: ... PS : do you plan something for VDR ? Sure, once the driver supports DVB-S2 ;-) Why wait ? there are also H264 over dvb-s :) Mike But there is no full featured DVB card yet that can be used to replay HDTV. And since my VDR only has a 450 MHz CPU, which can't decode HDTV in software, and I'm not planning on putting a 3GHz dual CPU machine into my living room, HDTV is currently not interesting for me ;-) Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] CA_CI_MODULE_READY not reset when CAM removed from AV7110 DVB card
Oliver Endriss wrote:
Klaus Schmidinger wrote:
I'm currently improving VDR's CAM handling, and while doing so
I came across what seems to be a bug in the AV7110 driver code.
If I do
int fd = open(/dev/dvb/adapter0/ca0, O_RDWR);
ca_slot_info_t sinfo;
sinfo.num = 0;
ioctl(fd, CA_GET_SLOT_INFO, sinfo);
to check whether the CI adapter contains a CAM, the value of
sinfo.flags is 0 as long as no CAM is inserted. When I insert a CAM,
it first goes to 1 (CA_CI_MODULE_PRESENT) and then to 3
(CA_CI_MODULE_PRESENT | CA_CI_MODULE_READY). So far everything is ok.
However, when I remove the CAM from the slot, sinfo.flags still remains
set to 3. It never goes back to 0.
Is this a bug or intended behavior?
Afaics it is a bug. Could you check whether CI_handle(in av7110_ca.c) is
called when you remove the CAM? If not it's a firmware bug.
CI_handle(in av7110_ca.c) never gets called.
I've added the following debug output to av7110.c (after trying directly in
av7110_ca.c, which didn't give any results):
case DATA_CI_GET:
{
printk(DATA_CI_GET: %d %d %d %d %d %d %d\n, __LINE__,
debibuf[0], debibuf[1], debibuf[2], debibuf[3], debibuf[4], debibuf[5]);//XXX
if ((debibuf[0] 2) debibuf[2] == 0xff) {
int flags = 0;
if (debibuf[5] 0)
flags |= CA_CI_MODULE_PRESENT;
if (debibuf[5] 5)
flags |= CA_CI_MODULE_READY;
printk(DATA_CI_GET: %d %04X %04X\n, __LINE__,
av7110-ci_slot[debibuf[0]].flags, flags);//XXX
av7110-ci_slot[debibuf[0]].flags = flags;
} else
ci_get_data(av7110-ci_rbuffer, debibuf,
debilen);
break;
}
case DATA_COMMON_INTERFACE:
printk(DATA_COMMON_INTERFACE: %d %d\n, __LINE__,
debilen);//XXX
CI_handle(av7110, debibuf, debilen);
What I get in the log file is:
* Start VDR with no CAM in the slot
Nov 1 11:25:22 video kernel: DATA_CI_GET: 376 0 0 255 2 0 0
Nov 1 11:25:22 video kernel: DATA_CI_GET: 383
* Insert CAM into slot:
Nov 1 11:25:58 video kernel: DATA_CI_GET: 376 0 0 255 2 0 1
Nov 1 11:25:58 video kernel: DATA_CI_GET: 383 0001
Nov 1 11:25:59 video kernel: DATA_CI_GET: 376 0 0 255 2 0 2
Nov 1 11:25:59 video kernel: DATA_CI_GET: 383 0001 0001
Nov 1 11:25:59 video kernel: DATA_CI_GET: 376 0 0 255 2 0 3
Nov 1 11:25:59 video kernel: DATA_CI_GET: 383 0001 0001
Nov 1 11:25:59 video kernel: DATA_CI_GET: 376 0 0 255 2 0 4
Nov 1 11:25:59 video kernel: DATA_CI_GET: 383 0001 0001
Nov 1 11:25:59 video kernel: DATA_CI_GET: 376 0 0 255 2 0 5
Nov 1 11:25:59 video kernel: DATA_CI_GET: 383 0001 0001
Nov 1 11:25:59 video kernel: DATA_CI_GET: 376 0 0 255 2 0 6
Nov 1 11:25:59 video kernel: DATA_CI_GET: 383 0001 0003
Nov 1 11:26:00 video vdr: [8977] CAM: module ready in slot 0
Nov 1 11:26:01 video kernel: DATA_CI_GET: 376 0 1 131 1 1 128
Nov 1 11:26:01 video kernel: DATA_CI_GET: 376 0 1 128 2 1 128
Nov 1 11:26:01 video kernel: DATA_CI_GET: 376 0 1 160 7 1 145
Nov 1 11:26:01 video kernel: DATA_CI_GET: 376 0 1 128 2 1 0
Nov 1 11:26:01 video kernel: DATA_CI_GET: 376 0 1 128 2 1 0
Nov 1 11:26:02 video kernel: DATA_CI_GET: 376 0 1 128 2 1 128
Nov 1 11:26:03 video kernel: DATA_CI_GET: 376 0 1 160 130 0 9
Nov 1 11:26:03 video kernel: DATA_CI_GET: 376 0 1 128 2 1 0
Nov 1 11:26:04 video kernel: DATA_CI_GET: 376 0 1 128 2 1 128
Nov 1 11:26:04 video kernel: DATA_CI_GET: 376 0 1 160 130 0 9
Nov 1 11:26:04 video kernel: DATA_CI_GET: 376 0 1 128 2 1 0
Nov 1 11:26:06 video kernel: DATA_CI_GET: 376 0 1 128 2 1 128
Nov 1 11:26:06 video kernel: DATA_CI_GET: 376 0 1 160 7 1 145
Nov 1 11:26:06 video kernel: DATA_CI_GET: 376 0 1 128 2 1 0
Nov 1 11:26:06 video kernel: DATA_CI_GET: 376 0 1 128 2 1 0
Nov 1 11:26:07 video kernel: DATA_CI_GET: 376 0 1 128 2 1 128
Nov 1 11:26:07 video kernel: DATA_CI_GET: 376 0 1 160 130 0 31
Nov 1 11:26:07 video vdr: [8977] CAM: AlphaCrypt, 01, 4A20, 4A20
Nov 1 11:26:08 video kernel: DATA_CI_GET: 376 0 1 128 2 1 128
Nov 1 11:26:09 video kernel: DATA_CI_GET: 376 0 1 160 7 1 145
Nov 1 11:26:09 video kernel: DATA_CI_GET: 376 0 1 128 2 1 0
Nov 1 11:26:09 video kernel: DATA_CI_GET: 376 0 1 128 2 1 0
Nov 1 11:26:10 video kernel: DATA_CI_GET: 376 0 1 128 2 1 128
Nov 1 11:26:10 video kernel: DATA_CI_GET: 376 0 1 160 130 0 17
Nov 1 11:26:11 video kernel: DATA_CI_GET: 376 0 1 128 2 1 128
Nov 1 11:26:12 video kernel: DATA_CI_GET: 376 0 1 160 7 1 145
Nov 1 11:26:12 video kernel: DATA_CI_GET: 376 0 1 128 2 1 0
Nov 1 11:26:13 video kernel: DATA_CI_GET: 376 0 1 128 2 1 128
Nov 1 11:26:13 video kernel: DATA_CI_GET: 376 0 1 160 130 0 10
Nov 1 11:26:13 video kernel: DATA_CI_GET: 376 0 1
Re: [linux-dvb] CA_CI_MODULE_READY not reset when CAM removed from AV7110 DVB card
Klaus Schmidinger wrote: Oliver Endriss wrote: Klaus Schmidinger wrote: I'm currently improving VDR's CAM handling, and while doing so I came across what seems to be a bug in the AV7110 driver code. If I do int fd = open(/dev/dvb/adapter0/ca0, O_RDWR); ca_slot_info_t sinfo; sinfo.num = 0; ioctl(fd, CA_GET_SLOT_INFO, sinfo); to check whether the CI adapter contains a CAM, the value of sinfo.flags is 0 as long as no CAM is inserted. When I insert a CAM, it first goes to 1 (CA_CI_MODULE_PRESENT) and then to 3 (CA_CI_MODULE_PRESENT | CA_CI_MODULE_READY). So far everything is ok. However, when I remove the CAM from the slot, sinfo.flags still remains set to 3. It never goes back to 0. Is this a bug or intended behavior? Afaics it is a bug. Could you check whether CI_handle(in av7110_ca.c) is called when you remove the CAM? If not it's a firmware bug. CI_handle(in av7110_ca.c) never gets called. ... Well, apparently this is a firmware problem - and, shame on me, one I created myself... Back in 2003 I was debugging problems with CAM access, and my findings then were that if the CiMAX version 2.0 chip's registers were read too often, this caused frequent failures. So I changed that to no longer read the CiMAX registers once a CAM has been detected. Well, looks like this is now backfiring at me. I'll test what happens if I revert to the old version, maybe the problem back then was something else... Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] CA_CI_MODULE_READY not reset when CAM removed from AV7110 DVB card
I'm currently improving VDR's CAM handling, and while doing so I came across what seems to be a bug in the AV7110 driver code. If I do int fd = open(/dev/dvb/adapter0/ca0, O_RDWR); ca_slot_info_t sinfo; sinfo.num = 0; ioctl(fd, CA_GET_SLOT_INFO, sinfo); to check whether the CI adapter contains a CAM, the value of sinfo.flags is 0 as long as no CAM is inserted. When I insert a CAM, it first goes to 1 (CA_CI_MODULE_PRESENT) and then to 3 (CA_CI_MODULE_PRESENT | CA_CI_MODULE_READY). So far everything is ok. However, when I remove the CAM from the slot, sinfo.flags still remains set to 3. It never goes back to 0. Is this a bug or intended behavior? Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] TechnoTrend Budget T-1500 DVB-T CI doesn't find any channels
Jon Forsberg wrote: Hello! I can't get my Budget T-1500 to find any channels. The modules seem to load ok and I do a 'scan scan_example_file_for_my_country_and_town': scanning scan_example_file_for_my_country_and_town using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 58600 0 2 0 3 1 2 0 initial transponder 53800 0 2 0 3 1 2 0 initial transponder 50600 0 2 0 3 1 2 0 initial transponder 69800 0 2 0 3 1 2 0 initial transponder 74600 0 2 0 3 1 2 0 tune to: 58600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_NONE:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE WARNING: tuning failed!!! tune to: 58600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_NONE:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE (tuning failed) WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x WARNING: filter timeout pid 0x0010 tune to: 53800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_NONE:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x WARNING: filter timeout pid 0x0010 tune to: 50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_NONE:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x WARNING: filter timeout pid 0x0010 tune to: 69800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_NONE:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x WARNING: filter timeout pid 0x0010 tune to: 74600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_NONE:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x WARNING: filter timeout pid 0x0010 dumping lists (0 services) Done. So it didn't find anything(?). The frequencies and parameters I use are correct for my location (I have checked). I have tried to do a scan with Kaffeine (0.6) as well - same result. Am I missing something obvious? Sounds like the same problem I had. The card generates a +5V power supply for active antennas. If your antenna shorts the power, the card won't receive anything. There is a jumper on the card which you can remove to turn the power off. Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] How to turn off +5V supply on AirStar2
Does anybody know a way to turn off the +5V supply voltage on the antenna input of the TechniSat AirStar2 DVB-T card? The driver source file frontends/mt352.c mentions the MT352 design manual from Zarlink, so I assume somebody must have access to that manual. Is it publicly available? Or could somebody with access to it check if there is a register setting for controlling the +5V supply? Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] How to turn off +5V supply on AirStar2
e9hack wrote: ... I think, you will found nothing about the antenna supply in the spec of the demodulator (MT352) or the pll (TSA5523M). If the card has implemented a switchable supply, they will use one of the GPIO-Pins (GPP3 from MT352 or P0..P7 from TSA5523M). The band switch bytes for the pll are 0x09 (VHF low), 0x0a (VHF high) and 0x08 (UHF). Possible, P3 (bit 3) is where you are searching for. I'm afraid I don't quite understand what you mean by mentioning the band switch bytes. Are you saying that in the code sequence if (params-frequency = 4800 params-frequency = 15400) bs = 0x09; if (params-frequency = 16100 params-frequency = 43900) bs = 0x0a; if (params-frequency = 44700 params-frequency = 86300) bs = 0x08; pllbuf[0] = 0x61; pllbuf[1] = div 8; pllbuf[2] = div 0xff; pllbuf[3] = 0xcc; pllbuf[4] = bs; in flexcop-fe-tuner.c I should do bs |= 0x04; to set bit 3? Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] How to turn off +5V supply on AirStar2
Klaus Schmidinger wrote: e9hack wrote: ... I think, you will found nothing about the antenna supply in the spec of the demodulator (MT352) or the pll (TSA5523M). If the card has implemented a switchable supply, they will use one of the GPIO-Pins (GPP3 from MT352 or P0..P7 from TSA5523M). The band switch bytes for the pll are 0x09 (VHF low), 0x0a (VHF high) and 0x08 (UHF). Possible, P3 (bit 3) is where you are searching for. I'm afraid I don't quite understand what you mean by mentioning the band switch bytes. Are you saying that in the code sequence if (params-frequency = 4800 params-frequency = 15400) bs = 0x09; if (params-frequency = 16100 params-frequency = 43900) bs = 0x0a; if (params-frequency = 44700 params-frequency = 86300) bs = 0x08; pllbuf[0] = 0x61; pllbuf[1] = div 8; pllbuf[2] = div 0xff; pllbuf[3] = 0xcc; pllbuf[4] = bs; in flexcop-fe-tuner.c I should do bs |= 0x04; to set bit 3? Well, or rather bs = ~0x08; to clear P3 (I guess I was off by one in my previous mail). Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] How to turn off +5V supply on AirStar2
e9hack wrote: Klaus Schmidinger wrote: in flexcop-fe-tuner.c I should do Well, or rather bs = ~0x08; to clear P3 (I guess I was off by one in my previous mail). Exactly, I meant that in this way. Ok, I tried that, but now tuning apparently doesn't work any more (no TS data). Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Improved rmmod.pl script
The rmmod.pl script that comes with the current driver source blindly tries to load all modules it can find. While this is good in case one has no idea which modules to load, there's no easy way of finding out exactly which modules need to be loaded to support just the installed hardware (unless I've missed it). The attached version of this script accepts additional parameters, which can be used to specify the top level driver modules to load, and starting from there it loads all other modules that the given ones depend on. For a system with full featured and budget DVB cards, the call might look like this: rmmod.pl load dvb-ttpci budget The modified script also makes sure that the explicitly mentioned modules are loaded in the given sequence, so that the sequence of devices can be defined (for instance making sure that the first device is a full featured card). This also works with 'reload', as in rmmod.pl reload dvb-ttpci budget So this could be the only line necessary in a 'runvdr' script, because it first unloads all given modules and the ones they depend on (if any are loaded) and then loads the given ones plus the ones they depend on. Without the additional parameters the behavior is as before. Maybe this is also useful to others. If so, perhaps it could be checked in to the Mercurial by somebody with write access. Klaus rmmod.pl Description: Perl program ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Driver version 7a0daff8ed2c doesn't compile
Trent Piepho wrote: On Sun, 3 Sep 2006, Klaus Schmidinger wrote: Klaus Schmidinger wrote: I'm trying to compile today's driver (version 7a0daff8ed2c from the Hg) and get the following error: CC [M] /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.o /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c: In function 'snd_bt87x_create_risc': I'm using SUSE Linux 10.0 with kernel 2.6.13. Any ideas what might be wrong here? Looks like a missing #include, but which one? Still the same with today's driver source (54eb9f90c06d). Does anybody have an idea what might be causing this? It looks like this might be a kernel incompatibility. I get the same problem when trying to compile against 2.6.12, but if I try to compile against 2.6.18-rc4 it works. The only thing that seems strange to me is that the first error is because struct snd_sg_buf isn't defined. In 2.6.12, this _is_ defined in the kernel file include/sound/memalloc.h, and bt87x.c _does_ include this file. It's no different than 2.6.18-rc4. So it should work under 2.6.12 (and 2.6.13 too I would assume), but doesn't. I'm not sure what is going on. Something to do with include searching maybe? Nevermind, I simply disabled that module in the config, and now the rest compiles. Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Driver version 7a0daff8ed2c doesn't compile
Klaus Schmidinger wrote: I'm trying to compile today's driver (version 7a0daff8ed2c from the Hg) and get the following error: CC [M] /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.o /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c: In function 'snd_bt87x_create_risc': /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:191: error: dereferencing pointer to incomplete type /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c: In function 'snd_bt87x_interrupt': /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:303: warning: passing argument 1 of 'snd_pcm_period_elapsed' from incompatible pointer type /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c: At top level: /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:308: error: variable 'snd_bt87x_digital_hw' has initializer but incomplete type /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:309: error: unknown field 'info' specified in initializer /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:312: warning: excess elements in struct initializer /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:312: warning: (near initialization for 'snd_bt87x_digital_hw') /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:313: error: unknown field 'formats' specified in initializer /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:313: warning: excess elements in struct initializer /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:313: warning: (near initialization for 'snd_bt87x_digital_hw') /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:314: error: unknown field 'rates' specified in initializer /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:314: warning: excess elements in struct initializer /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:314: warning: (near initialization for 'snd_bt87x_digital_hw') /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:315: error: unknown field 'channels_min' specified in initializer /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:315: warning: excess elements in struct initializer /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:315: warning: (near initialization for 'snd_bt87x_digital_hw') /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:316: error: unknown field 'channels_max' specified in initializer /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:316: warning: excess elements in struct initializer ... (the list goes on for quite a while). I'm using SUSE Linux 10.0 with kernel 2.6.13. Any ideas what might be wrong here? Looks like a missing #include, but which one? Still the same with today's driver source (54eb9f90c06d). Does anybody have an idea what might be causing this? Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] How to compile the firmware into the latest driver?
Trent Piepho wrote: On Monday 28 August 2006 12:43, Klaus Schmidinger wrote: Trent Piepho wrote: On Sun, 27 Aug 2006, Klaus Schmidinger wrote: I want the AV7110 firmware to be compiled into the driver. But I don't seem to be able to make it do that. I tried editing the linux/drivers/media/dvb/ttpci/Kconfig file and changed the default value of DVB_AV7110_FIRMWARE_FILE to point to my firmware file's location, Use make menuconfig or make xconfig and then set the options like you would if you were compilig the kernel. Actually that's what I want to avoid. I want to use an automated process So want you really want to know is how to setup an automated process to give you a special configuration? That's totally different than compiling the firmware into the driver. Well, you're right, sorry about that. You could just configure once, then use hg pull ; hg update to get the latest source. You should be able to build without re-configuring or even re-compiling all the code that didn't change. If you need some automated way to change the configuration. I'd run make allmodconfig first, then edit v4l/.config with sed/perl/whatever. You might be able to just use: echo CONFIG_DVB_AV7110_FIRMWARE=y v4l/.config echo CONFIG_DVB_AV7110_FIRMWARE_FILE=/firmware/file v4l/.config You might need to mantually run make_myconfig.pl after that. Thanks, that works for me. Just in case somebody else is interested, here's my complete script: make allmodconfig rm -f v4l/.config.new echo CONFIG_DVB_AV7110_FIRMWARE=y v4l/.config.new echo CONFIG_DVB_AV7110_FIRMWARE_FILE=/home/kls/vdr/firmware/FW.current v4l/.config.new cat v4l/.config v4l/.config.new mv v4l/.config.new v4l/.config (cd v4l; scripts/make_myconfig.pl) make Also thanks to all others who have responded to my question. Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Driver version 7a0daff8ed2c doesn't compile
I'm trying to compile today's driver (version 7a0daff8ed2c from the Hg) and get the following error: CC [M] /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.o /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c: In function 'snd_bt87x_create_risc': /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:191: error: dereferencing pointer to incomplete type /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c: In function 'snd_bt87x_interrupt': /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:303: warning: passing argument 1 of 'snd_pcm_period_elapsed' from incompatible pointer type /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c: At top level: /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:308: error: variable 'snd_bt87x_digital_hw' has initializer but incomplete type /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:309: error: unknown field 'info' specified in initializer /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:312: warning: excess elements in struct initializer /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:312: warning: (near initialization for 'snd_bt87x_digital_hw') /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:313: error: unknown field 'formats' specified in initializer /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:313: warning: excess elements in struct initializer /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:313: warning: (near initialization for 'snd_bt87x_digital_hw') /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:314: error: unknown field 'rates' specified in initializer /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:314: warning: excess elements in struct initializer /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:314: warning: (near initialization for 'snd_bt87x_digital_hw') /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:315: error: unknown field 'channels_min' specified in initializer /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:315: warning: excess elements in struct initializer /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:315: warning: (near initialization for 'snd_bt87x_digital_hw') /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:316: error: unknown field 'channels_max' specified in initializer /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:316: warning: excess elements in struct initializer ... (the list goes on for quite a while). I'm using SUSE Linux 10.0 with kernel 2.6.13. Any ideas what might be wrong here? Looks like a missing #include, but which one? Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] How to compile the firmware into the latest driver?
Trent Piepho wrote: On Sun, 27 Aug 2006, Klaus Schmidinger wrote: I want the AV7110 firmware to be compiled into the driver. But I don't seem to be able to make it do that. I tried editing the linux/drivers/media/dvb/ttpci/Kconfig file and changed the default value of DVB_AV7110_FIRMWARE_FILE to point to my firmware file's location, Use make menuconfig or make xconfig and then set the options like you would if you were compilig the kernel. Actually that's what I want to avoid. I want to use an automated process that downloads the latest driver source, unpacks it into a new directory, does some magic necessary to have the firmware taken from a custom place and compiled into the driver, and runs the 'make'. I don't want to have to go through any kind of interactive action. Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] How to compile the firmware into the latest driver?
Wolfgang Rohdewald wrote: On Monday 28 August 2006 12:43, Klaus Schmidinger wrote: Trent Piepho wrote: On Sun, 27 Aug 2006, Klaus Schmidinger wrote: I want the AV7110 firmware to be compiled into the driver. But I don't seem to be able to make it do that. I tried editing the linux/drivers/media/dvb/ttpci/Kconfig file and changed the default value of DVB_AV7110_FIRMWARE_FILE to point to my firmware file's location, Use make menuconfig or make xconfig and then set the options like you would if you were compilig the kernel. Actually that's what I want to avoid. I want to use an automated process doesn't make menuconfig only change the .config file? Well, it starts an interactive dialog in which the user must make selections :-(. Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] How to compile the firmware into the latest driver?
I've downloaded the latest driver source (v4l-dvb-79d6a1de784a) from the Mercurial repository, but somehow I have a problem with it. I want the AV7110 firmware to be compiled into the driver. But I don't seem to be able to make it do that. I tried editing the linux/drivers/media/dvb/ttpci/Kconfig file and changed the default value of DVB_AV7110_FIRMWARE_FILE to point to my firmware file's location, and also added 'default y' to DVB_AV7110 to have it activated. After that I did 'make' in the top level directory of the driver source, but it didn't compile the firmware into the av7110.o module. There wasn't even an av7110_firm.h file generated. Looking into the '.myconfig' file in the 'v4l' subdirectory I found CONFIG_DVB_AV7110_FIRMWARE := n which probably explains why it wasn't compiled into the driver. I sure must be doing something wrong here. What I want to do is to download the latest driver source, unpack it, maybe run some script that patches some files in order to have the firmware taken from my custom location, and have it compiled into the driver. All this should be done in batch mode, without me having to respond to any menus or stuff like that. Any idea how this can be achieved? Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Vdr and gcc-4.1.2
Hu-Emulator wrote: Question why is vdr lagging behind the linux kernel's. Well, because I don't install new kernels twice a day ;-) I'm still using kernel 2.6.13. GCC 4.1.2 has been out for quite awhile now. Both kernel-2.6.18, in fact gcc-4.1.2 is required on 2.6.18; and v4l-dvb hg tree compile fine with gcc-4.1.2, but vdr-1.4.1-5 will not. I still have to drop down to gcc-3.4?? Any ideas on this? Why don't you send a patch that makes VDR compile on gcc-4.1.2? Klaus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: a/v-blanking solved
Thomas Schorpp wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Schorpp wrote: | yes, | | my system was just halted on this: | | Jul 18 16:21:38 tom1 vdr[3199]: linking channel 402 from 502 504 516 505 | 506 510 508 509 to 502 504 516 501 505 506 507 510 508 503 509 | | kernel 2.6.7 debian source, vdr 1.3.11. | no more logs. | | ive bigger problems with blanking a/v, the above stall may result from | hardware overheating or power failures: | | now back to kernel 2.4. | UPDATE: just had the opportunity to update vdr to 1.3.12, build on linux 2.6.7, ALL FINE NOW :)) thx to mr.schmidinger. I wouldn't know which change in VDR 1.3.12 should have fixed that... Klaus
[linux-dvb] Re: [OT] Reality
Gavin Hamill wrote: Just a note to say that as I was looking out of the window on the train home yesterday evening, I saw lots of trees flash by very quickly, and I did actually think for a moment that I could see some MPEG2 artefacts on the window probably caused by low bitrate.. Oh dear. Is there any therapy available for this? :) I was under the impression that this is normal here in this Matrix... Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: cam_test cam_set
Francesco wrote: On Sun, 2004-05-09 at 21:04, Marcus Metzler wrote: What kind of card and driver are you using, maybe this is an indicator that there is something wrong with the cam support in the driver. I use dvb-kernel driver from cvs (28/04/2004), libdvb-0.5.4. I downloaded the new version from cvs today but when I load budget-ci I get segmentation fault message. I've recompiled kernel 2.6.5 without IO-APIC support and the when I load cam_set there isn't any error in dmesg out. Tomorrow in evening I test system with Sky smartcard. Hey, is there finally a Videoguard CAM available? Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Calling plugins derived from cOsdObject
[EMAIL PROTECTED] wrote: Hi, I try to call plugins from within a new other plugin. This works fine for those, which are derived from cOsdMenu, but fails for those, which are derived from cOsdObject. The reason behind is, as I think, that it is not possible to assign a value to cMenuMain::pluginOsdObject, since this is private. Is there any other way to call such plugins? Calling plugins from other plugins? What's that? Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: 2.6.6-rc3 is very good!!!
Gregoire Favre wrote: On Sun, May 02, 2004 at 03:40:31PM +0200, Juergen Sauer wrote: Is also vdr alright ? VDR isn't NPTL compatible, you have to run it with: LD_ASSUME_KERNEL=2.4 vdr I'm still waiting for somebody to send me a patch that makes VDR 1.3.6 NPTL compatible (BTW: I was under the impression that verion 1.3.6 already was NPTL compatible). Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Channel change delay with DVB-T
Michal Dobrzynski wrote: Frankly I'd be overjoyed if I only had to wait 3 seconds at channel change :/ I timed it with a stopwatch and it takes at LEAST 5 seconds and sometimes even 8 seconds. I'm sure it wasn't always this slow :/ (ie when I first started dabbling). And it sure as hell was never this slow under Windows back when I tried it. Which version of VDR (if any) are you using? If it is 1.2.x, have you applied the autopid patch? That one is known to slow down channel switching. Can you try VDR 1.3.6? Klaus On 23/04/2004, at 4:38 PM, Adrian P Challinor wrote: I understand the concerns here, but this delay also happens on commercial TV's. I have a fairly expensive Phillips TV with built in DVB-T receiver, and it takes at least three seconds to switch between digital channels. Analogue is instant. Is this something to do with DVB-T encoding? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juri Haberland Sent: Thursday, April 22, 2004 11:08 PM To: [EMAIL PROTECTED] Subject: [linux-dvb] Re: Channel change delay with DVB-T Prakash K. Cheemplavam wrote: Michal Dobrzynski wrote: Hi, I asked this on the VDR mailing list and was redirected here. Is there any way to reduce the massive channel change delays? I am running 2 DVB-T budget cards and one Full Featured DVB-S card for output and channel change times are quite disconcerting. Every time my parents change the channel they have to ask what's wrong as the screen stays black for 4 or 5 seconds (last night it even took 7 seconds a few times). Are you experiencing this with vdr or apps in general? I once had the problem with vdr, when I compiled a 1.2.x version on a NPTL enabled system. Using a NPTL disabled system, vdr tuned very fast. I haven't treid vdr 1.3.x with NPTL, though. I have such delays also with a DVB-T 1.3 premium card. Switching to channels on the same frequency as the previous channel is in general very fast, but switching to another frequency can take up to several seconds until you get a stable picture. This is without NTPL, with Linux kernel 2.4.25, dvb-kernel from 2004-04-13 and VDR 1.2.6 - so nothing fancy. With DVB driver from the DVB branch (aka the old driver) switching was a bit slower but reliable. Cheers, Juri -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Channel change delay with DVB-T
Michal Dobrzynski wrote: I am running VDR 1.3.6 with Update Channels set to no (if that makes a difference). Regards, Michal Well, then I guess it must be a driver issue. Klaus On 23/04/2004, at 5:07 PM, Klaus Schmidinger wrote: Michal Dobrzynski wrote: Frankly I'd be overjoyed if I only had to wait 3 seconds at channel change :/ I timed it with a stopwatch and it takes at LEAST 5 seconds and sometimes even 8 seconds. I'm sure it wasn't always this slow :/ (ie when I first started dabbling). And it sure as hell was never this slow under Windows back when I tried it. Which version of VDR (if any) are you using? If it is 1.2.x, have you applied the autopid patch? That one is known to slow down channel switching. Can you try VDR 1.3.6? Klaus On 23/04/2004, at 4:38 PM, Adrian P Challinor wrote: I understand the concerns here, but this delay also happens on commercial TV's. I have a fairly expensive Phillips TV with built in DVB-T receiver, and it takes at least three seconds to switch between digital channels. Analogue is instant. Is this something to do with DVB-T encoding? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juri Haberland Sent: Thursday, April 22, 2004 11:08 PM To: [EMAIL PROTECTED] Subject: [linux-dvb] Re: Channel change delay with DVB-T Prakash K. Cheemplavam wrote: Michal Dobrzynski wrote: Hi, I asked this on the VDR mailing list and was redirected here. Is there any way to reduce the massive channel change delays? I am running 2 DVB-T budget cards and one Full Featured DVB-S card for output and channel change times are quite disconcerting. Every time my parents change the channel they have to ask what's wrong as the screen stays black for 4 or 5 seconds (last night it even took 7 seconds a few times). Are you experiencing this with vdr or apps in general? I once had the problem with vdr, when I compiled a 1.2.x version on a NPTL enabled system. Using a NPTL disabled system, vdr tuned very fast. I haven't treid vdr 1.3.x with NPTL, though. I have such delays also with a DVB-T 1.3 premium card. Switching to channels on the same frequency as the previous channel is in general very fast, but switching to another frequency can take up to several seconds until you get a stable picture. This is without NTPL, with Linux kernel 2.4.25, dvb-kernel from 2004-04-13 and VDR 1.2.6 - so nothing fancy. With DVB driver from the DVB branch (aka the old driver) switching was a bit slower but reliable. Cheers, Juri -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: budget-ci CI interface testing
Andrew de Quincey wrote: I do not know the protocol well enough, to see the problem, but I think it has something todo with a tcid comparison in cam_set which is not fulfilled. The second possible problem I see is that the dvb_ca_en50221_read_data function is called 1130 times in 12 seconds, but no data is delivered to cam_set after the 7 bytes. I have also seen one time, that every io_poll returned with a time out, also the one after the FR IRQ. And so cam_set never called read and returned errors only. But I have no log of this and I have no access to the machine anymore, because it crashed. I started cam_set, killed it with CTRL+C somewhere between write and read call and started it again. After this procedure the connection was lost. I hope this will help a little bit, I will continue my tests after I have reseted the machine today evening or tomorrow. Thanks very much, I'm hopefully about to start testing this stuff myself soon. Are you using the very latest CVS? I found and fixed a stupid bug yesterday which would explain why dvb_ca_en50221_read_data is called 1130 times in only a few seconds. Since AFAIK the CI code in libdvb originally came from VDR I would appreciate if you could send me a copy of any fixes you make to that code. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: DVB-CI question
Johannes Stezenbach wrote: On Sat, Mar 27, 2004 at 01:18:40PM +, Andrew de Quincey wrote: On Friday 26 March 2004 15:14, Klaus Schmidinger wrote: Strange, from what I know a TPDU can be at most 2048 byte long... Out of interest, where does that 2048 figure come from? I can't see it in EN50221 or R206-001. I'm wondering if its an implementation limit imposed by the av7110 firmware. I can see why it would be like that; it really simplifies the defragmenter (I'll probably do the same myself). However, the worrying thing is that I can't see how the *CAM* knows the maximum TPDU size; there doesn't seem to be a protocol for negotiating it. Can anyone suggest what I'm missing? Hm, unanswered questions... Is there any news about the 2048 limit? Johannes There's a line #define MAX_TPDU_SIZE 2048 /* Maximum size of TPDU */ in ci_link_layer.h of the firmware (hope I'm not violating the NDA too much here... ;-). Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: DVB-CI question
Andrew de Quincey wrote: I've had to write all this horrendously complicated buffering code in order to support the CAM link level interface in the kernel; i.e. taking the multiplexed packet fragments from multiple connection IDs/slots and reassembling them into full packets. This means the code is quite quite nasty; one buffer per connection id PER slot, combined with some complex locking. I've just thought: why don't I just return the fragments, and expect the userspace code to do the defragmentation. Then I could have just two buffers for each CI slot, and virtually no complexity. What do you think? It means it wont work with existing apps until they implement the packet re-assembly code... but thats not exactly hard to do in userspace. I was going to revamp the DVB CI API a bit anyway (all changes will have to be agreed by everyone naturally), so I could easily add a new CI interface type for this. If it's not hard to do in userspace, why is it so hard in the driver? Why should every application implement this by itself? I'd say this should be done by the driver, and the applications shall exchange complete TPDU's with the driver. Or did I misunderstand this and you're talking about something completely different? Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: DVB-CI question
Andrew de Quincey wrote: ... Its just it makes the driver's IO routines _really_ complex, as they have to deal with multiple connections, multiple slots, the possibility that the CAM can be yanked out by the user at any time, and lots of other things. There is a LOT of complex locking involved to ensure it can't break. Add to that the fact that each de-fragmented packet can be up to 65536 bytes, Strange, from what I know a TPDU can be at most 2048 byte long... Maybe you could take a quick look at VDR/ci.c and let me know whether the data VDR exchanges with the CI already consists of the fragements you're referring to. Klaus so at least one of those buffers is needed PER connection PER slot. Adds up to a lot of wasted memory. It would also fix some otherwise unsolvable buffering issues in the driver (or rather, not solvable without some extremely nasty code). IMO, the driver should be as simple as possible. I don't think the CAM interface benefits speed-wise from the reassembly being in the driver, so, apart from saving a little bit of extra code in userspace I can't see any good reason for the reassembly being in the kernel. Each app already has to implement all the other layers of the EN50221 control protocol stack itself; why not this extra bit as well? At the moment, I'm still convinced that this is a good idea. I'm implementing all layers of the EN50021 protocol and the driver in parallel right now, and userspace looks far more suitable for the defragmentation code. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: ttpci firmware building tool?
D. Ratner wrote: In reading up on the drivers and such and I have seen mention of a dvb firmware building tool for ttpci. Is this tool distributed with linuxtv-dvb-1.1.0 driver? If so what is the name of this 'tool'? If not, I assume its on the site somewhere. CVS maybe? What is the name and what do I need to run it for a 2.4 version kernel. See the file scripts/ttpci-firmware.c. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Andrew de Quincey wrote: Cool. The Root/Dpram in your 2003-11-08 DVB snapshot is the same as the ones I extracted from dvb-ttpci-01.fw.gz currently on the website. So its definitely not that; I just wanted to make ABSOLUTELY sure it wasn't some build issue. I'm assuming your 2003-11-08 snapshot works for your DISEQC BTW. Yes, it does. Another difference (though I don't see how it can affect DISEQC, but you never know!): In 1.0.0 and your 2003-11-08 snapsnot, hw_sections = 0 by default In 1.1.0 and CVS, hw_sections = 1 by default BINGO! Andrew, you're the best! I've changed to hw_sections = 0 in the dvb-kernel driver and DiSEqC now works as reliably as with the DVB driver. I then switched the DVB driver to hw_sections = 1 in order to cross check, but the DVB driver still switches DiSEqC reliably, even with hw_sections = 1. Finally, I switched the dvb-kernel driver back to hw_sections = 1 and again DiSEqC didn't work reliably. So apparently the dvb-kernel driver doesn't handle DiSEqC reliably with hw_sections = 1, while in the DVB driver it works with both 0 and 1. I can, of course, use the dvb-kernel driver with hw_sections = 1 (as I always did with the DVB driver) and this solves my immediate problem. However, there must still be something else that influences things here, because in the old (DVB) driver the actual value of hw_sections didn't matter... Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Klaus Schmidinger wrote: Andrew de Quincey wrote: Cool. The Root/Dpram in your 2003-11-08 DVB snapshot is the same as the ones I extracted from dvb-ttpci-01.fw.gz currently on the website. So its definitely not that; I just wanted to make ABSOLUTELY sure it wasn't some build issue. I'm assuming your 2003-11-08 snapshot works for your DISEQC BTW. Yes, it does. Another difference (though I don't see how it can affect DISEQC, but you never know!): In 1.0.0 and your 2003-11-08 snapsnot, hw_sections = 0 by default In 1.1.0 and CVS, hw_sections = 1 by default BINGO! Andrew, you're the best! I've changed to hw_sections = 0 in the dvb-kernel driver and DiSEqC now works as reliably as with the DVB driver. I then switched the DVB driver to hw_sections = 1 in order to cross check, but the DVB driver still switches DiSEqC reliably, even with hw_sections = 1. Finally, I switched the dvb-kernel driver back to hw_sections = 1 and again DiSEqC didn't work reliably. So apparently the dvb-kernel driver doesn't handle DiSEqC reliably with hw_sections = 1, while in the DVB driver it works with both 0 and 1. I can, of course, use the dvb-kernel driver with hw_sections = 1 Sorry, this should of course have been ... hw_sections = 0. (as I always did with the DVB driver) and this solves my immediate problem. However, there must still be something else that influences things here, because in the old (DVB) driver the actual value of hw_sections didn't matter... Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Heino Goldenstein wrote: Hello Klaus, Klaus Schmidinger wrote: Andrew de Quincey wrote: On Saturday 20 March 2004 16:42, Klaus Schmidinger wrote: Andrew de Quincey wrote: From the Dpram checksums I can say that the first one is the one from 2003-09-05, and the second one is the one which is in the 2003-11-08 driver package in my VDR FTP archive. So which is the one you tried in the 1.1.0 driver that had the same firmware version? I'm trying to help you: the most likely (to me) is that something about the firmware is different, even though the versions are the same. I do not have older versions of the firmware. The one that's currently on linuxtv.org has version number 0x261b, the previous one had 0x261a. I have tried both of them, but they behave exactly the same (meaning DiSEqC doesn't work reliably). Cool. The Root/Dpram in your 2003-11-08 DVB snapshot is the same as the ones I extracted from dvb-ttpci-01.fw.gz currently on the website. So its definitely not that; I just wanted to make ABSOLUTELY sure it wasn't some build issue. I'm assuming your 2003-11-08 snapshot works for your DISEQC BTW. Yes, it does. Klaus FWIW: I reviewed your e-mails to understand your SAT-hardwaresetup. From your descriptions I guess you have something like this: some ASCII art:--- |Switch 1 | |E0 10 38 F0|---ZF 1 (e.g. 19,2E low vert.) ---|E0 10 38 F1|---ZF 2 (e.g. 19,2E high vert.) |Relay | |E0 10 38 F2|---ZF 3 (e.g. 19,2E low hor.) DVB-CARD |E0 10 38 F0|---|E0 10 38 F3|---ZF 4 (e.g. 19,2E high hor.) | |--- | |--- |E0 10 38 F1|---|Switch 2 | ---|E0 10 38 F0|---ZF 1 (e.g. 21,5E low vert.) |E0 10 38 F1|---ZF 2 (e.g. 21,5E high vert.) |E0 10 38 F2|---ZF 3 (e.g. 21,5E low hor.) |E0 10 38 F3|---ZF 4 (e.g. 21,5E high hor.) --- but then I think your DiSEqC setup is not matching. For this you need: S19.2E 11700 V 9750 v [E0 10 38 F0] W100 [E0 10 38 F0] S19.2E 9 V 10600 v [E0 10 38 F0] W100 [E0 10 38 F1] S19.2E 11700 H 9750 v [E0 10 38 F0] W100 [E0 10 38 F2] S19.2E 9 H 10600 v [E0 10 38 F0] W100 [E0 10 38 F3] S21.5E 11700 V 9750 v [E0 10 38 F1] W100 [E0 10 38 F0] S21.5E 9 V 10600 v [E0 10 38 F1] W100 [E0 10 38 F1] S21.5E 11700 H 9750 v [E0 10 38 F1] W100 [E0 10 38 F2] S21.5E 9 H 10600 v [E0 10 38 F1] W100 [E0 10 38 F3] Maybe the relay is only a mini-DiSEqC-relay (aka tonburst) then you need: S19.2E 11700 V 9750 v A W100 [E0 10 38 F0] S19.2E 9 V 10600 v A W100 [E0 10 38 F1] S19.2E 11700 H 9750 v A W100 [E0 10 38 F2] S19.2E 9 H 10600 v A W100 [E0 10 38 F3] S21.5E 11700 V 9750 v B W100 [E0 10 38 F0] S21.5E 9 V 10600 v B W100 [E0 10 38 F1] S21.5E 11700 H 9750 v B W100 [E0 10 38 F2] S21.5E 9 H 10600 v B W100 [E0 10 38 F3] --^ I know you compiled that hardwired in, but I like it explicit. According to the DiSEqC Application Information for Tuner-Receivers/IRDS, page 13, may setup should be correct. The relay is configured to react on DiSEqC Option A/B, and according to the DiSEqC specs the values F0..F7 imply Option A, while F8..FF imply Option B. So with a sequence like [E0 10 38 F0] W100 [E0 10 38 F0] the first [E0 10 38 F0] goes to the relay, which switches to the first switch (Option A), then (after 100ms) the same sequence is repeated and reaches the switch. The switch then goes to satellite position A, polarization V, frequency Low. The dvb-kernel driver works fine now with hw_sections = 0 (see the other postings in this thread). Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Heino Goldenstein wrote: Hello Klaus, Klaus Schmidinger wrote: Heino Goldenstein wrote: ---8-8-8-8-8-8-8-8-8-8--- FWIW: I reviewed your e-mails to understand your SAT-hardwaresetup. From your descriptions I guess you have something like this: some ASCII art:--- |Switch 1 | |E0 10 38 F0|---ZF 1 (e.g. 19,2E low vert.) ---|E0 10 38 F1|---ZF 2 (e.g. 19,2E high vert.) |Relay | |E0 10 38 F2|---ZF 3 (e.g. 19,2E low hor.) DVB-CARD |E0 10 38 F0|---|E0 10 38 F3|---ZF 4 (e.g. 19,2E high hor.) | |--- | |--- |E0 10 38 F1|---|Switch 2 | ---|E0 10 38 F0|---ZF 1 (e.g. 21,5E low vert.) |E0 10 38 F1|---ZF 2 (e.g. 21,5E high vert.) |E0 10 38 F2|---ZF 3 (e.g. 21,5E low hor.) |E0 10 38 F3|---ZF 4 (e.g. 21,5E high hor.) --- but then I think your DiSEqC setup is not matching. For this you need: S19.2E 11700 V 9750 v [E0 10 38 F0] W100 [E0 10 38 F0] S19.2E 9 V 10600 v [E0 10 38 F0] W100 [E0 10 38 F1] S19.2E 11700 H 9750 v [E0 10 38 F0] W100 [E0 10 38 F2] S19.2E 9 H 10600 v [E0 10 38 F0] W100 [E0 10 38 F3] S21.5E 11700 V 9750 v [E0 10 38 F1] W100 [E0 10 38 F0] S21.5E 9 V 10600 v [E0 10 38 F1] W100 [E0 10 38 F1] S21.5E 11700 H 9750 v [E0 10 38 F1] W100 [E0 10 38 F2] S21.5E 9 H 10600 v [E0 10 38 F1] W100 [E0 10 38 F3] Maybe the relay is only a mini-DiSEqC-relay (aka tonburst) then you need: S19.2E 11700 V 9750 v A W100 [E0 10 38 F0] S19.2E 9 V 10600 v A W100 [E0 10 38 F1] S19.2E 11700 H 9750 v A W100 [E0 10 38 F2] S19.2E 9 H 10600 v A W100 [E0 10 38 F3] S21.5E 11700 V 9750 v B W100 [E0 10 38 F0] S21.5E 9 V 10600 v B W100 [E0 10 38 F1] S21.5E 11700 H 9750 v B W100 [E0 10 38 F2] S21.5E 9 H 10600 v B W100 [E0 10 38 F3] --^ I know you compiled that hardwired in, but I like it explicit. According to the DiSEqC Application Information for Tuner-Receivers/IRDS, page 13, may setup should be correct. The relay is configured to react on DiSEqC Option A/B, and according to the DiSEqC specs the values F0..F7 imply Option A, while F8..FF imply Option B. So with a sequence like [E0 10 38 F0] W100 [E0 10 38 F0] the first [E0 10 38 F0] goes to the relay, which switches to the first switch (Option A), then (after 100ms) the same sequence is repeated and reaches the switch. The switch then goes to satellite position A, polarization V, frequency Low. The dvb-kernel driver works fine now with hw_sections = 0 (see the other postings in this thread). Klaus you are right, I had to guess your hardware setup. Your setup is working, but I like the explicit approach because it is more obvious what is going on. In your case I had done it the following way: some ASCII art:--- |Switch 1 | |E0 10 38 F0|---ZF 1 (e.g. 19,2E low vert.) ---|E0 10 38 F1|---ZF 2 (e.g. 19,2E high vert.) |Relay | |E0 10 38 F2|---ZF 3 (e.g. 19,2E low hor.) DVB-CARD |E0 10 38 F0|---|E0 10 38 F3|---ZF 4 (e.g. 19,2E high hor.) | |--- | |--- |E0 10 38 F8|---|Switch 2 | ---|E0 10 38 F0|---ZF 1 (e.g. 21,5E low vert.) |E0 10 38 F1|---ZF 2 (e.g. 21,5E high vert.) |E0 10 38 F2|---ZF 3 (e.g. 21,5E low hor.) |E0 10 38 F3|---ZF 4 (e.g. 21,5E high hor.) --- S19.2E 11700 V 9750 v [E0 10 38 F0] W100 [E0 10 38 F0] S19.2E 9 V 10600 v [E0 10 38 F0] W100 [E0 10 38 F1] S19.2E 11700 H 9750 v [E0 10 38 F0] W100 [E0 10 38 F2] S19.2E 9 H 10600 v [E0 10 38 F0] W100 [E0 10 38 F3] S21.5E 11700 V 9750 v [E0 10 38 F8] W100 [E0 10 38 F0] S21.5E 9 V 10600 v [E0 10 38 F8] W100 [E0 10 38 F1] S21.5E 11700 H 9750 v [E0 10 38 F8] W100 [E0 10 38 F2] S21.5E 9 H 10600 v [E0 10 38 F8] W100 [E0 10 38 F3] But wouldn't this mean that, if Switch 1 is currently at ZF 2 and I want to tune to a channel on ZF 3, the following would happen: - The first sequence of E0 10 38 F0 goes to the relay as well as Switch 1, so the relay switches to Switch 1 (which it already was, so no change), and Switch 1 will switch to ZF 0 (which is not what I want). - The second sequence of E0 10 38 F2 also
[linux-dvb] Re: DVB Branch
Kenneth Aafløy wrote: Hi, I was wondering about when the DVB branch will be phased out of development? Essentially, it's not really needed anymore, since the 1.1.0 release is out, or are you just keeping it around for incompatability reasons? What about just tarring up the DVB branch for reference at linuxtv.org, and removing the old stuff from CVS? Kenneth Let's not repeat the Toll-Collect disaster ;-) They dropped a working system _before_ the new system ran stable... Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Johannes Stezenbach wrote: Andrew de Quincey wrote: its not the firmware. its not the frontend driver (that was a different issue). well, pretty obvious where it has to be really; must be a card setup problem in the OSS code. I'll have a closer check over the next few days. Like I said before, DiSEqC was always unreliable with my ves1893 card, but I don't know if it is a general problem or if just my card is broken. Anyway, today I got a DiSEqC test box from Eutelsat, and it does not even recognize a single valid bit of DiSEqC data. It recognizes 13(18 volt and tone on/off, so I guess the timings of our DiSEqC stuff must be totally off. I didn't have the time to connect an oscilloscope to investigate further. Maybe tomorrow. The little Spaun DiSEqC test box I use normally recognizes the DiSEqC sequences most of the time, but it is probably much more tolerant that the Eutelsat test box. Same with my DiSEqC tester. With the DVB driver it detects the signals correctly every time, with dvb-kernel only sometimes. Does someone know for sure how the DiSEqC signals for a ttpci rev1.3 card with ves1893 are generated? Is this different from all other cards? From what I can see in the driver source, on AV7110 based cards the actual DiSEqC signal is generated fom inside the firmware. But since the firmware hasn't changed between the latest DVB driver and dvb-kernel (at least as far as i know) I would assume that the actual signal the firmware generates should still be the same. Unless, of course, some other setup stuff interferes with that... Is there something about the COMTYPE_AUDIODAC stuff that's done differently in dvb-kernel and could break the generation of the DiSEqC signal? Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Andrew de Quincey wrote:
the actual DiSEqC signal is generated fom inside the firmware.
But since the firmware hasn't changed between the latest DVB driver
and dvb-kernel (at least as far as i know) I would assume that
the actual signal the firmware generates should still be the same.
Unless, of course, some other setup stuff interferes with that...
Is there something about the COMTYPE_AUDIODAC stuff that's done
differently in dvb-kernel and could break the generation of the
DiSEqC signal?
I had a quick look through; the functions themselves have all been reorganised
into seperate files for clarity, but the code within the functions is pretty
much identical. Unfortunately this means the use of diff is limited... I'll
try something more sophisticated later.
I found one difference though:
in 1.0.0, av7110.c/av7110_before_after_tune():
if (av7110-fe_synced) {
.
} else
SetPIDs(av7110, 0, 0, 0, 0, 0);
in 1.1.0, av7110.c/av7110_before_after_tune():
if (av7110-fe_synced) {
.
} else {
SetPIDs(av7110, 0, 0, 0, 0, 0);
av7110_fw_cmd(av7110, COMTYPE_PIDFILTER, FlushTSQueue, 0);
}
This change was done to avoid glitches in recordings on the primary device
in case the channel is switched.
Does it change anyting (DiSEqC wise) if you comment that line out?
Klaus
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as
subject.
[linux-dvb] Re: Full featured card summary
Andrew de Quincey wrote: This change was done to avoid glitches in recordings on the primary device in case the channel is switched. Does it change anyting (DiSEqC wise) if you comment that line out? No idea, sorry, I only have budget cards; I'm just suggesting things. I tried it now, but it makes no difference. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Andrew de Quincey wrote: Incidentally, even though the firmwares used by 1.0.0 and 1.1.0 have the same version number, they are _not_ the same. 1.0.0 had two seperate files, Dpram and Root 1.1.0 has a combined file, dvb-ttpci-01.fw However the file format of dvb-ttpci-01.fw is obvious: 4 byte magic 4 byte number (probably a date) 4 byte length of Dpram Dpram data Root data I extracted the Dpram and Root from dvb-ttpci-01.fw. Additionally, the two Roots are slightly different lengths, but the end of the file is full of padding. I chopped a bytes off the end of each so they were the same length (this is the Root2 below). Results: 1.0.0: [EMAIL PROTECTED] av7110]$ md5sum Dpram 65edabe40061f0e5b0a5d2eb6cbf9132 Dpram [EMAIL PROTECTED] av7110]$ md5sum Root2 abfbffc0bef9fde14e5eb28ad6da66c0 Root2 1.1.0: [EMAIL PROTECTED] build-2.4]$ md5sum Dpram 24b2e6e396d18883074aa88879094999 Dpram [EMAIL PROTECTED] build-2.4]$ md5sum Root2 b8668b7f2a744a254d3e49409dcde813 Root2 The md5sums of the Root files don't correspond to any of the Root files I have. Maybe you chopped off a few bytes too many. From the Dpram checksums I can say that the first one is the one from 2003-09-05, and the second one is the one which is in the 2003-11-08 driver package in my VDR FTP archive. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Andrew de Quincey wrote: On Saturday 20 March 2004 15:26, Andrew de Quincey wrote: Incidentally, even though the firmwares used by 1.0.0 and 1.1.0 have the same version number, they are _not_ the same. 1.0.0 had two seperate files, Dpram and Root 1.1.0 has a combined file, dvb-ttpci-01.fw Actually maybe I have a slightly newer dvb-ttpci-01.fw; no idea how old the one I have is. Can you send me the version you said had the same version number so I can check it? I believe the file http://linuxtv.org/download/dvb/dvb-ttpci-01.fw.gz now contains the latest firmware version (the previous file was not gzipped). Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Andrew de Quincey wrote: From the Dpram checksums I can say that the first one is the one from 2003-09-05, and the second one is the one which is in the 2003-11-08 driver package in my VDR FTP archive. So which is the one you tried in the 1.1.0 driver that had the same firmware version? I'm trying to help you: the most likely (to me) is that something about the firmware is different, even though the versions are the same. I do not have older versions of the firmware. The one that's currently on linuxtv.org has version number 0x261b, the previous one had 0x261a. I have tried both of them, but they behave exactly the same (meaning DiSEqC doesn't work reliably). Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Andrew de Quincey wrote: On Saturday 20 March 2004 16:42, Klaus Schmidinger wrote: Andrew de Quincey wrote: From the Dpram checksums I can say that the first one is the one from 2003-09-05, and the second one is the one which is in the 2003-11-08 driver package in my VDR FTP archive. So which is the one you tried in the 1.1.0 driver that had the same firmware version? I'm trying to help you: the most likely (to me) is that something about the firmware is different, even though the versions are the same. I do not have older versions of the firmware. The one that's currently on linuxtv.org has version number 0x261b, the previous one had 0x261a. I have tried both of them, but they behave exactly the same (meaning DiSEqC doesn't work reliably). Cool. The Root/Dpram in your 2003-11-08 DVB snapshot is the same as the ones I extracted from dvb-ttpci-01.fw.gz currently on the website. So its definitely not that; I just wanted to make ABSOLUTELY sure it wasn't some build issue. I'm assuming your 2003-11-08 snapshot works for your DISEQC BTW. Yes, it does. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Andrew de Quincey wrote: Ok, so I have changed the DiSEqC setup in my VDR to S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t S19.2E 9 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t S19.2E 9 H 10600 t V W15 [E0 10 38 F3] W15 A W15 T which should be what the spec requires, right? Not much to my surprize this doesn't work, either. The multiswitch I use ignores any analog switching stuff as soon as it receives the first actual DiSEqC sequence. So doing the t-v-A-t dance doesn't make any sense. I also updated the driver to the latest CVS (2004-03-15, 17:31), compiled both driver and VDR newly, but there was no improvement. So all I can say is that I still believe DiSEqC handling is broken in the current dvb-kernel driver. Would you mind trying my suggestion of using the av7110 firmware from 1.0.1 in 1.1.0? Its the only thing I can see that might be different. The firmware that was originally on linuxtv.org for use with dvb-kernel 1.1.0 had version 0x261a, and thus was exactly the same as used in dv-kernel 1.0.1. So from what I can see the problem is definitely not in the firmware, because with the exact same firmware the DVB driver works fine here, but dvb-kernel does not. Since I am using a different hardware than my normal VDR machine for this, I have now explicitly tried the DVB driver on that hardware, and DiSEqC works just fine there with my setup S19.2E 11700 V 9750 [E0 10 38 F0] W100 [E0 10 38 F0] S19.2E 9 V 10600 [E0 10 38 F1] W100 [E0 10 38 F1] S19.2E 11700 H 9750 [E0 10 38 F2] W100 [E0 10 38 F2] S19.2E 9 H 10600 [E0 10 38 F3] W100 [E0 10 38 F3] Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Holger Waechtler wrote: On Monday 15 March 2004 00:13, Klaus Schmidinger wrote: Holger Waechtler wrote: The DiSEqC spec requires you to set the appropriate bus voltage before a DiSEqC command is sent. It also requires that the old-style SEC and DiSEqC commands are sent compatibly, the behaviour of switches, rotors and LNBs is not defined if the content of SEC and DiSEqC sequence don't match. The SEC sequence is mandatory (Voltage, tone and burst). See the DiSEqC Update and Recommendations for Implementations on the Eutelsat website: http://www.eutelsat.org/satellites/pdf/Diseqc/associated docs/update_recomm_for_implim.pdf, page 36. Also check out dvb-apps/test/diseqc.c for a reference implementation. But my DiSEqC equipment _does_ work fine with the DVB driver and sending plain hex codes (like [E0 10 38 F3]). The LNB power issue has been resolved by explicitly turning it on in VDR, so I would expect the DiSEqC equipment to work with dvb-kernel - but it doesn't (at least not reliably) if it worked before it was pure luck -- if you prefer deterministic behaviour should follow the spec... Holger Ok, so I have changed the DiSEqC setup in my VDR to S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t S19.2E 9 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t S19.2E 9 H 10600 t V W15 [E0 10 38 F3] W15 A W15 T which should be what the spec requires, right? Not much to my surprize this doesn't work, either. The multiswitch I use ignores any analog switching stuff as soon as it receives the first actual DiSEqC sequence. So doing the t-v-A-t dance doesn't make any sense. I also updated the driver to the latest CVS (2004-03-15, 17:31), compiled both driver and VDR newly, but there was no improvement. So all I can say is that I still believe DiSEqC handling is broken in the current dvb-kernel driver. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Johannes Stezenbach wrote: Klaus Schmidinger wrote: Holger Waechtler wrote: On Sunday 14 March 2004 23:55, Andrew de Quincey wrote: The problem with 1.1.0 is VDR isn't doing the full DISEQC init sequence, and so no voltage was ever being sent to the LNB. that's definitely illegal. Note that I _do_ turn on LNB power now when setting up the devices in VDR. Just to make sure: You also must wait some msec after turning the power on before sending the first DiSEqC command. Johannes This is implicitly the case because first the devices are initialized one by one, and then (a few seconds later) the first actual channel switch occurs. Besides, even with the DiSEqC setup S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t S19.2E 9 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t S19.2E 9 H 10600 t V W15 [E0 10 38 F3] W15 A W15 T (which definitely explicitly waits 15ms before sending any DiSEqC sequence) it doesn't work (see my reply to Holger's mail). Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Helmut Auer wrote: Hi, The diseqc settings: S19.2E 11700 V 9750 v [E0 10 38 F0] [E1 10 38 F0] [E1 10 38 F0] is not working perfectly. Sometimes when switching from h to v or vice versa its not working. Then I added W15: S19.2E 11700 V 9750 v W15 [E0 10 38 F0] [E1 10 38 F0] [E1 10 38 F0] and this seems to work fine. Where can I read what all these parameters are doing ? http://www.eutelsat.com/satellites/4_5_5.html Get the Bus Specification PDF file. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Helmut Auer wrote: Hi, One ( hopefully ) last point: It often happens after startup the first channel is not displayed by vdr, that means, I have to switch once and the everything works fine. Is that a vdr or dvb problem ? If DiSEqC switching doesn't work reliably I'd say it's a DVB problem. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Andrew de Quincey wrote: The two combinations below are working with the _unmodified_ ves1x93 code and also with my alps_bsvr2 mod. S13E11700 V 9750 v [E0 10 38 F0] S13E9 V 10600 v [E0 10 38 F1] S13E11700 H 9750 v [E0 10 38 F2] S13E9 H 10600 v [E0 10 38 F3] S19.2E 11700 V 9750 v [E0 10 38 F4] S19.2E 9 V 10600 v [E0 10 38 F5] S19.2E 11700 H 9750 v [E0 10 38 F6] S19.2E 9 H 10600 v [E0 10 38 F7] S13E11700 V 9750 v [E0 10 38 F0] [E1 10 38 F0] [E1 10 38 F0] S13E9 V 10600 v [E0 10 38 F1] [E1 10 38 F1] [E1 10 38 F1] S13E11700 H 9750 v [E0 10 38 F2] [E1 10 38 F2] [E1 10 38 F2] S13E9 H 10600 v [E0 10 38 F3] [E1 10 38 F3] [E1 10 38 F3] S19.2E 11700 V 9750 v [E0 10 38 F4] [E1 10 38 F4] [E1 10 38 F4] S19.2E 9 V 10600 v [E0 10 38 F5] [E1 10 38 F5] [E1 10 38 F5] S19.2E 11700 H 9750 v [E0 10 38 F6] [E1 10 38 F6] [E1 10 38 F6] S19.2E 9 H 10600 v [E0 10 38 F7] [E1 10 38 F7] [E1 10 38 F7] @Andrew: Thanks for code-digging that much. Do you understand the difference? I get you, its the 'v'. Previously the driver was turning voltage on when it started up, so power was being supplied, whereas now by default leaves it off. So this means VDR should turn the voltage _on_ upon startup, right? I don't think having to do this via the DiSEqC configuration is the way to go... One question though (I've never had any experience with VDR/DISEQC2.0), what does the frequency of 9 do? is it for when switching away from a channel? man 5 vdr: ... Following is the switch frequency of the LNB (slof), which is the transponder frequency up to which this entry shall be used; the first entry with an slof greater than the actual transponder frequency will be used. Typically there is only one slof per LNB, but the syntax allows any number of frequency ranges to be defined. Note that there should be a last entry with the value 9 for each satellite, which covers the upper frequency range. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Johannes Stezenbach wrote: Klaus Schmidinger wrote: Andrew de Quincey wrote: I get you, its the 'v'. Previously the driver was turning voltage on when it started up, so power was being supplied, whereas now by default leaves it off. So this means VDR should turn the voltage _on_ upon startup, right? I don't think having to do this via the DiSEqC configuration is the way to go... Hm, it's been a while since I read the DiSEqC spec, but IIRC the sequence is: - turn off 22KHz - set voltage to 13V or 18V - send DiSEqC sequence - if necessary turn on 22KHz It doesn't make much sense to remove the power from the LNB while sending the DiSEqC sequence, but luckily vdr doesn't seem to do that ;-) So, I guess that 'v' is a no-op. 'v' means voltage low (13V) 'V' means voltage high (18V) So if there was no voltage before, 'v' will turn on the low voltage. There are some mandatory delays before and after sending the DiSEqC sequence. The Nokia API rolled all that in a simple and convenient ioctl which would allow the driver to do all the timing (so that applications cannot fuck up), but Holger removed it. Why did he do that? Doesn't make any sense to me...?! Any chance we'll get that back - or do we have to live with the fact that Holger has f*cked up the DiSEqC handling? Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Holger Waechtler wrote: On Sunday 14 March 2004 23:02, Klaus Schmidinger wrote: There are some mandatory delays before and after sending the DiSEqC sequence. The Nokia API rolled all that in a simple and convenient ioctl which would allow the driver to do all the timing (so that applications cannot fuck up), but Holger removed it. @Johannes: behave. Why did he do that? Doesn't make any sense to me...?! The required delays, the number of required message repetitions depend on the actual setup. The old-fashioned API was not able to handle anything but simple non-cascaded switches. Well, I have a setup with two multiswitches behind a DiSEqC relay, and that workes just fine with the DVB driver. So I would have expected that to still work with the dvb-kernel driver. Please check the DiSEqC spec for details. Any chance we'll get that back - or do we have to live with the fact that Holger has f*cked up the DiSEqC handling? ?!? Sorry, didn't mean to be offensive - it's just that I've finally spent the time this weekend to set up a machine where I can test the dvb-kernel driver, and it appeared to work fine, except for DiSEqC support. Since there have been quite a few guesses why this has been broken between the DVB and the dvb-kernel driver and AFAIK none of them fixed the problem, I thought this would have been the actual cause... Not without removing the ability to be DiSEqC 2.x compliant and to support anything else beside the standard single-switch, unidirectional DiSEqC 1.0 setup. Those changes have been introduced about 2 years ago, proper rotor support and support for cascaded DiSEqC devices would never have been possible without. Bidirectional DiSEqC support neither. Can you please explain a little more in detail what exactly is your problem and why it never showed up before? Up to now I have been (and still am) using the DVB driver 2003-11-08 and my cascaded DiSEqC setup works just fine with it. With the dvb-kernel driver (version as of friday afternoon) the DiSEqC signal is sometimes sent so that the relay and switch react correctly, and sometimes not. My DiSEqC tester sometimes displays weird combinations of LEDs (that don't make sense), and sometimes when switching polarizations there is no change in the tester's LEDs at all. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Johannes Stezenbach wrote: Klaus Schmidinger wrote: Johannes Stezenbach wrote: It doesn't make much sense to remove the power from the LNB while sending the DiSEqC sequence, but luckily vdr doesn't seem to do that ;-) So, I guess that 'v' is a no-op. 'v' means voltage low (13V) 'V' means voltage high (18V) So if there was no voltage before, 'v' will turn on the low voltage. Right. I checked vdr source again, and now see how it works. I would think the frontend driver should power up the LNB upon open, and power it down after close. I'd think so, too. Without LNB power there's not much you can do, anyway... There are some mandatory delays before and after sending the DiSEqC sequence. The Nokia API rolled all that in a simple and convenient ioctl which would allow the driver to do all the timing (so that applications cannot fuck up), but Holger removed it. Why did he do that? Doesn't make any sense to me...?! Any chance we'll get that back - or do we have to live with the fact that Holger has f*cked up the DiSEqC handling? Nokia specified the ioctl to run asynchronous, which causes some headaches for implementation. The current API also is more flexible and simpler, but forces every programmer to scrutinize the DiSEqC spec to use it right. The old API also made it difficult to integrate DiSEqC 2.0. For reference, the old API was in sec.h: http://linuxtv.org/cgi-bin/cvsweb.cgi/DVB/ost/include/ost/?hideattic=0#dirlist When I compiled the latest VDR developer version with the dvb-kernel header files, everything compiled just fine - so I would assume that there was no change in the API (besides, it has always been emphasized that the API did not change between DVB and dvb-kernel). Sendeing DiSEqC codes in VDR is done via the ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd)); call - is this no longer the way to go? Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Holger Waechtler wrote: On Sunday 14 March 2004 23:35, Andrew de Quincey wrote: If you specify a bus voltage of 13 or 18V you definitely don't mean VOLTAGE_OFF but expect the LNBP working, everything else is a bug. Yeah, it seemed to have changed from being set to VOLTAGE_13 in the initialisation tables to being set to VOLTAGE_OFF by default... somewhere between the 1.0.1 and the 1.1.0 release. Defaulting to VOLTAGE_OFF makes sense though; no point powering up the LNB until its actually needed. What do you think of Johannes' idea of it auto powering up on frontend open? makes not really sense -- you can't really tune a LNB wothout setting up polarisation plane and the band selection switch before, can't you? As soon you submit the polarisation selection command (VOLTAGE_13V or VOLTAGE_18V) you already powered up the LNB. The only important thing is to maintain the delay times required by the spec, the diseqc.c example shows how this can get implemented. With the DVB driver I am able to use a VDR DiSEqC setup like S19.2E 11700 V 9750 [E0 10 38 F0] W100 [E0 10 38 F0] S19.2E 9 V 10600 [E0 10 38 F1] W100 [E0 10 38 F1] S19.2E 11700 H 9750 [E0 10 38 F2] W100 [E0 10 38 F2] S19.2E 9 H 10600 [E0 10 38 F3] W100 [E0 10 38 F3] here the sequence [E0 10 38 F0] is sent, followed by a 100ms wait, and then [E0 10 38 F0] is repeated because the multiswitch is behind a DiSEqC relay. There's no need for explicit tone or voltage switching here. So I would say that activating the power supply to the LNB should be done automatically when the frontend is opened. As a workaround in VDR 1.3.6 I have added a call to ioctl(fd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_13) when opening the device, but I think this shouldn't be necessary. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Johannes Stezenbach wrote: Klaus Schmidinger wrote: Johannes Stezenbach wrote: Nokia specified the ioctl to run asynchronous, which causes some headaches for implementation. The current API also is more flexible and simpler, but forces every programmer to scrutinize the DiSEqC spec to use it right. The old API also made it difficult to integrate DiSEqC 2.0. For reference, the old API was in sec.h: http://linuxtv.org/cgi-bin/cvsweb.cgi/DVB/ost/include/ost/?hideattic=0#dirlist When I compiled the latest VDR developer version with the dvb-kernel header files, everything compiled just fine - so I would assume that there was no change in the API (besides, it has always been emphasized that the API did not change between DVB and dvb-kernel). The Nokia API was the ancient API (devices in /dev/ost/ etc.). There is no API change bewteen recent DVB and dvb-kernel. Sorry if I confused you. Well, then there must still be some bug that keeps DiSEqC from working in the dvb-kernel driver. I have changed VDR today so that it explicitly turns on LNB power at startup, but the DiSEqC switching is still totally unreliable. I'll give this another try next weekend... Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Andrew de Quincey wrote: On Sunday 14 March 2004 22:47, Holger Waechtler wrote: On Sunday 14 March 2004 23:46, Andrew de Quincey wrote: On Sunday 14 March 2004 22:36, Holger Waechtler wrote: As soon you submit the polarisation selection command (VOLTAGE_13V or VOLTAGE_18V) you already powered up the LNB. The only important thing is to maintain the delay times required by the spec, the diseqc.c example shows how this can get implemented. I think the problem was they're using DISEQC 1.0/2.0 switches, but weren't using the older voltage-based polarisation selection commands, assuming that the frontend would have automatically applied some power to the LNB (BTW: I do know the sequence in the DISEQC spec says you should specify the voltage; I use that exact sequence in my code). The DiSEqC spec explicitly requires you to set up a bus voltage of 13 or 18V and wait a little before submitting any command. I suppose its a matter of how tolerant we want to be of userspace programs.. I mean, we already turn OFF the LNB power automatically, why not turn it on as well? we do, a LNB power switch is automatically enabled as soon a voltage != 0V is specified by all drivers I'm aware of. Did not checked the latest changes though, if the VES1x93 does not do so anymore it needs to get fixed, you should set the GPIO line high that is connected to the LNBP as soon any bus voltage != 0V is requested. Yeah, it does. The issue is as follows: driver 1.0.1: ves1x93 set the LNB voltage to 13v as soon as the driver was loaded. When you select the voltage, it sets the correct GPIO driver 1.1.0: ves1x93 was changed so it left the voltage at 0v when the driver was loaded. When you select the voltage, it sets the correct GPIO The problem with 1.1.0 is VDR isn't doing the full DISEQC init sequence, and so no voltage was ever being sent to the LNB. So its really a fixed driver bug clashing with an issue in VDR. As of version 1.3.6 VDR explicitly turns on the LNB power at startup (which I believe the driver should do when the frontend is opened), but that didn't fix the actual DiSEqC problem (unreliable switching). Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Andreas Oberritter wrote: Hi, On Sun, 2004-03-14 at 23:46, Andrew de Quincey wrote: I suppose its a matter of how tolerant we want to be of userspace programs.. I mean, we already turn OFF the LNB power automatically, why not turn it on as well? I don't care much, but please don't change the voltage setting in the inittab, because it breaks support for the ves1893 and ves1993 on the other (non-pci) boards, where the gpio pins toggled by this register have a different meaning. If you decide to set the voltage of all frontends to 13V at open(), then checking for O_RDWR should be sufficient to decide, because only one writer is allowed. However, I don't like that idea. It makes it impossible to stay at 0V, when the frontend is connected to a loop through output of another receiver, which shall not be disturbed. Userspace apps can choose the desired voltage anyway after opening the device. Ok, if it is defined behaviour that the driver does _not_ turn on LNB power when opening the frontend, that's fine with me - I have a workaround in VDR now. I just wasn't aware of this change, and apparently it has nothing to do with the actual problem of DiSEqC switching being unreliable with dvb-kernel. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Problems with 1.1.1
Helmut Auer wrote: Hi Oliver, diseqc.conf S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t S19.2E 9 V ... It seems to be that switching to vertical position kills everything. Maybe timing has changed slightly (for whatever reason). Try to optimize your DiSEqC setup. This might speed-up tuning: full DiSEqC sequence: S19.2E 11700 V 9750 [E0 10 38 F0] [E1 10 38 F0] [E1 10 38 F0] S19.2E 9 V 10600 [E0 10 38 F1] [E1 10 38 F1] [E1 10 38 F1] S19.2E 11700 H 9750 [E0 10 38 F2] [E1 10 38 F2] [E1 10 38 F2] S19.2E 9 H 10600 [E0 10 38 F3] [E1 10 38 F3] [E1 10 38 F3] I'm using this setup for a long time now (vdr 1.1.x). It works perfectly. After switchin to vdr 1.1.x I tried a lot of diseqc settings, and the one I posted was working best. Now with dvb drivers 1.1.x it works sometimes, but when switching polarisation it doesn't work most times. I also tried your diseqc setiings, but with these I can't switch to any channel ! -- Helmut Auer, [EMAIL PROTECTED] I can confirm this. Yesterday I have set up a new machine with SuSE 8.2 (kernel 2.4.20) and a Siemens DVB-S rev 1.3 card. Driver is the dvb-kernel version from yesterday's CVS. In case it matters, here's the list of modules that are loaded: Module Size Used byNot tainted dvb-ttpci 282964 4 ttpci-eeprom1296 0 [dvb-ttpci] saa7146_vv 34780 0 [dvb-ttpci] saa714610464 0 [dvb-ttpci saa7146_vv] mt312 4556 0 cx24110 5476 0 grundig_29504-491 3108 0 grundig_29504-401 3852 0 tda1004x 10832 0 ves1820 4512 0 stv0299 9164 0 (unused) alps_tdmb7 3592 0 alps_tdlb7 5176 0 ves1x93 4496 1 dvb-core 38792 14 [dvb-ttpci mt312 cx24110 grundig_29504-491 grundig_29504-401 tda1004x ves1820 stv0299 alps_tdmb7 alps_tdlb7 ves1x93] video-buf 10420 0 [saa7146_vv] v4l2-common 2880 0 [saa7146_vv] v4l1-compat12680 0 [saa7146_vv] videodev5600 1 [saa7146_vv] evdev 4032 0 (unused) input 3104 0 [dvb-ttpci evdev] ipv6 134516 -1 (autoclean) af_packet 12392 1 (autoclean) 8139too14696 1 mii 2304 0 [8139too] ext3 77288 1 jbd45584 1 [ext3] I have inserted a DiSEqC tester into the sat cable and can see that when switching polarization it doesn't send the correct DiSEqC commands, because the tester still displays the previous polarization. Sometimes the switching does work, sometimes not. There are even cases where some of the other LEDs on the tester light up, like Reply OK, which, I believe, indicates that the DiSEqC sequence actually sent is broken in some way. I am using the exact same diseqc.conf with VDR 1.3.5 as I do on my other machine with the DVB driver on SuSE 7.3, kernel 2.4.10. When I switch to not using DiSEqC (just 14/18V, 22kHz) everything works just fine. So, in order to use the latest dvb-kernel driver in a DiSEqC environment, something needs to be fixed here. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: dvb-kernel: old firmware
Johannes Stezenbach wrote: Klaus Schmidinger wrote: Ok, so I've set up a machine with SuSE 8.2, kernel 2.4.20, fetched the dvb-kernel driver from today's CVS and the firmware from http://www.linuxtv.org:81/download/dvb/dvb-ttpci-01.fw. ^^ Why? Just one thing: apparently the firmware in vb-ttpci-01.fw is version 0x261a, while the latest firmware version as used with the DVB driver is 0x261b. Maybe somebody can fix this. Whoops! Something went wrong with rsync'ing from the internal preview webserver to the external one. I've notified the admin to fix this. Johannes Apparently there has been a new version of dvb-ttpci-01.fw copied to http://www.linuxtv.org/download/dvb yesterday evening. But the file has the same name as the previous version. Wouldn't it make sense to put some version number into the file name? Preferably the same number as logged when loading the firmware (currently 261b). Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Problems with 1.1.1
Andreas Share wrote:
Be careful. The new code _works_ with BSRU6 (stv0299) and the old BSRV2
module. Remember that DiSEqC is _always_ done by the av7110 on
full-featured cards.
That is very weird.. So the new-ves1x93 must be in some mode that is
interfering with the DISEQC being sent by the av7110... I can't think of
any
other explanation.
Hi,
this could not be caused by the latest changes, because 1.1.0 doesn´t work
also.
But between 1.0.1 and 1.1.0 was some init changed in ves1x93 related to the
polarisation. Maybe somone can test it with the old value...
static
u8 init_1893_tab [] = {
0x01, 0xA4, 0x35, 0x81, 0x2A, 0x0d, 0x55, 0xC4,
0x09, 0x69, 0x00, 0x86, 0x4c, 0x28, 0x7F, 0x00,
0x00, 0x81, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-0x80, 0x00, 0x31, 0xb0, 0x14, 0x00, 0xDC, 0x00,
+0x80, 0x00, 0x31, 0xb0, 0x14, 0x00, 0xDC, 0x20,
0x81, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x55, 0x00, 0x00, 0x7f, 0x00
};
This bit set the initial voltage to 0V (before 13V)...
By the waythe hole before_after_tune/notifier stuff doesen´t work as
aspected...sometimes the driver run into the wrong funktion, because he
reported HAS_LOCK, but i was at the beginning of tunig, sometimes
av7110_before_after_tune() reported lock and set up the pids, but tuning
isen´t finished.
I tried this, but there was no change at all.
Switching polarizations with DiSEqC still doesn't work reliably.
Klaus
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as
subject.
[linux-dvb] Re: Problems with 1.1.1
Helmut Auer wrote: Hi Andreas, -0x80, 0x00, 0x31, 0xb0, 0x14, 0x00, 0xDC, 0x00, +0x80, 0x00, 0x31, 0xb0, 0x14, 0x00, 0xDC, 0x20, just to clarify: my ves1x93.c has the following contens: 0x80, 0x00, 0x21, 0xb0, 0x14, 0x00, 0xDC, 0x00, ^ What should I try now ? These values don't work here at all (no signal on any polarization). Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Andrew de Quincey wrote: OK, this is getting far too confusing. Need to summarise this: We're trying two types of DVB-S-fullfeatured cards: the 1.3 and the 1.6 The 1.3 works fine with the alps_bsrv2(101) driver The 1.3 fails with the ves1x93(110) (polarisation switching) The 1.3 fails with the ves1x93(cvs) (polarisation switching) I don't see how the 1.6 can be working with either as it is using a completely different frontend. Klaus, you reported that the 1.3 fails completely for you with ves1x93(cvs), and that the suggestion by Andreas doesn't help with the polarization problem. That sounds weird 'cos Helmut says ves1x93(cvs) only has the polarization problem, not that it fails totally. Can you try Oliver's suggestion of resetting everything and retry ves1x93(cvs)? Is the above correct? Not quite. When I use the driver from yesterday's CVS it works a bit, but switching polarizations doesn't always work. With 0x80, 0x00, 0x31, 0xb0, 0x14, 0x00, 0xDC, 0x20, it is the same as before, and with 0x80, 0x00, 0x21, 0xb0, 0x14, 0x00, 0xDC, 0x00, (as Helmut Auer wrote) it fails completely. Klaus BTW: I don't think it was a good idea to break this thread apart... :-( -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured card summary
Andrew de Quincey wrote: On Saturday 13 March 2004 15:00, you wrote: Andrew de Quincey wrote: OK, this is getting far too confusing. Need to summarise this: We're trying two types of DVB-S-fullfeatured cards: the 1.3 and the 1.6 The 1.3 works fine with the alps_bsrv2(101) driver The 1.3 fails with the ves1x93(110) (polarisation switching) The 1.3 fails with the ves1x93(cvs) (polarisation switching) I don't see how the 1.6 can be working with either as it is using a completely different frontend. Klaus, you reported that the 1.3 fails completely for you with ves1x93(cvs), and that the suggestion by Andreas doesn't help with the polarization problem. That sounds weird 'cos Helmut says ves1x93(cvs) only has the polarization problem, not that it fails totally. Can you try Oliver's suggestion of resetting everything and retry ves1x93(cvs)? Is the above correct? Not quite. When I use the driver from yesterday's CVS it works a bit, but switching polarizations doesn't always work. With 0x80, 0x00, 0x31, 0xb0, 0x14, 0x00, 0xDC, 0x20, it is the same as before, and with 0x80, 0x00, 0x21, 0xb0, 0x14, 0x00, 0xDC, 0x00, OK, in that case it shouldn't be the 0x20/0x00 change; that appears to be the voltage setting (0x20==13v, 0x30==18v, 0x00=OFF). So that change was just changing the default from 13v to OFF. As for the 0x21/0x31. I do have the alps bsrv2 datasheet, but they don't go into much detail. They recommend 0x21 though and have a comment saying (MODE: QPSK/DVB). I don't know why 0x31 is working for you and not 0x21. Looking at the source, the only other change I can see is to when it sets the tuner frequency. The attached patch will disable this change. Note: I have _no_ idea what it does; the sheet doesn't go into any details. Name: ves-fix-1.patch ves-fix-1.patchType: text/x-diff Encoding: 7bit I went back to the original init_1893_tab values and applied your patch. No improvement, though. Switching polarizations still doesn't work reliably. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: problem with 1.1.1 and VDR grab
Michael Hunold wrote: Hello Peter, On 03/12/04 10:22, Peter Siering wrote: Can you please send me oops? I am not sure, how to do that? May be just that: [...] Yes, thanks. Can you give me some informations about your system? - kernel version used 2.4.24 - kernel patches applied plain Debian plus Gerd Knorrs V4L2 patches (as I wrote in my first post, the same Kernel(+Patches) works as expected with DVB 1.1.0). Sorry, I missed that piece of information. Ok, but this explains your problems. Gerd Knorr regularly improves the v4l2 helper modules (like video-buf, v4l2-common or v4l1-compat) or incorporates my fixes. He regularly creates patches against recent 2.4 kernels, but he *doesn't* create patches against older versions, ie. the patches against 2.4.24 and 2.4.25 contain differences. When 2.4.25 came out, I took his latest improvements and incorporated it into the DVB tree. The problem now is, that the in-kernel modules for 2.4.24 are compiled against different header files than the DVB drivers from the release. This is screaming for problems. One solution is to upgrade to 2.4.25 and use the CVS version of the dvb-kernel tree. (Not the release, because some bugfixes are missing) Or you take 2.6.4 and apply the patches from the patches-2.6 directory from dvb-kernel CVS. I can confirm that 1.1.1 contains a bug that produces a kernel oops through the v4l1 compatibility layer when using kvdr. Taking a snapshot via space then quitting the application will cause a kernel oops. I'm working on it, the fix for preventing the oops is easy. But it looks like kvdr needs to be changed in order to work after that change. If you like to, I could give it try. I apologize for the current problems. The problems are due to the fact that most applications are still Video4Linux-1 specific, so all stuff goes through the compatibility layer until it reaches the DVB Video4Linux-2 driver. I recently added some resource management to get the driver more robust and a lot of hidden bugs are now triggered. I admit that it was unfortunate to do this before the releases, but now we have to live with it. Be assured that I'm really interested to fix all these problems. If you're not bound to 2.4, please try 2.6.4 and the patches I mentioned above. Otherwise update to 2.4.25 and use a recent CVS driver. Thanks, Peter CU Michael. I was thinking about giving the new linux-dvb driver a try today, on a SuSE 8.2 system with kernel 2.4.20 - but from what I see here there's apparently so much confusion about this driver that I guess I'll rather not waste time on this... Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] dvb-kernel: old firmware
Ok, so I've set up a machine with SuSE 8.2, kernel 2.4.20, fetched the dvb-kernel driver from today's CVS and the firmware from http://www.linuxtv.org:81/download/dvb/dvb-ttpci-01.fw. Compiling the driver and VDR worked just fine, and it appears to run ok. Just one thing: apparently the firmware in vb-ttpci-01.fw is version 0x261a, while the latest firmware version as used with the DVB driver is 0x261b. Maybe somebody can fix this. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Kernel OOPS
Robert Schlabbach wrote: From: Oliver Endriss [EMAIL PROTECTED] People have invested real money into these full featured DVB cards and just don't want to throw them away. Plus, there just isn't any reasonable alternative Full-featured ack. ;-) Full-featured cards are legacy hardware, they have no future. But they are very widely used _now_, and will be as long as they physically live. I don't think that people are going to throw away their full featured cards just because some people say they have no future... I'd really like to see a new, full featured, DVB card come onto the market that does away with all the shortcomings of the TT design, has a better OSD and digital audio output. If such a new card would work with the LinuxDVB driver I'd by several of them in a heartbeat. Unfortunately, the hardware manufacturers don't seem to like useful solutions... :-( Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Kernel OOPS
Holger Waechtler wrote: Johannes Stezenbach wrote: [EMAIL PROTECTED] wrote: i am playing around with the DVR device for playing back a TS which was recorded from the DVR device. ... The kernel is configured a an SMP Kernel and Preemptible feature. That's a recipe for disaster -- the dvr playback code in the av7110 is seriously b0rked. Apart from the bug you found, the dvr device does not support non-blocking writes, and if you try to use multiple threads and do video ioctls from one thread while another thread blocks in dvr write() your machine will lock up... The output from dmesg after Oopsing is : bad: scheduling while atomic! Call Trace: Just for the record, this is not an Oops, just an indication that the driver is buggy. anybody you can help me out of this? The problem is that the av7110 hardware does not support TS playback. The driver tries to work around this by remuxing the TS into PES and feeding PES to the hardware. IMHO this code should be dropped rather than attempted to fix. Remuxing should be done in user space. VDR does the right thing. calling the PES unpacking process a 'remuxing' is kind of flattered, not? Forcing everybody to misuse the lowlevel-API instead of highlevel access just because the av711x driver is broken... Well, Holger, you keep repeating over and over that the av7110 driver is broken and that this is ancient hardware and how great modern hardware ist - but IMHO you totally neglect that the av7110 still is probably the most widely used hardware! People have invested real money into these full featured DVB cards and just don't want to throw them away. Plus, there just isn't any reasonable alternative And don't say use a budget card and do replay over the graphics card - the average user wants to insert *ONE* card into his PC and use that one for recording AND replay. Besides: replay over graphics card means MPEG decoding in software, which in turn requires more CPU power... Also: are there any budget cards already that have drivers that support CAMs? I have to admit that I don't know that. So, what about just fixing the av7110 driver? SCNR Klaus ...has the unlovely side effect that on well-designed hardware that can eat PS and TS directly the code will still do all the protocol handling and bit-twiddling on the host processor, the dedicated hardware will run idle. The Avia processor and all modern STB CPUs can process multiplexed streams directly. Holger -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Kernel OOPS
Holger Waechtler wrote: Klaus Schmidinger wrote: Holger Waechtler wrote: ... calling the PES unpacking process a 'remuxing' is kind of flattered, not? Forcing everybody to misuse the lowlevel-API instead of highlevel access just because the av711x driver is broken... Well, Holger, you keep repeating over and over that the av7110 driver is broken and that this is ancient hardware and how great modern hardware ist - but IMHO you totally neglect that the av7110 still is probably the most widely used hardware! People have invested real money into these full featured DVB cards and just don't want to throw them away. Plus, there just isn't any reasonable alternative And don't say use a budget card and do replay over the graphics card - the average user wants to insert *ONE* card into his PC and use that one for recording AND replay. Besides: replay over graphics card means MPEG decoding in software, which in turn requires more CPU power... Also: are there any budget cards already that have drivers that support CAMs? I have to admit that I don't know that. So, what about just fixing the av7110 driver? (nope, let's design cheap and cool hardware instead - evil things need to get changed, not worked around - ;) we'll keep you posted... Does this mean convergence(?) will be producing a DVB-S/C/T PCI card that - can deliver the full TS - can do (PES-) MPEG decoding in hardware (the format VDR currently uses) - supports CAMs through the LL interface - has a fullscreen OSD with at least 256 colors - has a builtin AC3 output port - has A/V and RGB output (others?) - does not require any firmware (or at least no closed source FW) - is _really_stable_ - did I forget anything? If so, I'd buy 3 right away! ;-) Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Kernel OOPS
Johannes Stezenbach wrote: ... Sure, it would be cool if VDR would be changed so it supports other hardware just as good as the av7110 cards. But IMHO VDR should use PES playback on av7110 cards, and TS playback on hardware that support it. Doing TS-PES conversion in the driver is wrong. The recording format of VDR _is_ PES (or is it PS - sometimes I'm confused with these terms, so if in doubt, just look at an actual VDR recording), and that's what it sends to the output device. It won't use two different formats or go to TS as recording format. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: channels.conf updates for Australia
Hamish Moffatt wrote: On Wed, Mar 03, 2004 at 09:20:01AM +1100, Peter Urbanec wrote: Hamish Moffatt wrote: Peter, your Melbourne data is quite old. The frequency for SBS changed 2-3 months ago from 536.5 MHz to 536.625 MHz. The PIDs for channel 9 changed about 1 month ago. Thanks for the updates. As you can appreciate, keeping these configs up to date in Australia is not easy. The broadcasters keep on changing the setup with an alarming frequency, especially the channel names and PIDs. Rescanning needs to be done by local residents - since I can't exactly point my antenna at a transmitter 1,000km away :-) Peter, That makes sense. (Sorry, I came off too negative in the quote above.) Channel 9 seems to enjoy changing their pids regularly. I don't understand why they would bother but it's happened a couple of times recently. I think that ideally user software would not store the pids but perhaps the service IDs and locate the pids by doing a scan themselves. That's possibly too slow to do on every channel change but the results could be cached for a limited period etc. I think I read that there is some work going into MythTV to do this. The VDR developer version does exactly that. PID changes are detected and applied fully automatically. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Full featured cards
Carlo E. Prelz wrote: Subject: [linux-dvb] Full featured cards Date: Thu, Feb 05, 2004 at 11:24:10PM - Quoting Adrian P Challinor ([EMAIL PROTECTED]): Does anyone know where you can get the full featured cards that are needed by VDR? My understanding is that I need at least one card that support DVB-IN, DVB/TV-OUT and has an MPEG decoder on board. These seem to be in very short supply on the open market, so if you know of a card that is available I would be very glad to hear from you. It appears vdr was targeted to the Hauppauge Nexus-s (that is, the old Technotrend full-featured) card. Here in Holland it can be easily found, albeit at a shamefully high price (I found it at a shop of the Mycom chain: www.mycom.nl). I understand that this was the first card that was available to developers. VDR makes use of the V4L-compatible video out that was developed for the Nexus, as well as of the OSD and CAM interface code. I understand that VDR was developed in parallel with the dvb driver. With a Nexus, VDR works perfectly. The unpleasant fact that I am finding out is that the Nexus is old technology: it includes the saa7111 DSP, that does not allow you to extract the complete multiplexed stream - only specific PIDs, and I am experiencing, with the same level of signal, a much higher error rate in the extracted MPEG stream, if compared with the Hauppauge Nova (budget) card. Otherwise, any reason why I cant use a hi-end AGP card with a TV/DVI-out capability? In order to generate a video output, VDR needs the capability (provided by the driver) of onboard MPEG conversion, and of on-screen display. I *think* you can use VDR with a budget card for recording, but you cannot see the set-top-box-like output. Porting it to using software MPEG decoding is, I believe, not trivial. There is already work going on on implementing a softdevice plugin for VDR, which does the MPEG decoding in software and uses your graphics card for display. See http://www.k13zoo.de/vdr. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: How to tune to channels via the CAM module?
Carlo E. Prelz wrote: Subject: [linux-dvb] Re: Activation of a card via Nexus+VDR - Possible? Date: ven, feb 06, 2004 at 04:26:40 +0100 Quoting Andreas Share ([EMAIL PROTECTED]): this could be only a problem with you CICAM, because neither vdr or the driver touch anything in the stream you need for activation. Only if your CICAM is not supported by vdr the card could not be activated. If your provider is PREMIERE, and you use an older Irdeto 4.6/4.7/4.8 SE or an Alphacrypt CI with firmware 2.02, then you must update your CICAM. Umm umm. Should not be the case: I bought the CICAM card expecially for this use. It is a brand new AstonCrypt V1.05 (SECA), and the service is CanaalNederland (the Netherlands). I have had the card activated again at the shop, and this is confirmed from the card's menu. But I still see no output for those encrypted channels that I should be able to see. I try with both vdr and the utilities that are included in libdvb. With vdr I do not know what to write into the CA field of the channel description. If I put 0, the screen remains black (for the encrypted channels). I wanted to be sure that there would be a communication to the card, so I added a printout in cCiConditionalAccessSupport::SendPMT For example, if I want to tune to SBS6 (on Astra, 12574 MHz, Hor, SR 22000, video PID 514, audio PID 80, SID 5005), the following bytes are sent to the CA: : 03 13 8d 01 00 14 01 09 11 01 00 e6 41 00 6a ff 0016: 00 00 00 00 00 00 02 04 1c 46 00 02 02 00 00 00 0032: 00 50 00 00 (the first byte is CPLM_ONLY) But then, nothing happens... I also tried with cam_test and cam_set. If cam_test is started as follows: ./cam_test -q 12574000 -l H -r 2200 -i 5005 -s I get as output: Warning: TP already defined: ID: 1 SATID: 1 Channel: SBS6 apid: 0x50 vpid: 0x202 ttpid: 0x20 CAM Test: 0x138d 0x202 0x50 0x0 0x 0x6 CAM Test: 0x138d 0x202 0x50 0x0 0x 0x6 CAM Test: 0x138d 0x202 0x50 0x0 0x 0x13 and I see the following bytes are passed to the card: : 01 01 a0 32 01 90 02 00 03 9f 80 32 29 03 13 8d 0016: 01 00 14 01 09 11 01 00 e6 41 00 6a ff 00 00 00 0032: 00 00 00 02 04 1c 46 00 02 02 00 00 00 00 50 00 0048: 00 00 ff ff 00 00 (this is the complete message, which contains the bytes shown above), but I see nothing happening after that, too. There is no output to the V4L port, and if I use the -o flag to cam_test, the stream I receive is still encrypted. So my question is: what is the correct procedure for tuning channels that must be decrypted by the CAM module? Where will the decrypted mpeg stream be found? I am copying Klaus, the author of the CI software. I hope you do not get upset... There is so little information around on these topics. ...! Have you tried VDR version 1.3.3? See ftp://ftp.cadsoft.de/vdr/Developer. Use a Ca value of 0 and VDR 1.3.3 will fill in the correct values automatically. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: CI Question again
Johannes Stezenbach wrote: Manfred Petz wrote: Sorry, if this has already been answered: Looking at EN 50221:1997, a CAM should be able to decrypt multiple tv channels at once. I'm playing around with this and I only manage to decrypt one single audio/video PID pair with my Nexus-S. While the standards may allow this (do they really?), I'm quite sure CAM vendors won't implement it. I believe somebody on this list (or was it the VDR list?) has reported that he was able to set the CAM to decrypt up to three channels. It depends on the individual CAM whether or not this is possible. The standard explicitly allows it. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Is there anything I could do to make editing mark working under 2.6?
Johannes Stezenbach wrote: Gregoire Favre wrote: for some reasons I prefer to use 2.6 kernels, BUT with 2.6 kernels I can't edit my marks under 2.6... I have tried to run vdr with only one card: same result... As already discussed, for some people, it works, for some other it's only slow, for me all I can do is to killall -KILL vdr... What could be done? What works for me is: LD_ASSUME_KERNEL=2.4 ./vdr Which means that this problem is unrelated to the DVB drivers, but due to changed behaviour of the new NPTL (native posix threading library) vs. the old linuxthreads. (LD_ASSUME_KERNEL=2.4 makes glibc use linuxthreads even if the kernel is capable of running NPTL.) Johannes VDR 1.3 natively supports NPTL. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Is there anything I could do to make editing mark working under 2.6?
Gregoire Favre wrote: On Tue, Feb 03, 2004 at 04:28:29PM +0100, Klaus Schmidinger wrote: VDR 1.3 natively supports NPTL. I am sorry but I don't understand NPTL ;-) I got same problem with 1.2.x and 1.3.x If there is a switch to compil without NPTL, I would happily try it!!! I just meant that VDR 1.3 uses thread ids instead of process ids, which is necessary with NPTL. There's no other special stuff for NPTL. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Is there anything I could do to make editing mark working under 2.6?
Johannes Stezenbach wrote: Klaus Schmidinger wrote: Johannes Stezenbach wrote: LD_ASSUME_KERNEL=2.4 ./vdr ... (LD_ASSUME_KERNEL=2.4 makes glibc use linuxthreads even if the kernel is capable of running NPTL.) VDR 1.3 natively supports NPTL. What does this mean? Well, Jon Burgess, Andreas Schultz, Werner Fink and Stefan Huelswitt have sent me patches for VDR 1.3.0 to work with NPTL without having to set LD_ASSUME_KERNEL=2.4. Since I don't run kernel 2.6 or NPTL here I wasn't able to explicitly test this and just had to assume that it would work. If somebody with NPTL can provide a fix, please let me know. I tried with vdr-1.3.3. It hangs without LD_ASSUME_KERNEL=2.4. NPTL is more Posix conforming than linuxthreads, so there may be differences in the *behaviour* of some pthread_* functions, and especially in the interaction of threads and signals. But I haven't had time to look into NPTL yet, so I don't know what exactly could be the problem. But the SIGIO stuff in vdr/thread.c could be the culprit... Possible - but as I said I can't debug this myself. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Is there anything I could do to make editingmark working under 2.6?
Arne Gellhaus wrote: Gregoire Favre wrote: On Tue, Feb 03, 2004 at 04:23:25PM +0100, Johannes Stezenbach wrote: What works for me is: LD_ASSUME_KERNEL=2.4 ./vdr Which means that this problem is unrelated to the DVB drivers, but due to changed behaviour of the new NPTL (native posix threading library) vs. the old linuxthreads. (LD_ASSUME_KERNEL=2.4 makes glibc use linuxthreads even if the kernel is capable of running NPTL.) ;-) It works perfectly, I didn't immediatly try it because I didn't fully understand all answer!!! So, the bug is in VDR? I can confirm this. So the problem is that vdr can't deal properly with pthreads. This is known for 1.2.x, but 1.3.x states in the HISTORY file that this problem is solved, so i didn't tried the old threading lib. Well, maybe somebody who is running NPTL can debug this. I was under the assumption that the problem was solved by the changes introduced in version 1.3.0. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] dvb_frontend_recover not working
I was looking into why the driver doesn't recover after a loss of signal (like when pulling the antenna cable for a few seconds) and found that apparently (at least with DVB-S) it starts a dvb_frontend_recover() sequence, but aquires a lock at a completely different frequency, which is some 16MHz off the original transponder. This is not surprising, because the fe-lnb_drift takes on values of up to +/-15462 or so, which lets it run into the next transponder at the same polarization as the current one. So no wonder there is no more picture then, because the PIDs may be totally different on different transponders. I therefore limited the range of fe-lnb_drift in dvb_frontend_recover() to some 8MHz, but then it didn't lock on to any transponder any more. This is what puzzles me, because the original transponder was perfectly locked on with fe-lnb_drift==0, and that value is the first one that gets tried in dvb_frontend_recover(). And since there can (due to the limitation to 8MHz) be no more other transponder it might lock on to by mistake, I don't understand why it doesn't lock on to the original transponder any more. It just loops through the original frequency +/-8MHz in 32 steps over and over again. Note that I did all these tests with the most recent CVS version of the DVB driver, but dvb_frontend.c appears to be quite the same (with respect to the dvb_frontend_recover() mechanism) as in the dvb-kernel driver. Does anybody have an idea why this doesn't work as expected? We should really get this to work in order to make an application automatically come back after the signal was lost, for instance due to bad weather. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: UK DVB-T Freeview channel numbering
John Murdoch wrote: Hi, I'm wondering if the scan developers are considering incorporating automatic channel numbering (for applications such as VDR) in the near future for those services that support it? If so, I have attached a small patch (created against the CVS dvb-apps tree) to retrieve the channel numbers for the UK terrestrial Freeview service for use in VDR 1.2.xx. The channel numbers can be found in the NIT table as the user-defined descriptor 0x83 and each channel number has a corresponding Service ID which is included in the descriptor. How did you find out about this user-defined descriptor? Is there any documentation available about its format (and maybe other user-defined descriptors, too)? Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: 1.0.2 Release?
Niklas Peinecke wrote: ... I agree with Holger. Of course it's better to have a release suitable for 2.6, but it will take some more time until 2.6 kernels are really common: Most people have working vdr-boxes based on existing 2.4 kernels and they just like to use some e-bayed cheap skystar2 as a third card. I'm sure they won't like to upgrade their kernels for that. It will also take some time until 2.6 is established in dists like LinVDR, thus we need a release as a bridge until then. I haven't used dvb-kernel yet and also have no 2.6 machine, but just wanted to drop in my 2 cents: IIRC there was a discussion a while ago about dvb-kernel being considerably slower in channel switching than the DVB driver (presumably because of different I2C handling). Is this still the case (or was it never the case)? If dvb-kernel switches channels slower than DVB, I guess this would be a no-go criteria for many people. As I said, just my 2ct, w/o personal experience with either dvb-kernel or kernel 2.6. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: No sound on some channels (sometimes)
Martin Holst wrote: Hi although I believe that this bug is well known by the dvb-developer, I'll describe it another time: Many people noticed, that the sound on some channel gets lost and only a restart of the dvb driver solves that problem. In my case I'm pretty sure, that this problem doesn't exist within dvb-driver from 20.09.2003. But some other people on the vdr-ML said, that they have this problem with drivers before that date. Affected channels are: RTL, ARD. Oliver Endriss wrote on the vdr-ML: * I often have missing sound on ARD (pid 102), but sometimes other * pids are affected (101, 104). 101 is used by picture on ARD, 104 * by sound on RTL... * * This is a known and pretty old bug. I had some off-list discussion * with the driver developers in April 2003 about this issue. It was * mentioned on the ML several times, too. As discussed on the vdr-ML this problem occurs on a DVB-s 1.3 and 1.6 as well as with a Nexus. I've tried recent dvb-driver and dvb-kernel with the same result. Has anyone of the driver-gurus an idea, where we can start to get rid of this problem? I wouldn't call myself a driver guru, but here's an observation I made: The Sat.1/Pro7 transponder uses the PIDs 97...107 for their PMT data. Maybe, when switching from a channel on that transponder to, say, RTL the PID 104, for instance, is still in use by the PMT section filter and thus can't be used for audio at that time. VDR does stop all section filtering before switching channels, so I would assume that from VDR's point of view the PIDs should all be available as necessary. Maybe there is a race condition in the driver that causes the already freed PIDs to still be in use? Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: Discrepancy in scrambling between Windows and Linux
Michal Dobrzynski wrote: Under Windows I was using MultiDec to view the following channel and it was not scrambled (I do not have a CI module or CA so there would have been no way to descramble it): TVSN:12478:h:S156.0E:27800:1081:1082:0:1:3008:0:0:0 This is the TV Shopping Network (it's not that I want to watch it but it's a channel I can using for testing as it's not scrambled).. or is it? When scanning under Linux this channel was listed as scrambled. I also could not view it under VDR (though there were a couple of other unscrambled but even less useful channels which it could view). Any ideas of what might cause that? Have you tried the VDR 1.3.0 developer version? This one includes automatic PID and CA setting. You also might want to set the Ca parameter to '0', as in TVSN:12478:h:S156.0E:27800:1081:1082:0:0:3008:0:0:0 VDR 1.3.0 will then automatically fill in any CA system ids automatically. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: [RFC] Limitations of current filtering
Roberto Ragusa wrote: Hi all, this posts is about discussions started in a different thread ([linux-dvb] Re: [PATCH?] proposed rewrite of skystar2 filters, Wed, 03 Dec 2003 20:24:42 +0100) There are currently two ways to get data from a TS (I'm considering DMX_TYPE_PES only): 1) DMX_OUT_TAP 2) DMX_OUT_TS_TAP With DMX_OUT_TAP: - we setup the filter trough /dev/dvb/adapterX/dmxY - we get data from /dev/dvb/adapterX/dmxY - we get payload only - we get one pid for each opened /dev/dvb/adapterX/dmxY With DMX_OUT_TS_TAP: - we setup the filter trough /dev/dvb/adapterX/dmxY - we get data from /dev/dvb/adapterX/dvrY - we get transport stream (first byte is 0x47) - we get a multiplexed stream of all the requested pids The TS_TAP method has a big limitation; there is only one /dev/dvb/adapter/dvrY device, so it's not possible to read two sets of pids (as it's necessary when one wants to separately record two television channels with identical frontend settings). I don't know whether I fully understand what this is about, but I just saw that DMX_OUT_TS_TAP is used in VDR, and VDR is well able to record the same channel into several files (like in case of overlapping timers on the same channel). It just reads the TS once and distributes it to the various cReceivers. But maybe you're aiming at something completely different... Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: [RFC] Limitations of current filtering
Holger Waechtler wrote: ... At that point dvrY is totally useless and it could be theorically removed (but it's better to not break existing apps, of course). We should keep it in v3, in v4 it will vanish anyways. The DVR device is still required for MultiPID-TS filters when we don't implement b). I have to admit that (due to lack of time) I didn't follow the V4 API discussion, so please forgive this question: if the DVR device will vanish, what will an application (like VDR) have to use instead? A short link to the relevant doc page or posting would do just fine. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: CI/CAM - Message Sequence wrong. (1 more thing)
Pedro Miguel Teixeira wrote: It works ok with -icam firware (just tested it) PLEASE DON`T START NEW THREADS WITH EVERY MESSAGE!! Stay in the thread you STARTED this with! Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: FF cards alter PTS'?
Holger Waechtler wrote: ... ? Hm, I think you got me wrong. If I may choose between two comparable cards, - one card with a closed-source firmware and - another card with a complete open-source driver I would definitely select the second one, even if it is more expensive. Furthermore, I will prefer a vendor who provides us with card specs. Well, the Technotrend cards are the one you woould never ever buy, is this correct? *g* Btw: understand firmware as part of the hardware, you don't have the sources of the BIOS of your mainboard and graphics card, you don't even know which other hardware components need some codelets from their drivers or from onboard EEPROMs to operate. A firmware is just something required for the hardware to operate, if it's done well you don't even want to know that it's there. Which is not a problem as long as the firmware actually *works*! There is no advantage except that these cards are really cheap. ?!? sorry, I don't understand you. They do their job and are cheap, isn't this advantage enough? I was targeting at budget cards with closed-source firmware. From what I have read so far, they are not working very reliable (yet). There are no specs, and I2C communication has to be sniffed. It's not easy to implement features like error recovery correctly, if the firmware is a black box... Well, as far I know the TDA10045 based DVB-T cards are working just fine, the Avermedia cards have problems at weak receiption conditions or with many reflections. But since the Windows driver is appearently doing fine with the same firmware it's a driver issue that can and will get fixed. The situation with full-featured cards is completely different: o Basically there is only one card design available. guess why. o While the firmware is closed-source, there are some trustworthy guys who maintain the source code and do a great job. ;-) none of them likes this job, scroll back in the mailing list archive. These are the guys trying to convince Klaus and the other VDR freaks to implement a software decoder. guess why. I hate to repeat myself, but here goes: Why should *I* implement a software decoder? I for myself am quite happy with the full featured DVB cards, and since I write VDR mainly for my personal needs, I don't need a software decoder! VDR has the ability to implement alternative devices, so if somebody feels the need to implement a software decoder plugin, just go ahead! Maybe, if it works fine, people will adopt it joyfully and sooner or later abandon the FF cards. But you won't be able to defeat the use of FF cards by just declaring them outdated or dinosaurs. You have to provide a better alternative, then evolution will do the rest. So, instead of theoreticising and calling people liars, why don't you just go ahead and write a device plugin for VDR that implements a software decoder and OSD? end of thread. Fine with me. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
[linux-dvb] Re: FF cards alter PTS'?
Holger Waechtler wrote: Klaus Schmidinger wrote: Holger Waechtler wrote: Oliver Endriss wrote: On Thursday 20 November 2003 15:59, Robert Schlabbach wrote: From: Klaus Schmidinger [EMAIL PROTECTED] Robert Schlabbach wrote: AFAIK, the specs for the TT designs have never been published either, and the drivers you have now are the result of guessing and reverse engineering. I don't see why this shouldn't be repeated for more up-to-date designs than the old TT ones... True - but soembody actually has to _do_ this ;-) Apparently the interest in this isn't high enough, yet... Maybe the incentives just aren't high enough - why bother reverse engineering a design that's technically no improvement over the TT ones? Now if there was a card that was actually a technical advance (e.g. a DVB-S2 card, or a hybrid DVB-C/T card, or a card with a better suited PCI bridge with a deep FIFO, or a card with a much quicker sync'ing demodulator), I'm sure someone would get into reverse engineering it... Exactly, that's the point. IIRC some recent budget cards also require closed-source firmware, which has to be taken from the windows driver. This is a step in the wrong direction. Get real. These cards are again Technotrend cards. Or do you know another design which is using the TDA10045 demod? There is no advantage except that these cards are really cheap. ?!? sorry, I don't understand you. They do their job and are cheap, isn't this advantage enough? You accept silently all the limitations of the av711x: a OSD that is far from what you expect for a modern STB (the OSD is not even able to display 8bit DVB subtitles correctly), no way to pass a high-bandwidth stream to the host and process it there, no way to decode HDTV or even MPEG4 sources. Their cheap alternatives provide you all this, What?? They have a better OSD? I thought they don't have an OSD at all (let a lone a TV out)?! When you take the framebuffer of your graphics card you get the freedom to draw anything you want into your OSD, you got rid of all limitations. Holger, please realize that we are talking about FULL FEATURED cards here! like mentioned before: Full Featured cards an anachronism, I hope no company will be so foolish to produce such a beast again for the mass market. I really fail to see your point. If a company were to produce a *GOOD* full featured DVB card, with a firmware (if necessary) that really works and doesn't require constant fixing, and an OSD that provides a full screen, 8bpp resolution, what would be wrong with that? It appears to me like the idea of a full featured DVB card seems like blasphemy to you. Just because one company was unable to deliver a flawless product doesn't need to keep all others from doing a better job. Do you remember why dinosaurs died? They expected their environment to adopt and were not willing to change their mind. Hope that VDR won't share their destiny. The DVB hardware environment has changed - be happy about it: things became cheaper, better and more robust. Well, repeating myself again: if you want a software decoder device, just write a device plugin and be happy. Do you really expect me to dump my FF DVB cards, just because there are lots of DVB cards out there without MPEG decoder? As long as my cards work, there is no incentive for me to implement a software decoder. I made the plugin interface available, so anybody who wants to can implement it. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as subject.
