[linux-dvb] Tuning problems with loss of TS packets

[linux-dvb] Tuning problems with loss of TS packets

[Josef Wolf]

Hello,

sometimes, I experience non-deterministic problems with tuning on some
transponders with dvb-s.  For example, on astra-H-11954, I have about
50% chance to get a good tune.  If I get a bad tune, I still receive
TS packets from the chosen transponder, but about 10%..20% of the
packets are lost.  The (remaining) packets contain PAT/PMT/PES packets
from the chosen transponder, so it is pretty safe to assume that
actual tuning worked properly.

What I do is pretty much straight forward:

  1. open frontend/dmx/dvr devices
  2. send diseqc command to switch to desired input
  3. use FE_SET_FRONTEND ioctl to tune to desired transponder
  4. wait for FE_HAS_LOCK
  5. set dmx_pesfilter_params to:
         pid:      0x2000  /* yes, I want the whole transponder */
         input:    DMX_IN_FRONTEND
         output:   DMX_OUT_TS_TAP
         pes_type: DMX_PES_OTHER
         flags:    DMX_IMMEDIATE_START

With this sequence, I have about 50% chance to receive a proper TS
stream.  When the stream is not OK, I can see about 10%..20% loss
of TS packets.

I have checked signal quality, but there is no significant difference
from working to non-working:

   Status:1f sig:ac80 snr:d9e0 ber:00000000 unc:fffffffe FE_HAS_LOCK
   Status:1f sig:adbe snr:dac4 ber:00000000 unc:fffffffe FE_HAS_LOCK

So I have tried to narrow the problem, and I think I've come pretty
close (but still no cigar):

Once the sequence (which is listed above) is completed, I can easily
(but randomly, IOW: I have to try 1..3 times) switch from proper stream
to broken stream and vice-versa simply by repeating step 3 with _exactly_
the _same_ values.

To be precise: on an already set-up transponder, re-executing this
function:

  static void tune_frequency (int ifreq, int sr)
  {
      struct dvb_frontend_parameters tuneto;
  
      tuneto.frequency = ifreq*1000;
      tuneto.inversion = INVERSION_AUTO;
      tuneto.u.qpsk.symbol_rate = sr*1000;
      tuneto.u.qpsk.fec_inner = FEC_AUTO;
      
      if (ioctl(fefd, FE_SET_FRONTEND, &tuneto) == -1) {
          fatal ("FE_SET_FRONTEND failed: %s\n", strerror (errno));
      }
  }

with _exactly_ the same values for ifreq and sr, is able to toggle from
good TS stream to bad TS stream or vice-versa.  As long as I avoid to
call this function, the quality of the stream does _not_ change.

I have tried to use fixed values instead of *_AUTO for FEC and INVERSION,
but that did not help either.

Any ideas?


BTW:
 $ lspci -v
 [ ... ]
 03:07.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
         Subsystem: Technotrend Systemtechnik GmbH Technotrend-Budget/Hauppauge WinTV-NOVA-CI DVB card
         Flags: bus master, medium devsel, latency 32, IRQ 21
         Memory at fdcfe000 (32-bit, non-prefetchable) [size=512]
         Kernel driver in use: budget_ci dvb
         Kernel modules: snd-aw2, budget-ci
 $ uname -a
 Linux raven 2.6.27.7-9-default #1 SMP 2008-12-04 18:10:04 +0100 x86_64 x86_64 x86_64 GNU/Linux

_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Tuning problems with loss of TS packets

[Alex Betis]

[-- Attachment #1.1: Type: text/plain, Size: 3824 bytes --]

On Sat, Feb 7, 2009 at 3:57 AM, Josef Wolf <jw@raven.inka.de> wrote:

> Hello,
>
> sometimes, I experience non-deterministic problems with tuning on some
> transponders with dvb-s.  For example, on astra-H-11954, I have about
> 50% chance to get a good tune.  If I get a bad tune, I still receive
> TS packets from the chosen transponder, but about 10%..20% of the
> packets are lost.  The (remaining) packets contain PAT/PMT/PES packets
> from the chosen transponder, so it is pretty safe to assume that
> actual tuning worked properly.
>
> What I do is pretty much straight forward:
>
>  1. open frontend/dmx/dvr devices
>  2. send diseqc command to switch to desired input
>  3. use FE_SET_FRONTEND ioctl to tune to desired transponder
>  4. wait for FE_HAS_LOCK
>  5. set dmx_pesfilter_params to:
>         pid:      0x2000  /* yes, I want the whole transponder */
>         input:    DMX_IN_FRONTEND
>         output:   DMX_OUT_TS_TAP
>         pes_type: DMX_PES_OTHER
>         flags:    DMX_IMMEDIATE_START
>
> With this sequence, I have about 50% chance to receive a proper TS
> stream.  When the stream is not OK, I can see about 10%..20% loss
> of TS packets.
>
> I have checked signal quality, but there is no significant difference
> from working to non-working:
>
>   Status:1f sig:ac80 snr:d9e0 ber:00000000 unc:fffffffe FE_HAS_LOCK
>   Status:1f sig:adbe snr:dac4 ber:00000000 unc:fffffffe FE_HAS_LOCK
>
> So I have tried to narrow the problem, and I think I've come pretty
> close (but still no cigar):
>
> Once the sequence (which is listed above) is completed, I can easily
> (but randomly, IOW: I have to try 1..3 times) switch from proper stream
> to broken stream and vice-versa simply by repeating step 3 with _exactly_
> the _same_ values.
>
> To be precise: on an already set-up transponder, re-executing this
> function:
>
>  static void tune_frequency (int ifreq, int sr)
>  {
>      struct dvb_frontend_parameters tuneto;
>
>      tuneto.frequency = ifreq*1000;
>      tuneto.inversion = INVERSION_AUTO;
>      tuneto.u.qpsk.symbol_rate = sr*1000;
>      tuneto.u.qpsk.fec_inner = FEC_AUTO;
>
>      if (ioctl(fefd, FE_SET_FRONTEND, &tuneto) == -1) {
>          fatal ("FE_SET_FRONTEND failed: %s\n", strerror (errno));
>      }
>  }
>
> with _exactly_ the same values for ifreq and sr, is able to toggle from
> good TS stream to bad TS stream or vice-versa.  As long as I avoid to
> call this function, the quality of the stream does _not_ change.

I had exactly the same behavior of Twinhan SP-200 (1027) card until I
totally gave up and bought Twinhan SP-400 (1041) card.
Interesting if those 2 cards have the same components.


>
>
> I have tried to use fixed values instead of *_AUTO for FEC and INVERSION,
> but that did not help either.
>
> Any ideas?

What driver repository you use? And what driver is loaded for that card?
My guess was that the tuner is not properly reset/set before the tuning.
But (again) since I don't have any chip specification, I didn't have much
progress with that.



>
>
> BTW:
>  $ lspci -v
>  [ ... ]
>  03:07.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
>         Subsystem: Technotrend Systemtechnik GmbH
> Technotrend-Budget/Hauppauge WinTV-NOVA-CI DVB card
>         Flags: bus master, medium devsel, latency 32, IRQ 21
>         Memory at fdcfe000 (32-bit, non-prefetchable) [size=512]
>         Kernel driver in use: budget_ci dvb
>         Kernel modules: snd-aw2, budget-ci
>  $ uname -a
>  Linux raven 2.6.27.7-9-default #1 SMP 2008-12-04 18:10:04 +0100 x86_64
> x86_64 x86_64 GNU/Linux
>
> _______________________________________________
> linux-dvb users mailing list
> For V4L/DVB development, please use instead linux-media@vger.kernel.org
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>

[-- Attachment #1.2: Type: text/html, Size: 5416 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Tuning problems with loss of TS packets

[Josef Wolf]

On Sat, Feb 07, 2009 at 11:12:25AM +0200, Alex Betis wrote:
[ ... ]
> > To be precise: on an already set-up transponder, re-executing this
> > function:
> >
> >  static void tune_frequency (int ifreq, int sr)
> >  {
> >      struct dvb_frontend_parameters tuneto;
> >
> >      tuneto.frequency = ifreq*1000;
> >      tuneto.inversion = INVERSION_AUTO;
> >      tuneto.u.qpsk.symbol_rate = sr*1000;
> >      tuneto.u.qpsk.fec_inner = FEC_AUTO;
> >
> >      if (ioctl(fefd, FE_SET_FRONTEND, &tuneto) == -1) {
> >          fatal ("FE_SET_FRONTEND failed: %s\n", strerror (errno));
> >      }
> >  }
> >
> > with _exactly_ the same values for ifreq and sr, is able to toggle from
> > good TS stream to bad TS stream or vice-versa.  As long as I avoid to
> > call this function, the quality of the stream does _not_ change.
> 
> I had exactly the same behavior of Twinhan SP-200 (1027) card until I
> totally gave up and bought Twinhan SP-400 (1041) card.
> Interesting if those 2 cards have the same components.

The cards I have are of those:
http://www.linuxtv.org/wiki/index.php/TechnoTrend_PCline_budget_DVB-S
Do you think the problem is related to hardware?

> > I have tried to use fixed values instead of *_AUTO for FEC and INVERSION,
> > but that did not help either.
> >
> > Any ideas?
> 
> What driver repository you use? And what driver is loaded for that card?
> My guess was that the tuner is not properly reset/set before the tuning.
> But (again) since I don't have any chip specification, I didn't have much
> progress with that.

  # lsmod|egrep '(dvb|budget|stv|saa|ttpci)'
  stv0299                11280  1
  budget_ci              18956  3
  budget_core            12332  1 budget_ci
  dvb_core               87948  3 stv0299,budget_ci,budget_core
  saa7146                18080  2 budget_ci,budget_core
  ttpci_eeprom            2520  1 budget_core
  ir_common              43340  1 budget_ci
  i2c_core               35280  5 stv0299,budget_ci,budget_core,ttpci_eeprom,i2c_piix4
  #

I have not yet compiled my own drivers, so I use the drivers that came
with the disro (opensuse-11.1, x86_64).  But I am about to dive into the
driver to narrow down the problem closer.  Any hint how to compile my
own drivers on opensuse?

_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Tuning problems with loss of TS packets

[Alex Betis]

[-- Attachment #1.1: Type: text/plain, Size: 2942 bytes --]

On Sat, Feb 7, 2009 at 12:57 PM, Josef Wolf <jw@raven.inka.de> wrote:

> On Sat, Feb 07, 2009 at 11:12:25AM +0200, Alex Betis wrote:
> [ ... ]
> > > To be precise: on an already set-up transponder, re-executing this
> > > function:
> > >
> > >  static void tune_frequency (int ifreq, int sr)
> > >  {
> > >      struct dvb_frontend_parameters tuneto;
> > >
> > >      tuneto.frequency = ifreq*1000;
> > >      tuneto.inversion = INVERSION_AUTO;
> > >      tuneto.u.qpsk.symbol_rate = sr*1000;
> > >      tuneto.u.qpsk.fec_inner = FEC_AUTO;
> > >
> > >      if (ioctl(fefd, FE_SET_FRONTEND, &tuneto) == -1) {
> > >          fatal ("FE_SET_FRONTEND failed: %s\n", strerror (errno));
> > >      }
> > >  }
> > >
> > > with _exactly_ the same values for ifreq and sr, is able to toggle from
> > > good TS stream to bad TS stream or vice-versa.  As long as I avoid to
> > > call this function, the quality of the stream does _not_ change.
> >
> > I had exactly the same behavior of Twinhan SP-200 (1027) card until I
> > totally gave up and bought Twinhan SP-400 (1041) card.
> > Interesting if those 2 cards have the same components.
>
> The cards I have are of those:
> http://www.linuxtv.org/wiki/index.php/TechnoTrend_PCline_budget_DVB-S
> Do you think the problem is related to hardware?


Since the tuning works from time to time, I tend to think that its a driver
problem.


>
>
> > > I have tried to use fixed values instead of *_AUTO for FEC and
> INVERSION,
> > > but that did not help either.
> > >
> > > Any ideas?
> >
> > What driver repository you use? And what driver is loaded for that card?
> > My guess was that the tuner is not properly reset/set before the tuning.
> > But (again) since I don't have any chip specification, I didn't have much
> > progress with that.
>
>  # lsmod|egrep '(dvb|budget|stv|saa|ttpci)'
>  stv0299                11280  1
>  budget_ci              18956  3
>  budget_core            12332  1 budget_ci
>  dvb_core               87948  3 stv0299,budget_ci,budget_core
>  saa7146                18080  2 budget_ci,budget_core
>  ttpci_eeprom            2520  1 budget_core
>  ir_common              43340  1 budget_ci
>  i2c_core               35280  5
> stv0299,budget_ci,budget_core,ttpci_eeprom,i2c_piix4
>  #
>
Don't remember when drivers it used, I've removed it from my box long ago.


>
> I have not yet compiled my own drivers, so I use the drivers that came
> with the disro (opensuse-11.1, x86_64).  But I am about to dive into the
> driver to narrow down the problem closer.  Any hint how to compile my
> own drivers on opensuse?

I dont have opensuse, but I'd suggest to use this repository:
http://mercurial.intuxication.org/hg/s2-liplianin


>
>
> _______________________________________________
> linux-dvb users mailing list
> For V4L/DVB development, please use instead linux-media@vger.kernel.org
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>

[-- Attachment #1.2: Type: text/html, Size: 4991 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Tuning problems with loss of TS packets

[Josef Wolf]

On Sat, Feb 07, 2009 at 02:57:44AM +0100, Josef Wolf wrote:
> Hello,
> 
> sometimes, I experience non-deterministic problems with tuning on some
> transponders with dvb-s.  For example, on astra-H-11954, I have about
> 50% chance to get a good tune.  If I get a bad tune, I still receive
> TS packets from the chosen transponder, but about 10%..20% of the
> packets are lost.  The (remaining) packets contain PAT/PMT/PES packets
> from the chosen transponder, so it is pretty safe to assume that
> actual tuning worked properly.

I have tried to analyze the cc (continuation counter) field of the TS
packets to get more clue. This is what I found on the astra-H-11954 (zdf)
transponder:

When I get a "bad" tune (that is: mplayer and vlc get stuck), the
cc errors are unsystematic.  All PIDs are affected, and the amount
of lost packets varies.  But from time to time regularities can be
seen:

     cc pid:967 expect:3  got:5   *
     cc pid:970 expect:3  got:5   *
     cc pid:966 expect:3  got:5   *
     cc pid:18  expect:10 got:11
     cc pid:969 expect:5  got:6
     cc pid:131 expect:10 got:9
     cc pid:710 expect:7  got:11
     cc pid:967 expect:13 got:15   *
     cc pid:970 expect:13 got:15   *
     cc pid:966 expect:13 got:15   *
     cc pid:968 expect:11 got:13
     cc pid:230 expect:12 got:15
     cc pid:330 expect:5  got:8
     cc pid:620 expect:1  got:5
     cc pid:130 expect:5  got:9   +
     cc pid:630 expect:5  got:9   +
     cc pid:220 expect:6  got:10
     cc pid:120 expect:14 got:2
     cc pid:968 expect:4  got:6
     cc pid:967 expect:7  got:9   *
     cc pid:970 expect:7  got:9   *
     cc pid:966 expect:7  got:9   *

I have marked the interesting lines.  Most interesting are the lines
marked with stars.  This is the same sequence of PIDs in the same
order and with the same amount of lost packets.  This does not look
like a coincidence to me.


_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb