On Saturday 13 March 2004 14:18, Andrew de Quincey wrote:
On Saturday 13 March 2004 12:56, you wrote:
On Friday 12 March 2004 20:28, Helmut Auer wrote:
Helmut Auer wrote:
Hello, I have a reproducable error with the 1.1.1 release. When
zapping: ARD, ZDF, RTL1, RTL2, VOX, SAT1 the
On Saturday 13 March 2004 14:45, Helmut Auer wrote:
It's getting more and more interesting. In my case this doesn't change a
thing.
I have the same problems, when I use the alps_bsrv2 instead of the ves1x93.
Then I tried a dvb-s 1.6 with the grundig tuner and then strange things
( in my
On Saturday 13 March 2004 09:43, Alfred Zastrow wrote:
It is definitely a ves1x93-problem. For testing purposes I load the
following modules for my rev 1.3-cards:
,,,
#insmod ves1x93 --- commented out
insmod alps_bsrv2 --- from the DVB-Tree
...
Just an idea:
Have you tried
On Saturday 13 March 2004 23:58, Heino Goldenstein wrote:
FWIW:
I have also a DVB-S fullfeatured 1.3 card and use the drivers
1.0.0, 1.0.1, 1.1.0 and curently 1.1.1.
They all work with DiSEqE without any problems.
This are my DiSEqC parameters
S19.2E 11700 V 9750 v [E0 10 38 F0]
On Friday 12 March 2004 21:28, Helmut Auer wrote:
Helmut Auer wrote:
Hello, I have a reproducable error with the 1.1.1 release. When
zapping: ARD, ZDF, RTL1, RTL2, VOX, SAT1 the screen gets black when
reaching SAT1, and afterwards I can tzap to whatever I want. The
screen stays
On Tuesday 09 March 2004 01:58, Andrew de Quincey wrote:
Hi, this new version of the patch has all the previous features as well as:
* Removed unnecessary second tune from stv0299.c
* Fix non-PHILIPS_SU1278_TSA_TT cards in stv0299.c
* Removed the FE_RESET/FE_POLL stuff; no longer needed.
*
On Friday 05 March 2004 11:17, Klaus Schmidinger wrote:
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
Hi,
now I tried your patch with my DVB-S (BSRU6, stv01299-based).
I'm using DiSEqC.
Basically it seems to work fine, never encountered a zigzag scan. :)
Tuning is somewhat slower, compared to my old reference driver
(CVS DVB from November, with zigzag scan removed).
Until now, I found that
On Monday 08 March 2004 22:36, 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
On Monday 08 March 2004 21:34, Holger Waechtler wrote:
Ralph Metzler wrote:
Oliver Endriss writes:
And, unless there is a hardware or firmware CSA descrambler on the card, you
will never be able to decrypt pay-tv in a legal way.
IANAL, but I don't think that anyone can write a CSA
On Monday 08 March 2004 20:39, Andrew de Quincey wrote:
On Saturday 06 March 2004 13:55, Oliver Endriss wrote:
Until now, I found that FE_SET_PARAMETERS is always called twice,
with fe-state==2 and fe-state==4. Is this intentional?
Yeah, thats the frontend-core auto inversion. The stv0299
On Tuesday 09 March 2004 01:15, Robert Schlabbach wrote:
From: Oliver Endriss [EMAIL PROTECTED]
Hm, interesting. Are you sure? Afaik the CSA is implemented in the AV7110
of the full-featured cards. So I would have expected that CSA has to be
implemented in the driver of the budget cards
On Tuesday 09 March 2004 01:26, Andrew de Quincey wrote:
On Tuesday 09 March 2004 00:19, Oliver Endriss wrote:
On Monday 08 March 2004 20:39, Andrew de Quincey wrote:
On Saturday 06 March 2004 13:55, Oliver Endriss wrote:
Until now, I found that FE_SET_PARAMETERS is always called twice
On Tuesday 09 March 2004 02:54, Andrew de Quincey wrote:
Do you have a particular reason in mind for it returning to AUTO if the
lock is lost?
No, this was a simplification. A transponder will hardly ever change
signal inversion on the fly. (At least I hope so.)
Anyway, someone
On Tuesday 09 March 2004 02:25, Ralph Metzler wrote:
Oliver Endriss writes:
Great. So there are no license/patent issues which might prevent writing
an open-source driver. I wonder why nobody has done this before.
The hardware has been available for some time.
I thought about
On Tuesday 02 March 2004 20:57, Joerg Riechardt wrote:
what do I have to do to disable zif-zag scan?
edit dvb_frontend.c? But what exactly do I have to change?
Just set j=0 at the beginning of dvb_frontend_recover() in dvb_frontend.c.
Maybe these issues will be fixed soon for dvb-kernel (see
On Tuesday 02 March 2004 23:37, Andrew de Quincey wrote:
In the past I did some tests and found that tuning is always faster if
zig-zag scan is disabled. So the first thing I do after a check-out is
disabling this cra^Wstuff. - Never had any problems (QPSK BSRU6, Grundig
29504-451).
On Monday 01 March 2004 12:09, Andrew de Quincey wrote:
I only have access to a few sat dishes, all of which are professional quality
with quad LNBs. I haven't ever actually experienced LNB drift. Currently the
Same here.
only use I have for the zigzagging code is to finetune during the
On Saturday 28 February 2004 14:27, Andrew de Quincey wrote:
On Friday 27 February 2004 20:19, Oliver Endriss wrote:
On Friday 27 February 2004 19:37, Johannes Stezenbach wrote:
Christian Schuld wrote:
So I vote for a way to disable zigzagging completely, may be via a
sysfs interface
On Saturday 28 February 2004 22:46, Johannes Stezenbach wrote:
Oliver Endriss wrote:
In the past I did some tests and found that tuning is always faster if zig-zag
scan is disabled. So the first thing I do after a check-out is disabling this
cra^Wstuff. - Never had any problems (QPSK
On Friday 27 February 2004 11:19, Justin Frisch wrote:
Heya :)
I just bought a Terratec Cinergy 1200 after looking at the specs and assuming
that it was already supported (just didn't notice that it had just recently
come out.)
The chipsets that I have on the card are as follows:
On Friday 27 February 2004 19:37, Johannes Stezenbach wrote:
Christian Schuld wrote:
So I vote for a way to disable zigzagging completely, may be via a sysfs
interface? It would be nice for tuning the zigzigging parameters, too.
sysfs stuff will have to wait until after we branch CVS to
Hi,
there is a preliminary patch for dvb-kernel to support the FS Activy card
with Grundig frontend on
http://endriss.escape.bei.t-online.de/dvb/fs_activy.diff
The patch is the result of this thread at vdrportal.de:
On Friday 16 January 2004 09:35, Steffen Barszus wrote:
Am Donnerstag, 15. Januar 2004 15:31 schrieb Oliver Endriss:
On Thursday 15 January 2004 14:56, Niklas Peinecke wrote:
To settle this issue we have to answer the following question: Is
channel switching slower with
a) dvb
On Thursday 15 January 2004 14:24, Klaus Schmidinger wrote:
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
On Thursday 15 January 2004 14:56, Niklas Peinecke wrote:
To settle this issue we have to answer the following question: Is
channel switching slower with
a) dvb-kernel + kernel 2.6
stv0299-based frontend (full-featured card, rev.2.1): no
b) dvb-kernel + kernel 2.4
stv0299-based frontend
On Monday 05 January 2004 14:29, Software wrote:
Hello,
last weekend i switched my vdr-pc to kernel 2.6.0. Now i have an echo of
the pressed remote keys on the
terminal window.
With kernel 2.4.21 i simple rmmod keybdev.o module and the echo was
gone...
What should i do under a 2.6.
On Monday 05 January 2004 18:10, Johannes Stezenbach wrote:
Holger Waechtler wrote:
has it ever been discussed to add a device type flag (KEYBOARD, REMOTE
or SENDS_TTY_EVENTS/NO_TTY_EVENTS -- anything like this)?
I think so. Search groups.google.com for lirc EVIOCGRAB
On Tuesday 30 December 2003 22:04, Georg Golombek wrote:
Hello,
unfortunately i got a skystar2 rev 2.6B with Samsung Tuner because my old
good skystar2 was damaged.
Then i saw that it doesn't work with the existing driver.
I was looking on linuxtv.org for a new driver because some mails
On Saturday 20 December 2003 19:09, Michael Hunold wrote:
As one of the last bigger changes, the core developers decided to remove
the firmware from the av7110/dvb-ttpci driver. I know that this is a
controversial step, so I'd like to explain it further.
...
As a first step, the av7110
On Tuesday 25 November 2003 10:19, Michael Hunold wrote:
Note that without [2] modification [1] is almost useless,
because each I2C access causes a delay of 10..20ms.
I suggested several times to improve this but I was ignored...
I'm sorry if I ignored something back then. I just had a
On Tuesday 25 November 2003 08:43, Holger Waechtler wrote:
static variables are initialized to 0 by definition. All variables
marked as 'static' are placed in the .bss section which gets cleared by
the bootloader and the module loader/dynamic linker before code is executed.
This is valid
Hi,
FYI, I committed the short_delay patch as suggested by Michael.
On Tuesday 25 November 2003 13:50, Jeremy Hall wrote:
It still feels like it takes longer to tune in dvb-kernel than it did in
DVB.
I'm using a stv0299-based frontend with a DiSEqC multi-switch,
and I can't see any
On Monday 24 November 2003 15:28, Jeremy Hall wrote:
Per some suggestions, I opted to try the dvb-kernel tree, but found that
timing is worse in the dvb-kernel.
I have requirements to be able to change voltage from h to v in under 8ms
consistently, and can successfully achieve this with
On Tuesday 25 November 2003 05:40, Jeremy Hall wrote:
Hi,
yes this fixed my problems. Will this be more reliable than the DVB tree
or the same? (the DVB code sometimes misfires and the wrong LNB is
selected)
Hm, I think there shouldn't be any difference.
What must be done to get this
On Tuesday 25 November 2003 06:10, Jeremy Hall wrote:
Hello,
I'm running dvb-kernel, and have noticed that when I kill vdr, a few
seconds after being returned to the prompt, the decoder stopps viewing the
channel it was on. Is there a reason for this?
The default value of
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
On Wednesday 12 November 2003 16:32, Johannes Stezenbach wrote:
Vadim Catana wrote:
Andrew de Quincey wrote:
Would it not actually be more useful to make it count uncorrected blocks,
as
this is a measure of what people actually will see.. as opposed to errors
which may (or may
On Friday 07 November 2003 15:18, Johannes Stezenbach wrote:
It seems the firmware sets two dummy PID filters for audio/video
on PID 0x1fff/0x1ffe during playback. I don't know why, but I assume
there's a reason. Maybe the audio/video decoder just won't work
without, even if the filters are
On Thursday 06 November 2003 08:00, Y2 Plugh wrote:
Oliver and Johannes, thanks for spending time on this problem.
Yesterday evening I tried to recreate the problem, but at fiirst I did not
succeed :-(
Everything was as it should be.
My first thougth was that it was because our provider
On Wednesday 05 November 2003 15:17, Y2 Plugh wrote:
I believe this timestamp can only come from the transponder PCR, since vdr
is not telling the driver the PCR pid, I concluded that the driver (firmware)
must be doing this.
vdr *always* sets the PCR pid in live view mode. If pcr pid (ppid)
On Wednesday 05 November 2003 18:27, Oliver Endriss wrote:
On Wednesday 05 November 2003 15:17, Y2 Plugh wrote:
I believe this timestamp can only come from the transponder PCR, since vdr
is not telling the driver the PCR pid, I concluded that the driver (firmware)
must be doing
On Wednesday 05 November 2003 19:13, Johannes Stezenbach wrote:
Oliver Endriss wrote:
On Wednesday 05 November 2003 15:17, Y2 Plugh wrote:
I believe this timestamp can only come from the transponder PCR, since vdr
is not telling the driver the PCR pid, I concluded that the driver
On Monday 13 October 2003 11:00, Holger Waechtler wrote:
Oliver Endriss wrote:
I'm not sure whether a 'get protocol types' ioctl is really useful.
For example, the full-featured DVB-S cards support RC5 and RCMM, but
most optical receivers shipped with these cards cannot receive RCMM
On Monday 13 October 2003 12:07, Vojtech Pavlik wrote:
On Mon, Oct 13, 2003 at 05:41:12AM +0200, Oliver Endriss wrote:
Basically we need 2 pass-through ioctls:
- set low level configuration
- get low level configuration
I'm not really keen on passing ioctl()s to drivers
On Monday 13 October 2003 14:33, Gerd Knorr wrote:
Vojtech Pavlik [EMAIL PROTECTED] writes:
It should be possible to read the current keymap from the device.
This way one could write something like a keymap editor, or
add another remote control to a loaded keymap.
Well, it is
Hi,
if you tune to the MPEG2 HD service on ASTRA 19.2E, the arm will
crash immediately. :-(
Channel settings:
MPEG2 HD:12168:v:S19.2E:27500:308+8190:256,257:0:0:21100:0:0:0
I would not expect that the firmware can decode HDTV properly, but it
should not crash imho. Can this be fixed?
Oliver
On Sunday 12 October 2003 10:35, Holger Waechtler wrote:
Oliver Endriss wrote:
The current implementation has a number of restrictions:
- Permissions of /proc/av7110_ir cannot be changed without recompiling
the driver, i.e. chown/chmod do not work.
- Only one keymap can be loaded
On Saturday 11 October 2003 16:50, Holger Waechtler wrote:
Oliver Endriss wrote:
On Friday 03 October 2003 14:12, Holger Waechtler wrote:
Oliver Endriss wrote:
On Friday 03 October 2003 12:25, Holger Waechtler wrote:
Oliver Endriss wrote:
On Thursday 02 October 2003 15:21, Rene
On Friday 03 October 2003 14:12, Holger Waechtler wrote:
Oliver Endriss wrote:
On Friday 03 October 2003 12:25, Holger Waechtler wrote:
Oliver Endriss wrote:
On Thursday 02 October 2003 15:21, Rene Bartsch wrote:
as it's quite a work to generate a key-code map, I'd like to know
On Thursday 02 October 2003 19:40, Rene Bartsch wrote:
From: Oliver Endriss [EMAIL PROTECTED]
FYI:
The next version of the vdr remote control plugin will load a default
keymap automatically. No need to use av7110_loadkeys/evtest anymore.
That's what I wanted to hear! ;o)
But three
On Friday 03 October 2003 12:25, Holger Waechtler wrote:
Oliver Endriss wrote:
On Thursday 02 October 2003 15:21, Rene Bartsch wrote:
as it's quite a work to generate a key-code map, I'd like to know if
it's possible to route/catch the raw IR-codes directly to/from the
input-device
On Thursday 02 October 2003 15:21, Rene Bartsch wrote:
as it's quite a work to generate a key-code map, I'd like to know if
it's possible to route/catch the raw IR-codes directly to/from the
input-device or a socket with the current DVB-driver.
Currently, there is no such interface.
The
On Friday 26 September 2003 14:52, Bruno Hellstern wrote:
...
here ist the output of both cards, 1st without subsystem:
00:0d.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Flags: bus master, medium devsel, latency 64, IRQ 10
Memory at ff000800 (32-bit,
On Friday 26 September 2003 18:19, Holger Waechtler wrote:
Oliver Endriss wrote:
On Friday 26 September 2003 00:25, Oliver Endriss wrote:
On Thursday 25 September 2003 12:51, Martin Holst wrote:
I've read sth in the ML-archive, that the Grundig-frontend had a similar
problem. While
On Friday 26 September 2003 22:16, Martin Holst wrote:
Oliver Endriss wrote:
On Friday 26 September 2003 18:19, Holger Waechtler wrote:
Oliver Endriss wrote:
On Friday 26 September 2003 00:25, Oliver Endriss wrote:
On Thursday 25 September 2003 12:51, Martin Holst wrote
On Thursday 25 September 2003 19:49, Martin Holst wrote:
for testing purposes I've installed Debian 3.01 with 2.4.22-Kernel. Now I've
installedcompiled dvb-from yesterday (make clean ./getlinks make)
without an error message. But when I run ./insmod.sh load I'll get an error-
messae
On Thursday 25 September 2003 12:51, Martin Holst wrote:
Michael Hunold wrote:
I've installed dvb-kernel from today and noticed, that sometimes
when running ./insmod.sh load there won't be frontend0 in
/dev/dvb/adapter1. After several restarts (or a restart of the
machine) there
On Friday 26 September 2003 00:25, Oliver Endriss wrote:
On Thursday 25 September 2003 12:51, Martin Holst wrote:
I've read sth in the ML-archive, that the Grundig-frontend had a similar
problem. While reloading that frontend the chip/card/whatever is
powered down and so can't initialize
On Friday 19 September 2003 22:24, Onno wrote:
Hi dvb list,
are there restrictions which prevent av7110_loadkeys from loading
ir codes for more than one device, thus supporting all keys cheap
universal ir's by loading keys for 2 devices ?
The current driver supports a single keymap only.
On Sunday 31 August 2003 15:36, Holger Waechtler wrote:
Oliver Endriss wrote:
On Saturday 30 August 2003 17:03, Jon Burgess wrote:
My remote works, but I ended deleting the existing key_map and
generating my own from scratch. There seem to be fairly major
differences between the remotes
On Thursday 28 August 2003 16:37, Bruno Hellstern wrote:
Hello,
since my last update from driver dvb-0.9.x to dvb-1.0.x one card can't be
recognized.
I saw that one card has no subsystem in lspci -v output which is needed by
the driver.
Kernel 2.4.x was used.
1st PC:
00:0d.0 Multimedia
Hi,
the implementation of play_iframe() has never worked with vdr,
so vdr used a workaround.
The following patch against CVS would fix this:
-
--- av7110.c.orgSat Aug 23 17:35:11 2003
+++ av7110.cTue Aug 26 20:01:17
On Tuesday 26 August 2003 15:54, Oskar Signell wrote:
On Sat, 2003-08-23 at 20:49, Oliver Endriss wrote:
On Friday 22 August 2003 16:51, Klaus Schmidinger wrote:
I just tested today's DVB driver, but when VDR starts I get
Aug 22 16:47:24 video vdr[27953]: probing /dev/dvb/adapter0
On Friday 22 August 2003 16:51, Klaus Schmidinger wrote:
I just tested today's DVB driver, but when VDR starts I get
Aug 22 16:47:24 video vdr[27953]: probing /dev/dvb/adapter0/frontend0
Aug 22 16:47:24 video vdr[27953]: ERROR: /dev/dvb/adapter0/frontend0: Device or
resource busy
...
On Saturday 23 August 2003 12:20, Karlheinz Pischke wrote:
I can not control volume from VDR on my Siemens cable card PCI rev1.5
because of an assumption made that all Siemens DVB-C cards would
have no DSP or have a MSP3400 (on analogue modul). This is what
I guess ...
(I don't have an
On Tuesday 12 August 2003 22:11, Are Årseth wrote:
The current firmware / driver seems to support only 6 bit RC5 data and 5
bit addr for Infrared codes. Would it be possible to add support for 7 bit
data codes?
7 bit data codes is a widely used extention to the standard Phillips RC5.
As can
On Wednesday 06 August 2003 13:11, Max Kiva wrote:
I am trying to install sa71146 driver.
insmod dvb-ttpci.o or 'make insmod' in driver subdir returns
init_module: no such device
Which card do you use (manufacturer, type, revision number)?
Please post the output of
lspci -vvnx.
Oliver
On Wednesday 06 August 2003 17:26, Max Kiva wrote:
The manufacturer is VVmer in Taiwan. Card is called [EMAIL PROTECTED]
I don't think that this card is supported by the driver.
For a list of supported cards, see file CARDS in the main driver
directory. Sorry.
Oliver
--
Info:
To
On Friday 01 August 2003 08:21, Klaus Schmidinger wrote:
Oliver Endriss wrote:
...
I had a closer look on the stv0299 frontend code and noticed that
dvb_frontend_recover() was called after every tuning, i.e. the
first tuning attempt failed. This happened because the frontend had
no lock
On Friday 01 August 2003 05:06, Ralph Metzler wrote:
Rene Bartsch writes:
obviously nobody is responsible for the functions setting the
PCI-latency to 64 in DVB-driver (maybe that functions just dropped
in while flying from venus to mars ... ;o) ).
According to CVS logs it was
On Friday 01 August 2003 12:12, Dr. Werner Fink wrote:
On Fri, Aug 01, 2003 at 09:26:45AM +0200, Oliver Endriss wrote:
Thinking about it I also came to the conclusion that it is a bad
idea to nail the latency setting to 64. Either it should be done by
calculating the latency *correctly
On Friday 01 August 2003 11:06, Joachim Herb wrote:
00:05.0 Class 0480: 1131:7146 (rev 01)
Flags: bus master, medium devsel, latency 32, IRQ 10
Memory at e200 (32-bit, non-prefetchable) [size=512]
00: 31 11 46 71 06 00 80 02 01 00 80 04 00 20 00 00
10: 00 00 00 e2 00 00 00
On Friday 01 August 2003 15:23, Rene Bartsch wrote:
Am Fre, 2003-08-01 um 14.22 schrieb Dr. Werner Fink:
On Fri, Aug 01, 2003 at 01:20:21PM +0200, Oliver Endriss wrote:
Wouldn't it be better to do the calculating instead of breaking
other systems which do it better _with_ a latency
On Thursday 31 July 2003 17:44, Edward Wildgoose wrote:
Yep, happens if you just use tzap and don't even view the output.
The issue is that when the card changes to a different mux, then
something suddenly dies. For most people it still goes through the
motions of tuning, symptoms vary
On Thursday 31 July 2003 20:16, Johannes Stezenbach wrote:
I did some more testing and was able to reproduce the tuning problems
with my card. After some testing I found that the root of the problem
was that the frontend thread was woken up immediately after
FE_SET_FRONTEND, so the frontend
On Wednesday 30 July 2003 18:11, Klaus Schmidinger wrote:
Johannes Stezenbach wrote:
Klaus Schmidinger wrote:
There are 3 xfer() calls in alps_bsrv2.c, but only the first one
appears to be relevant - a udelay(500) after the other two didn't
change anything.
So I did the
On Wednesday 30 July 2003 11:04, Dieter Tremel wrote:
We want to use lirc with a Hauppauge Nexus S Rev 2.1
vdr-1.2.0
ist it possible to use the card's receiver with lirc? Wich modules
should be used beside lirc_dev? Is it true that the newer DVB drivers
do not support lirc?
Sorry, there is
On Saturday 26 July 2003 11:11, Klaus Schmidinger wrote:
Oliver Endriss wrote:
So it appears to be a timing issue in the frontend driver.
Which frontend is detected by the driver?
Here's the complete log from loading the driver:
Jul 25 18:04:36 video kernel: DVB: registering new adapter
On Saturday 26 July 2003 12:42, Klaus Schmidinger wrote:
Oliver Endriss wrote:
On Saturday 26 July 2003 11:11, Klaus Schmidinger wrote:
Oliver Endriss wrote:
So it appears to be a timing issue in the frontend driver.
Which frontend is detected by the driver?
Here's the complete
On Friday 25 July 2003 15:50, Klaus Schmidinger wrote:
I just switched to the latest (2003-07-25) CVS version of the DVB
driver, and much to my disappointment I had to realize that switching
between channels on different transponders now takes considerably
longer than with the DVB driver
On Friday 25 July 2003 16:44, Klaus Schmidinger wrote:
Oliver Endriss wrote:
...I recently changed I2C bus speed from 10.3kHz to 275kHz to speed
up tuning and I2C firmware downloads. At least it does for me. ;-)
Maybe this causes problems with some frontends if they need some
delays
On Friday 25 July 2003 17:32, Klaus Schmidinger wrote:
Oliver Endriss wrote:
On Friday 25 July 2003 16:44, Klaus Schmidinger wrote:
Oliver Endriss wrote:
...I recently changed I2C bus speed from 10.3kHz to 275kHz to
speed up tuning and I2C firmware downloads. At least it does
On Friday 25 July 2003 18:10, Klaus Schmidinger wrote:
Oliver Endriss wrote:
Hm, could you try to increase the speed again but set the delay to
500us or 1000us. I'd like to know whether it is a matter of bus
speed or a timing issue. I think that timing problems should be
fixed
On Friday 25 July 2003 19:32, Johannes Stezenbach wrote:
I wrote:
Anyway, we should find out if it's really the I2C speed that's
causing problems (I2C errors), or if some other timing is the
problem. I'm going tpo enable some debug prints to find out.
IIRC Robert Schlabbach suggested that
On Friday 25 July 2003 20:10, Johannes Stezenbach wrote:
Oliver Endriss wrote:
On Friday 25 July 2003 19:32, Johannes Stezenbach wrote:
These were due to a bug in scan. Now everything works rock solid
with the fast I2C timings; the max. number of iterations in
i2c_busy_rise_and_fall
On Friday 25 July 2003 20:46, Erik Tjernlund wrote:
Ok. I thought the dvb driver that's in the 2.6.x kernel was the same
as the linuxtv-dvb-driver and
No, linuxtv-dvb-1.0.0-pre3 and DVB CVS are for 2.4.x kernels *only*,
while dvb-kernel CVS works with 2.4 and 2.6 kernels.
Kernel 2.6.x contains
On Saturday 26 July 2003 01:08, Erik Tjernlund wrote:
Oliver Endriss wrote:
No, linuxtv-dvb-1.0.0-pre3 and DVB CVS are for 2.4.x kernels
*only*, while dvb-kernel CVS works with 2.4 and 2.6 kernels.
Kernel 2.6.x contains a recent snapshot of dvb-kernel.
Ok! Thanks for the information.
So
On Thursday 24 July 2003 23:51, bigg wrote:
I have also realised that the channels.conf that it's outputting,
doesn't seem to work with my VDR... (currently 1.1.27 with ac3
patches). Was there any kind of format change between 1.1.27 and
1.2 vdr's for teh channels.conf file?
Yes, from vdr
On Wednesday 23 July 2003 21:06, Guido Fiala wrote:
[old 0.9.4 firmware with new driver]
...
I observed only 2 problems so far - live viewing using analogtv does
repeatedly dropout and continue, probably the data are not supplied
as fast as they are consumed.
Extensive use of OSD sometimes
On Monday 14 July 2003 17:54, Johannes Stezenbach wrote:
Oliver Endriss wrote:
On Monday 14 July 2003 14:33, Johannes Stezenbach wrote:
What I get from Roberts description it's not a timing problem (it's
not sufficient to udelay(1), or do a dummy read from some other
register), but one
Hi Michael,
On Tuesday 15 July 2003 09:21, Michael Hunold wrote:
I'm sorry that I'm answering so late...
No problem. I guess most of us have to work sometimes. ;-)
Are ms-delays really required?
After I applied the following patch the cpu load dropped to 3%:
Hehe, once again: the i2c
On Monday 14 July 2003 17:34, Johannes Stezenbach wrote:
Oliver Endriss wrote:
BTW, I had a look into dvb-kernel and noticed that the i2c code is
interrupt-driven. A quick test showed that the fe thread caused
virtually no cpu load, even if the sat signal is missing!
Sorry, wrong
On Tuesday 15 July 2003 16:23, Matthew Davis wrote:
On Tuesday 15 July 2003 06:23 am, Oliver Endriss wrote:
Hm, I tested this and could *not* verify this problem:
Reading IICSTA always returns a valid value (busy flag set).
Really strange. Anyway, to be on the safe side, a dummy read
On Monday 14 July 2003 14:33, Johannes Stezenbach wrote:
Oliver Endriss wrote:
you might consider this patch:
[snip]
What not make explicit what Robert said (pseudo-code):
Well, Robert wrote:
| Hmm, I had mentioned this before. Try replacing the wait for the rise with
| an empty read
On Sunday 13 July 2003 08:53, Robert Schlabbach wrote:
From: Oliver Endriss [EMAIL PROTECTED]
Well, I found the reason for the high cpu load:
i2c_busy_rise_and_fall (saa7146.c) uses mdelay calls, i.e.
busy-waiting. Normally this is no problem, but it consumes 30% of
the cpu power when
On Sunday 13 July 2003 20:21, Andreas Kool wrote:
I can confirm the faster firmware upload and faster tuning here with
my DVB-C rev1.3
Apparently the speedup of the I2C transfers is the main improvement of
the patch. Hopefully all devices can handle a 275 kHz clock rate.
I don't know why the
On Sunday 13 July 2003 18:25, Oliver Endriss wrote:
[patch #1]
Tomi Ollila pointed out that the jiffies counter might wrap.
There is a small chance that this happens during an i2c transfer.
So, if your DVB box is running for a multiple of 497 days ;-)
you might consider this patch
On Saturday 12 July 2003 13:46, Andy carter wrote:
On Friday 11 July 2003 5:24 am, Oliver Endriss wrote:
On Friday 11 July 2003 01:21, Gregor Lawatscheck wrote:
At 22:20 10/07/2003, you wrote:
Either your revision of the card makes a difference or you're
in the lucky position
On Friday 11 July 2003 12:10, Oliver Endriss wrote:
Ok, I'll check again tonight for a longer period.
FYI, I'm using this setup:
- AMD K6-II 400 MHz
- linux kernel 2.4.21 from kernel.org
- single DVB-S Nexus 2.1
- DVB driver CVS 2003-06-28
- vdr-1.2.1 + remote control plugin
- no other
201 - 300 of 367 matches
Mail list logo
