[linux-dvb] Re: Unable to lock drivers with DVB 1.1.1 drivers and TT DVB-C

[Robert Schlabbach]

From: "Johannes Stezenbach" <[EMAIL PROTECTED]>
> I have a Siemens DVB-C and it works perfect (better than ever before)
> with the current drivers.

But can you receive S41 (466MHz) correctly with it? There is an unencrypted
test station "Test S41-2" on it (at least in parts of the Berlin cable
network). But my Siemens DVB-C cannot tune into it quite correctly, while
it can get the other cable channels (up to S38) just fine. There are too
many uncorrectable errors. I also notice a slight drop in signal strength
on S39/S40/S41 (down to ~80%, while the other channels are 93-94%). I think
the tuner may not be designed to receive any channels in this frequency
range :(

Regards,
--
Robert Schlabbach
e-mail: [EMAIL PROTECTED]
Berlin, Germany



-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: Unable to lock drivers with DVB 1.1.1 drivers and TT DVB-C

[Andrew de Quincey]

On Tuesday 09 March 2004 23:06, Johannes Stezenbach wrote:
> lamikr wrote:
> > I have problems for getting channels locked on Linux and I hope somebody
> > could help me.
> > (I have now fight with this for three days)
> > I have full featured TT DVB-C 2.1 card and I am able to seen channels on
> > windows.
>
> I have a Siemens DVB-C and it works perfect (better than ever before)
> with the current drivers.

Glad to hear it! 


-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: Unable to lock drivers with DVB 1.1.1 drivers and TT DVB-C

[lamikr]

I have full featured TT DVB-C 2.1 card and I am able to seen channels on 
windows.
   

I have a Siemens DVB-C and it works perfect (better than ever before)
with the current drivers.
 

Are you using 1.1.1 drivers or have you used Andrew's patches?

  subtv:4260:INVERSION_ON:690:AUTO:QAM_128:353:609
   

Have you tried INVERSION_OFF or INVERSION_AUTO?

Since dvbtune works I don't think it's the driver's fault.
 

I have now been able to get channels locked, I just found out that I can 
use "scan" to
generate channel conf for czap. After comparing old and new channel.conf 
I noticed that my handmade
channel.conf was missing the service id field.
I think it would be nice to have fields required documented somewhere. 
(Maybe in the README)
I can try to make some documentation patches after playing and learning 
more from the usage of my card -:)

After getting channel locked with czap I have also been also able to 
show channels by using command
   gxine dvb://
Command
   mplayer dvb://

did now work for me, instead it just gave me a errors I put in the end 
of the mail.

I am also wondering whether I am loading my drivers correctly in the 
modprope.conf.
I have put there following lines I found from one discussion in the net

   alias char-major-81 dvb-ttpci
   alias char-major-250 dvb-ttpci
   alias /dev/dvb/* dvb-ttpci
   alias /dev/dvb/adapter0/* dvb-ttpci
   alias /dev/video* dvb-ttpci
   install dvb-ttpci /sbin/modprobe --ignore-install dvb-ttpci; \
 /sbin/modprobe ves1820
There are however some issues I do not understand.
First one is the frontdriver, which one I should use and where does it 
affect on?
I have just put ves1820 blindly into my modprobe because I noticed from 
the cards.txt that
there is only it at76c651 available for the DVB-C frontend driver. Is it 
possible to use some program
for finding out all chips my dvb-card has?

Another issue (which belongs more to the VDR newsgroup) is the usage of 
vdr/kvdr.
How they really should work?  If I run "./vdr", the app will just block 
without showing any output.
kvdr gives me a flashing dialog, but nothing else appear there. (not 
even menu)

Mika

-
MPlayer 1.0pre3-3.3.2 (C) 2000-2003 MPlayer Team
CPU: Advanced Micro Devices Athlon MP/XP Thoroughbred 1532 MHz (Family: 
6, Stepping: 1)
Detected cache-line size is 64 bytes
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
Compiled with Runtime CPU Detection - WARNING - this is not optimal!
To get best performance, recompile MPlayer with 
--disable-runtime-cpudetection.Reading config file /etc/mplayer/mplayer.conf
Reading config file /root/.mplayer/config
Reading /root/.mplayer/codecs.conf: Can't open 
'/root/.mplayer/codecs.conf': No such file or directory
Reading /etc/mplayer/codecs.conf: 61 audio & 169 video codecs
font: can't open file: /root/.mplayer/font/font.desc
font: can't open file: /usr/share/mplayer/font/font.desc
Using Linux hardware RTC timing (1024Hz).
Can't open input config file /root/.mplayer/input.conf: No such file or 
directory
Input config file /etc/mplayer/input.conf parsed: 53 binds
Opening joystick device /dev/input/js0
Can't open joystick device /dev/input/js0 : No such file or directory
Can't init input joystick
Setting up LIRC support...
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support.
You will not be able to use your remote control.

Playing dvb://.
TUNER TYPE SEEMS TO BE DVB-C
code taken from dvbstream for mplayer v0.4pre1 - (C) Dave Chapman 2001
Released under the GPL.
Latest version available from http://www.linuxstb.org/
dvb_tune Freq: 16200
Cache fill:  0,00% (0 bytes)dvb_streaming_read, attempt N. 6 failed 
with errno 11 when reading 2048 bytes
Cache fill:  0,00% (0 bytes)dvb_streaming_read, attempt N. 5 failed 
with errno 11 when reading 2048 bytes
Cache fill:  0,00% (0 bytes)dvb_streaming_read, attempt N. 4 failed 
with errno 11 when reading 2048 bytes
Cache fill:  0,00% (0 bytes)dvb_streaming_read, attempt N. 3 failed 
with errno 11 when reading 2048 bytes
Cache fill:  0,00% (0 bytes)dvb_streaming_read, attempt N. 2 failed 
with errno 11 when reading 2048 bytes
Cache fill:  0,00% (0 bytes)dvb_streaming_read, attempt N. 1 failed 
with errno 11 when reading 2048 bytes
dvb_streaming_read, return 0 bytes
Cache fill:  0,00% (0 bytes)LMLM4 Stream Format not found
XMMS: found plugin: libcdaudio.so (CD Audio Player 1.2.9)
XMMS: found plugin: libmpg123.so (MPEG Layer 1/2/3 Player 1.2.9)
XMMS: found plugin: libtonegen.so (Tone Generator 1.2.9)
XMMS: found plugin: libvorbis.so (Ogg Vorbis Player 1.2.9)
XMMS: found plugin: libwav.so (Wave Player 1.2.9)
XMMS: Closing plugin /usr/lib/xmms/Input/libwav.so
XMMS: Closing plugin /usr/lib/xmms/Input/libvorbis.so
XMMS: Closing plugin /usr/lib/xmms/Input/libtonegen.so
XMMS: Closing plugin /usr/lib/xmms/Input/libmpg123.so
XMMS: Closing plugin /usr/lib/xmms/Input/libcdaudio.so





--

[linux-dvb] Re: Unable to lock drivers with DVB 1.1.1 drivers and TT DVB-C

[Johannes Stezenbach]

lamikr wrote:
> 
> I have problems for getting channels locked on Linux and I hope somebody 
> could help me.
> (I have now fight with this for three days)
> I have full featured TT DVB-C 2.1 card and I am able to seen channels on 
> windows.

I have a Siemens DVB-C and it works perfect (better than ever before)
with the current drivers.

>subtv:4260:INVERSION_ON:690:AUTO:QAM_128:353:609

Have you tried INVERSION_OFF or INVERSION_AUTO?

Since dvbtune works I don't think it's the driver's fault.

Johannes


-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: SkyStar-1, network code and section packing

[Johannes Stezenbach]

Denis Fedorishenko wrote:
> 
> I have question, maybe anyone can help in that.
> Many of my customers have SkyStar-1 card (if i am not wrong, full
> featured card), and they experiencing problem with receiving DVB/IP.
> 
> Problem is, when they trying to receive stream, just by setting
> interface, it is running well at start, but suddently stopping
> receiving traffic , after while.
> There is also some feedbacks, that is stopping faster depends
> of used bandwidth (more bandwidth - more faster it stopped).
> After setting interface to promisc it is running again, but sure after
> while stopping again (even if customer leave interface in promisc
> mode).
> 
> In default mode i mean -
> user: hw_sections = 1
> encapsulator: section packing turned on (max 100ms delay)
> 
> If i disable section packing on encap - it is not making any sense
> when hw_sections = 1.
> 
> Only one way, how i can make customer work good - it is when i turn
> off section packing, and he turn off hardware sections filter(?)(hw_sections = 0),
> but on this way i am loosing bandwidth, because of turned off section packing.

What happens with hw_sections=0 and enabled section packing?

> Is there any ideas?
> Btw, there is alternative driver
> (http://www.linux-dvb.tv/driver/index.html), who working with original Technotrend 
> firmware,
> it is working good, only one issue - it is unstable on some hardware
> configurations, and locking up machine completely, and another issue,
> it is not updated, to work on 2.6.

The bandwidth of the bus between av7110 and PCI is quite limited
(I don't have exact numbers, but I think 10..15MBit/s). I guess you
are close to that limit, and some insufficient error handling
in the firmware causes the filter to stop when buffers are
filled up with hw_sections=1. It shouldn't happen with
hw_sections=0, though.

Johannes


-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: hdtv & dvb

[Hamish Moffatt]

On Tue, Mar 09, 2004 at 02:34:09PM +0100, Milos Prudek wrote:
> 
> >We have HDTV channels on DVB-T in Australia. They play ok in xine
> >though I haven't tried AC3 passthrough or decoding.
> 
> I'm only interested in DVB-S.

OK, but I think HDTV is HDTV. Finding HDTV channels on satellites is a
different issue of course.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Unable to lock drivers with DVB 1.1.1 drivers and TT DVB-C

[lamikr]

Hi

I have problems for getting channels locked on Linux and I hope somebody 
could help me.
(I have now fight with this for three days)
I have full featured TT DVB-C 2.1 card and I am able to seen channels on 
windows.
For viewing channels on Linux I have loaded following apps and drivers.

   dvb drivers 1.1.1
   dvbtune-0.5
   dvb apps 1.1.0
I have been able to search channels with dvbtune but after creating 
config file for czap I have
not been able to get any of the channels locked. For watching TV I have 
tried following steps after booting into Linux.

   [root]#modprobe dvb-ttpci   (this command creates 
/sys/class/firmware directory for me)
   [root]#cd linuxtv-dvb-1.1.1/build-2.6  
   [root]#./insmod.sh load
   Inserting DVB modules into kernel
   FATAL: Module input not found.
   insmod: error inserting './dvb-core.ko': -1 File exists
   insmod: error inserting './saa7146.ko': -1 File exists
   insmod: error inserting './saa7146_vv.ko': -1 File exists
   insmod: error inserting './ttpci-eeprom.ko': -1 File exists
   insmod: error inserting './dvb-ttpci.ko': -1 File exists
   [root]#./dvbtune -f 42600 -s 6900 -qam 128 -I 1 -i > 426.xml
   Using DVB card "VES1820 based DVB-C frontend"
   tuning DVB-C to 42600, srate=690
   polling
   Getting frontend event
   FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER 
FE_HAS_VITERBI FE_HAS_SYNC
   Event:  Frequency: 436573047
   SymbolRate: 690
   FEC_inner:  0

   Bit error rate: 168480
   Signal strength: 60395
   SNR: 60909
   FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER 
FE_HAS_VITERBI FE_HAS_SYNC

Now I create "channels.conf-dvbc-jkl" by using dvbtune information from 
the xml.
If I create for example a configuration which contains following 
information for one channel

   subtv:4260:INVERSION_ON:690:AUTO:QAM_128:353:609

and try to lock the channel with czap, the locking will not work and 
will instead just show following

   [root]#./czap -c channels.conf-dvbc-jkl subtv
   using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
   reading channels from file 'channels.conf-dvbc-jkl'
 1 subtv:4260:INVERSION_ON:690:AUTO:QAM_128:353:609
 1 subtv: f 4260, s 690, i 1, fec -1, qam 4, v 0x161, a 0x261
   status 00 | signal b8b8 | snr c9c9 | ber 0032 | unc  |
   status 00 | signal b9b9 | snr c9c9 | ber 0032 | unc  |
   status 00 | signal b9b9 | snr caca | ber 0032 | unc  |
   status 00 | signal b9b9 | snr c9c9 | ber 0032 | unc  |
   status 00 | signal b9b9 | snr c9c9 | ber 0032 | unc  |
   status 00 | signal b9b9 | snr c6c6 | ber 0032 | unc  |
   status 00 | signal b9b9 | snr c7c7 | ber 0032 | unc  |
   status 00 | signal baba | snr c6c6 | ber 0032 | unc  |
   ...
Here is the xml I have generated with dvbtune


























































































































































In windows I have received following values for the subtv channel.

freq   service id  audio pid  video pid   teletext pid
org net id  inversion   qam
426.512257690516576
   01128

Mika

--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: linuxtv-dvb-1.1.1 has been released

[Nico]

>On Tuesday 09 March 2004 11:44, Nico wrote:
>> Andrew de Quincey wrote:
>> 
>>>
>> >>
>> >>this one always fails, and at line 1188 of the patched file you wrote
>> >>
>> >>swicth(state->frontend_type) instead of
>> >>swicth(state->tuner_type)
>> >
>> >Doh! sorry.
>> >
>> >Just to check. You were using 1.1.0 before, and it was fine?
>>
>> no, 1.1.x never and recent dvb-kernel since your commits to stv0299.c
>> never worked for me.
>>
>> Previous versions of dvb-kernel, 1.0.x and 2.6.x all work well.

>Right. This version should sort it out.

sorry, it doesn't. No tuning at all

   Nico

--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: Kernel OOPS

[Robert Schlabbach]

From: "Klaus Schmidinger" <[EMAIL PROTECTED]>
> Robert Schlabbach wrote:
> > 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"...

Noone said that anyone should throw anything away. I clearly stated the
future-looking development should be focused on _current_ technologies.
E.g. if you have to make a "hack" to expand function to other cards, make
that hack for the _legacy_ cards, not for current technology.

> 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... :-(

They don't like making products that don't sell. STB cards are too
expensive and to inflexible. A modern STB (aka "full-featured") card would
have to feature:

- HDTV MPEG-2 hardware decoding
- H.264/AVC hardware decoding
- WMV9 HD hardware decoding
- DVI/HDMI/HDCP and YbPbCr video outputs
- Dolby AC-3 hardware decoding
- optical audio outputs
- common interface

Personally, I wouldn't want to pay for all this junk. Why? Because I
already _have_ paid for most of it: I have a graphics card with DVI and
MPEG-2 hardware decoding support, a sound card with S/PDIF, and a CPU with
well enough power to handle the other stuff in software.

All I need is a pure receiver card which gets me the digital data stream,
and maybe a common interface slot or two to decrypt pay-TV channels. Why
should I pay for any further capabilities, which I already have?

Regards,
--
Robert Schlabbach
e-mail: [EMAIL PROTECTED]
Berlin, Germany



-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: tt dvb-c 2.1 and signal quality

[Torbjörn Jansson]

> My problem is the reverse, but I was going to get a new
> powersuply for my
> other computer, so when I get it I gues I coud switch them
> and see if it
> helps.
> I'll make sure I get a powersuply that is a bit more powefull
> than the one I
> have now.
> 
> Now that I think about it, maybe the dvb card and powesuply
> is the cause of
> some of the other problems I have had with the computer.
> A few days ago I got some strange lockups, it looked like
> disk problems. At
> that time I had not loaded any dvb drivers
> The next boot I loaded the dvb drivers and I have not seen
> any of the disk
> problems again.
> 
> So maybe the powersupply is not powefull enough, so it caused other
> problems. 

I have done some more testing.
If I start the kernel with the option "no-hlt" I get almost the same
improvement as when running a program that just consumes cpu.
I get some bit errors but most of the time uncorected errors is zero or very
low.



-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: DVB 1.1.1 driver loading problems with the 2.6 kernels

[lamikr]

Johannes Stezenbach wrote:

lamikr wrote:
 

 Mar  6 13:52:02 aragorn kernel: ttusb_dec: Unknown symbol request_firmware
   

You must enable CONFIG_FW_LOADER in your kernel config.

Actually it was the hotplugging service it was not up as I had thought. 
Starting it up allowed
"insmod.sh load" to work. Now I just need to get the dvb-c card to lock 
channels with czap.

Mika



--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: dvb-kernel frontend experimental patch v2

[Oliver Endriss]

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.
> * Andreas Share's ves1x93 improvements (which is why FE_RESET/FE_POLL can go)

Tuning does not work anymore with stv0299/BSRU6 (DVB-S rev. 2.1).
If I use stv0299.c from patch v1, it works again.
Any idea? Otherwise I'll look into this.

Oliver


-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: driver 1.1.1 compile error

[Johannes Schoeller]

From: "Michael Hunold" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Johannes Schoeller" <[EMAIL PROTECTED]>
Sent: Tuesday, March 09, 2004 3:16 PM
Subject: Re: [linux-dvb] Re: driver 1.1.1 compile error


> Hello Johannes,
>
> here is the problem:
> ---
> create symbolic link `include/linux/videodev2.h'
> to`/lib/modules/2.4.24/build/include/linux/videodev2.h'
> 
>
> Where does (usr/)include/linux/videodev2.h come from?

maybe from 1.1.0 driver? only thing i can imagine.

> If you don't know and don't need it by some particular reason, simply
> remove it, do a "make clean && make" again and all should be fine.

no. did not work. same problem. upgraded to 2.6.2 kernel and everything
works fine now.

thanks!

servus hannes

> CU
> Michael.
>



-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: tt dvb-c 2.1 and signal quality

[Torbjörn Jansson]

[EMAIL PROTECTED] <> wrote:
>  > > I get more errors when running setiathome while using
> czap but this
>  > > is on a computer that has lots of errors in windows as well.  > >
>  >
>  > It's strange that signal quality is affected by cpu usage (for
>  better or > worse), I mean isn't everything done in hardware when I
> use the tvout from
>  > the card?
>  >
>  > Is dvb cards more sensitive to interference than other tv
> cards? If so where
>  > is the interference coming from? Powersuply? Cpu? Or
> something else?
> 
> 
> I had a case myself where interferences started after upgrading from a
> 600 MHz Duron to a 1200 MHz Duron. High CPU usage directly
> caused dropouts
> in a version 1.3 full-featured TT DVB-S card. Cooling the
> card only helped a
> little. Exchanging the power supply solved it. The faster Duron just
> needed more power and the DVB card was very susceptible to
> slight variations
> (or even small dropouts) in the power, especially when the
> demodulator was already running hot.
> 

My problem is the reverse, but I was going to get a new powersuply for my
other computer, so when I get it I gues I coud switch them and see if it
helps.
I'll make sure I get a powersuply that is a bit more powefull than the one I
have now.

Now that I think about it, maybe the dvb card and powesuply is the cause of
some of the other problems I have had with the computer.
A few days ago I got some strange lockups, it looked like disk problems. At
that time I had not loaded any dvb drivers
The next boot I loaded the dvb drivers and I have not seen any of the disk
problems again.

So maybe the powersupply is not powefull enough, so it caused other
problems.



-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: hdtv & dvb

[Milos Prudek]

We have HDTV channels on DVB-T in Australia. They play ok in xine
though I haven't tried AC3 passthrough or decoding.
I'm only interested in DVB-S.

--
Milos Prudek


--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: Kernel OOPS

[Ralph Metzler]

Robert Schlabbach writes:
 > > KNC released the specs (no begging and/or disassembling necessary ...)
 > > but the code we wrote is currently bound to a commercial project. It
 > > works since almost a year (at least with the modules without hardware
 > > problems).
 > 
 > One question: Does the KNC CI allow changing the voltage supplied to the
 > CAM? If I understand EN50221 right, the CAM may specify a supply voltage
 > other than 5V. However, the TT CI does not seem to allow controlling the
 > supply voltage, I assume it is fixed at 5V. Do all known CAMs use 5V supply
 > voltage?

The KNC CI interface (at least the one I have) is fixed to 5V.
I guess all the usual CAMs on the market currently use 5V.


Ralph


-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: hdtv & dvb

[Christian Schuld]

Hi,

Am Dienstag, 9. März 2004 13:32 schrieb p z :
> I know about one HDTV channel EURO1080 on astra.
>
> Last time I try it was free, but will be encrypted.
>
> recording was simple:
> cat /dev/dvb/adapter0/dvr0 > file

AFAIK this will only work for so called "budget" cards. Av7110 based cards 
can't handle the high bandwidth.

> Peter

-- 
Viele Grüße
Christian



-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: hdtv & dvb

[Hamish Moffatt]

On Tue, Mar 09, 2004 at 01:32:29PM +0100, p z  wrote:
> I know about one HDTV channel EURO1080 on astra.
> 
> Last time I try it was free, but will be encrypted.
> 
> recording was simple:
> cat /dev/dvb/adapter0/dvr0 > file

We have HDTV channels on DVB-T in Australia. They play ok in xine
though I haven't tried AC3 passthrough or decoding.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: tt dvb-c 2.1 and signal quality

[Ralph Metzler]

 > > I get more errors when running setiathome while using czap but this
 > > is on a computer that has lots of errors in windows as well.
 > > 
 > 
 > It's strange that signal quality is affected by cpu usage (for better or
 > worse), I mean isn't everything done in hardware when I use the tvout from
 > the card?
 > 
 > Is dvb cards more sensitive to interference than other tv cards? If so where
 > is the interference coming from? Powersuply? Cpu? Or something else?


I had a case myself where interferences started after upgrading from a
600 MHz Duron to a 1200 MHz Duron. High CPU usage directly caused dropouts
in a version 1.3 full-featured TT DVB-S card. Cooling the card only helped a
little. Exchanging the power supply solved it. The faster Duron just
needed more power and the DVB card was very susceptible to slight variations
(or even small dropouts) in the power, especially when the demodulator was
already running hot.


Ralph


 


-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: dvb-kernel frontend experimental patch v2

[Andrew de Quincey]

On Tuesday 09 March 2004 12:30, Johannes Stezenbach wrote:
> 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.
> > * Andreas Share's ves1x93 improvements (which is why FE_RESET/FE_POLL can
> > go)
>
>   dvb-kernel/build-2.6/ves1x93.c: In function `ves1x93_clr_bit':
>   dvb-kernel/build-2.6/ves1x93.c:250: warning: implicit declaration of
> function `dvb_delay'
>
> and later:
>
>   ves1x93: Unknown symbol dvb_delay
>
> --- ves1x93.c.orig2004-03-09 13:30:22.0 +0100
> +++ ves1x93.c 2004-03-09 13:16:12.0 +0100
> @@ -30,6 +30,7 @@
>  #include 
>
>  #include "dvb_frontend.h"
> +#include "dvb_functions.h"
>
>  static int debug = 0;
>  #define dprintk  if (debug) printk

Thanks, included. 

VERY weird though. It compiles on mine without dvb_functions.h being imported 
somehow!


-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: hdtv & dvb

[p z oooo]

I know about one HDTV channel EURO1080 on astra.

Last time I try it was free, but will be encrypted.

recording was simple:
cat /dev/dvb/adapter0/dvr0 > file

Peter
== REKLAMA 
Spolocnost SUN Microsystems uviedla na trh novy server Sun Fire V20z
zalozeny procesoroch AMD Opteron.
Viac informacii najdete na : http://www.somi.sk/sun/v20z.php
===



-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: dvb-kernel frontend experimental patch v2

[Johannes Stezenbach]

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.
> * Andreas Share's ves1x93 improvements (which is why FE_RESET/FE_POLL can go)

  dvb-kernel/build-2.6/ves1x93.c: In function `ves1x93_clr_bit':
  dvb-kernel/build-2.6/ves1x93.c:250: warning: implicit declaration of function 
`dvb_delay'

and later:

  ves1x93: Unknown symbol dvb_delay

--- ves1x93.c.orig  2004-03-09 13:30:22.0 +0100
+++ ves1x93.c   2004-03-09 13:16:12.0 +0100
@@ -30,6 +30,7 @@
 #include 
 
 #include "dvb_frontend.h"
+#include "dvb_functions.h"
 
 static int debug = 0;
 #define dprintkif (debug) printk


Johannes


-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: tt dvb-c 2.1 and signal quality

[Torbjörn Jansson]

[EMAIL PROTECTED] <> wrote:
>> Torbjörn Jansson  wrote:
>>> As some of you probably already know i have problem with the
>>> signal quality on my dvb-c card, i get lots of bit errors and
>>> uncorectable errors on some channels.
>>> 
>>> I found something intresting by accident.
>>> I left czap running on a channel that i have problem with
>>> (DisMix) and then started to compile the dvb-kernel drivers.
>>> During the compilation i noticed that the audio from my tv
>>> didn't have those audio noises that occurs with bad signal
>>> any more, so i checked the output from czap and there was no errors
>>> at all. 
>>> 
>>> So as long as i have a program that burns cpu i get perfect
>>> signal, zero ber and zero unc.
> 
> I get more errors when running setiathome while using czap but this
> is on a computer that has lots of errors in windows as well.
> 

It's strange that signal quality is affected by cpu usage (for better or
worse), I mean isn't everything done in hardware when I use the tvout from
the card?

Is dvb cards more sensitive to interference than other tv cards? If so where
is the interference coming from? Powersuply? Cpu? Or something else?



-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] hdtv & dvb

[Milos Prudek]

I've read a discussion about HDTV and DVB in Linux on this list, but I'm 
fairly new to this. Could anyone sum up the current state of affairs of 
HDTV via DVB on Linux, please?

- Is there a software that supports watching and recording of HDTV on 
Linux? Can MythTV do this?

- Is it worth attempting with regards to the number of English language 
channels available in Europe? In other words how many HDTV channels are 
broadcasted in Europe? Are all of them encrypted?

- What about watching encrypted channels, both oficially and unofficially?

--
Milos Prudek


--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: tt dvb-c 2.1 and signal quality

[Daniel Sangenberg]

> Torbjörn Jansson  wrote:
>> As some of you probably already know i have problem with the
>> signal quality on my dvb-c card, i get lots of bit errors and
>> uncorectable errors on some channels.
>>
>> I found something intresting by accident.
>> I left czap running on a channel that i have problem with
>> (DisMix) and then started to compile the dvb-kernel drivers.
>> During the compilation i noticed that the audio from my tv
>> didn't have those audio noises that occurs with bad signal
>> any more, so i checked the output from czap and there was no errors
>> at all.
>>
>> So as long as i have a program that burns cpu i get perfect
>> signal, zero ber and zero unc.

I get more errors when running setiathome while using czap but this is on a
computer that has lots of errors in windows as well.

-- 
Daniel




-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] SkyStar-1, network code and section packing

[Denis Fedorishenko]

Hello everybody

I have question, maybe anyone can help in that.
Many of my customers have SkyStar-1 card (if i am not wrong, full
featured card), and they experiencing problem with receiving DVB/IP.

Problem is, when they trying to receive stream, just by setting
interface, it is running well at start, but suddently stopping
receiving traffic , after while.
There is also some feedbacks, that is stopping faster depends
of used bandwidth (more bandwidth - more faster it stopped).
After setting interface to promisc it is running again, but sure after
while stopping again (even if customer leave interface in promisc
mode).

In default mode i mean -
user: hw_sections = 1
encapsulator: section packing turned on (max 100ms delay)

If i disable section packing on encap - it is not making any sense
when hw_sections = 1.

Only one way, how i can make customer work good - it is when i turn
off section packing, and he turn off hardware sections filter(?)(hw_sections = 0),
but on this way i am loosing bandwidth, because of turned off section packing.

Is there any ideas?
Btw, there is alternative driver
(http://www.linux-dvb.tv/driver/index.html), who working with original Technotrend 
firmware,
it is working good, only one issue - it is unstable on some hardware
configurations, and locking up machine completely, and another issue,
it is not updated, to work on 2.6.

-- 
Best regards,
 Denis  mailto:[EMAIL PROTECTED]



-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: Frontend experimental patch v1

[Johannes Stezenbach]

On Tue, Mar 09, 2004 at 03:20:35AM +0100, Oliver Endriss wrote:
> On Tuesday 09 March 2004 02:54, Andrew de Quincey wrote:
> > 
> > IMO, that should be done in userspace... when the apps are first scanning for 
> > TV signals they should use AUTO.. when they get a lock, they should record 
> > them and use the non-AUTO values.
> 
> Nack. Afaik there are some cards around, which require a different
> inversion setting than others. So the application had to store that
> inversion setting for each card. That's bad [tm].

Nope. It's sufficient to have one flag per card which
means "this card is different that the others" ;-)

> So the application should not care about inversion at all.
> If the the driver tries the last working inversion setting first, there
> should be no performance problem with INVERSION_AUTO.

I still think that explicit inversion setting is a useful optimization.

> > The frontend core only does autoinversion if the app requests it in 
> > SET_FRONTEND with INVERSION_AUTO... I think is how the API is supposed to 
> > work anyway.
> 
> Imho the inversion stuff should be completely removed from the API.

No way!

> Anyway, when using INVERSION_AUTO, the driver is free to use the last
> working inversion setting. It will speed-up tuning.

ACK

Johannes


-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] driver 1.1.1 compile error

[Johannes Schoeller]

hi list

i have a problem compiling driver version 1.1.1.
1.1.0 was no problem at all and did work (although switching channels took
about 5s).

pls take a look at http://nopaste.php.cd/10236

thanks for any help

servus hannes



-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: Kernel OOPS

[Holger Waechtler]

Oliver Endriss wrote:

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 descrambler under GPL.
   

There already are plenty available under GPL.
But you might get problems with the patent if you do not have enough money
to defend yourself against (currently actually still) illegal software patents.
 

right, some lawyers might run amok, but you should be able to win the 
lawsuit -- at time of patent application it was definitely not possible 
to protect software, mathematical formulas and algorithms by patents in 
europe.
   

Well, any valunteers here who can spend millions of $ to find out?
 

*g*

If you always wait until somebody else safeguards what you're doing and 
everybody else behaves like you it would not be possible to watch DVDs 
under Linux at all. DVB probably too. Media playback in general.

Don't let them ablate your brain, otherwise you even believe SCO one day 
that Linux is illegal due to license infringement. It's too easy to 
spread out uncertainity and doubts...

Holger



--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.

[linux-dvb] Re: Kernel OOPS

[Mario Ivankovits]

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.

  
  
I don't think that people are going to throw away their
full featured cards just because some people say "they have no future"...
  

And isnt it, that the tv-out quality of the ff-card is much better than
the routed picture through the tv-out of the graphics card?
So why should such a design have no future?


Ciao,
Mario




smime.p7s
Description: S/MIME Cryptographic Signature

[linux-dvb] dvb-kernel frontend experimental patch v2

[Andrew de Quincey]

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.
* Andreas Share's ves1x93 improvements (which is why FE_RESET/FE_POLL can go)
Index: linux/drivers/media/dvb/dvb-core/dvb_frontend.c
===
RCS file: /cvs/linuxtv/dvb-kernel/linux/drivers/media/dvb/dvb-core/dvb_frontend.c,v
retrieving revision 1.70
diff -a -u -b -r1.70 dvb_frontend.c
--- linux/drivers/media/dvb/dvb-core/dvb_frontend.c	1 Mar 2004 19:11:18 -	1.70
+++ linux/drivers/media/dvb/dvb-core/dvb_frontend.c	9 Mar 2004 00:52:04 -
@@ -46,8 +46,8 @@
 #define FESTATE_TUNED 16
 #define FESTATE_ZIGZAG_FAST 32
 #define FESTATE_ZIGZAG_SLOW 64
-#define FESTATE_CLEAN_SETUP 128
-#define FESTATE_SEARCHING (FESTATE_TUNING_FAST | FESTATE_TUNING_SLOW | FESTATE_ZIGZAG_FAST | FESTATE_ZIGZAG_SLOW)
+#define FESTATE_DISEQC 128
+#define FESTATE_WAITFORLOCK (FESTATE_TUNING_FAST | FESTATE_TUNING_SLOW | FESTATE_ZIGZAG_FAST | FESTATE_ZIGZAG_SLOW | FESTATE_DISEQC)
 #define FESTATE_SEARCHING_FAST (FESTATE_TUNING_FAST | FESTATE_ZIGZAG_FAST)
 #define FESTATE_SEARCHING_SLOW (FESTATE_TUNING_SLOW | FESTATE_ZIGZAG_SLOW)
 #define FESTATE_LOSTLOCK (FESTATE_ZIGZAG_FAST | FESTATE_ZIGZAG_SLOW)
@@ -59,8 +59,8 @@
  * FESTATE_TUNED. The frontend has successfully locked on.
  * FESTATE_ZIGZAG_FAST. The lock has been lost, and a fast zigzag has been initiated to try and regain it.
  * FESTATE_ZIGZAG_SLOW. The lock has been lost. Fast zigzag has been failed, so we're trying again, but slower.
- * FESTATE_CLEAN_SETUP. Used for certain dodgy tuners which need special massaging to lock.
- * FESTATE_SEARCHING. When we're searching for a signal using a zigzag scan of any sort.
+ * FESTATE_DISEQC. A DISEQC command has just been issued.
+ * FESTATE_WAITFORLOCK. When we're waiting for a lock.
  * FESTATE_SEARCHING_FAST. When we're searching for a signal using a fast zigzag scan.
  * FESTATE_SEARCHING_SLOW. When we're searching for a signal using a slow zigzag scan.
  * FESTATE_LOSTLOCK. When the lock has been lost, and we're searching it again.
@@ -69,7 +69,10 @@
 
 static int dvb_frontend_debug = 0;
 static int dvb_shutdown_timeout = 5;
-static int dvb_frequency_bending = 1;
+static int dvb_override_frequency_bending = 0;
+static int dvb_force_auto_inversion = 0;
+
+static int do_frequency_bending = 0;
 
 #define dprintk if (dvb_frontend_debug) printk
 
@@ -103,6 +106,8 @@
 int auto_count;
 int started_auto_count;
 int min_delay;
+int max_drift;
+int step_size;
 	int exit;
 fe_status_t status;
 };
@@ -357,8 +362,6 @@
  */
 static int dvb_frontend_autotune(struct dvb_frontend_data *fe)
 {
-int stepsize;
-int maxdrift;
 int autoinversion;
 int ready = 0;
 int wrapped = 0;
@@ -367,41 +370,14 @@
 
 	dprintk ("%s\n", __FUNCTION__);
 
-// choose step size for zigzag scan
-	switch(fe->info->type) {
-	case FE_QPSK:
-	if (fe->parameters.u.qpsk.symbol_rate < 1000) {
-	stepsize = fe->parameters.u.qpsk.symbol_rate / 32000;
-	maxdrift = 5000;
-	} else {
-		stepsize = fe->parameters.u.qpsk.symbol_rate / 16000;
-		maxdrift = fe->parameters.u.qpsk.symbol_rate / 2000;
-		}
-	break;
-	
-	case FE_QAM:
-		stepsize = 1;
-	maxdrift = 0; // don't want any zigzagging under DVB-C frontends
-	break;
-	
-	case FE_OFDM:
-	stepsize = fe->info->frequency_stepsize * 2;
-	maxdrift = (fe->info->frequency_stepsize * 2) + 1;
-	break;
-	
-	default:
-	printk("Unknown frontend type %i\n", fe->info->type);
-	return 0;
-	}
-
 // are we using autoinversion?
 autoinversion = ((!(fe->info->caps & FE_CAN_INVERSION_AUTO)) && (fe->parameters.inversion == INVERSION_AUTO));
 
 // setup parameters correctly
 while(!ready) {
 	// wrap the count if we've reached the maximum drift
-	fe->lnb_drift = (fe->auto_count / 4) * stepsize;
-	if (fe->lnb_drift >= maxdrift) {
+	fe->lnb_drift = (fe->auto_count / 4) * fe->step_size;
+	if (fe->lnb_drift > fe->max_drift) {
 		fe->auto_count = 0;
 		fe->lnb_drift = 0;
 		wrapped = 1;
@@ -442,8 +418,8 @@
 	if (!ready) fe->auto_count++;
 	}

-// perform frequency bending if enabled
-if (dvb_frequency_bending)
+// perform frequency bending if necessary
+if ((dvb_override_frequency_bending != 1) && do_frequency_bending)
 dvb_bend_frequency(fe, 0);

 // set the frontend itself
@@ -453,9 +429,6 @@
 	fe->parameters.frequency = original_frequency;
 fe->parameters.inversion = original_inversion;
 
-// reset frontend IRQ bits to clean error stats
-	dvb_front

[linux-dvb] Re: Kernel OOPS

[Klaus Schmidinger]

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

[Marcel Siegert]

On Tuesday 09 March 2004 00:54, Oliver Endriss wrote:
> 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-featured cards are "legacy hardware", they have no future. Thus,
> > future looking development should be centered around _current_ hardware,
> > and it has become quite obvious that so-called "budget" cards are a much
> > better solution, because they are cheap and allow much more flexibility
> > when it comes to handling the incoming data, simply because that's all done
> > in software.
> 
> Well, this has been discussed before. More than enough, imho.
> Even 'current' hardware will be outdated soon...
Maybe exactly this this the most important thing. Think about not supporting or fixing
any kind of driver because the Hardware may be outdated soon. 

Ever thought of ISA Plug&Play support in the Linux Kernel? Why it is still there?
Haven't seen a board with ISA slots for a long time now - but - there are still people 
using the Linux Kernel on machines which offer isa slots and isa plug'n'pray :)

I upset about myself not to have enough knowledge for developing kernel driver and/or
TS/PES conversions. Maybe i have to improve this someday :)

cu
mws




-- 
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as 
subject.