TS discontinuity with TT S-2300

TS discontinuity with TT S-2300

[Jaroslav Klaus]

Hi,

I'm loosing TS packets in my dual CAM premium TT S-2300 card (av7110+saa7146).

Is it possible the problem is in firmware? Here is the description:

04:00.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
        Subsystem: Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.3
        Flags: bus master, medium devsel, latency 32, IRQ 20
        Memory at fddff000 (32-bit, non-prefetchable) [size=512]
        Kernel driver in use: dvb

dvb 0000:04:00.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
IRQ 20/: IRQF_DISABLED is not guaranteed on shared IRQs
saa7146: found saa7146 @ mem ffffc90005248000 (revision 1, irq 20) (0x13c2,0x000e).
dvb 0000:04:00.0: firmware: requesting dvb-ttpci-01.fw
DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-S rev2.3)
adapter has MAC addr = 00:d0:5c:04:2e:ea
dvb 0000:04:00.0: firmware: requesting av7110/bootcode.bin
dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app 80f12623
dvb-ttpci: firmware @ card 0 supports CI link layer interface

I've tried also:
 dvb-ttpci: info @ card 1: firm f0240009, rtsl b0250018, vid 71010068, app 8000261a
 dvb-ttpci: info @ card 1: firm f0240009, rtsl b0250018, vid 71010068, app 80002622
without any impact.

SR of my signal is 27500, 2x official CAMs (videoguard).

I use dvblast to select 4 TV channels (~ 16 PIDs) from multiplex, descramble them and stream them to network. Dvblast reports TS discontinuity across all video PIDs only (no audio) usually every 1-3 minutes ~80 packets. But sometimes it goes well for tens of minutes (up to 1-2hours). Everything seems to be ok with 3 TV channels.

Do you thing it is av7110 issue? Do you know any relevant limits of av7110? What should I test/try more? Thanks

Regards,
Jaroslav

Re: TS discontinuity with TT S-2300

[Oliver Endriss]

Hi,

On Sunday 27 June 2010 01:05:57 Jaroslav Klaus wrote:
> Hi,
> 
> I'm loosing TS packets in my dual CAM premium TT S-2300 card (av7110+saa7146).
> 
> Is it possible the problem is in firmware? Here is the description:
> 
> 04:00.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
>         Subsystem: Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.3
>         Flags: bus master, medium devsel, latency 32, IRQ 20
>         Memory at fddff000 (32-bit, non-prefetchable) [size=512]
>         Kernel driver in use: dvb
> 
> dvb 0000:04:00.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> IRQ 20/: IRQF_DISABLED is not guaranteed on shared IRQs
> saa7146: found saa7146 @ mem ffffc90005248000 (revision 1, irq 20) (0x13c2,0x000e).
> dvb 0000:04:00.0: firmware: requesting dvb-ttpci-01.fw
> DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-S rev2.3)
> adapter has MAC addr = 00:d0:5c:04:2e:ea
> dvb 0000:04:00.0: firmware: requesting av7110/bootcode.bin
> dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app 80f12623
> dvb-ttpci: firmware @ card 0 supports CI link layer interface
> 
> I've tried also:
>  dvb-ttpci: info @ card 1: firm f0240009, rtsl b0250018, vid 71010068, app 8000261a
>  dvb-ttpci: info @ card 1: firm f0240009, rtsl b0250018, vid 71010068, app 80002622
> without any impact.
> 
> SR of my signal is 27500, 2x official CAMs (videoguard).
> 
> I use dvblast to select 4 TV channels (~ 16 PIDs) from multiplex,
> descramble them and stream them to network. Dvblast reports TS
> discontinuity across all video PIDs only (no audio) usually every
> 1-3 minutes ~80 packets. But sometimes it goes well for tens of
> minutes (up to 1-2hours). Everything seems to be ok with 3 TV channels.
> 
> Do you thing it is av7110 issue? Do you know any relevant limits of
> av7110? What should I test/try more? Thanks 

The full-featured cards are not able to deliver the full bandwidth of a
transponder. It is a limitaion of the board design, not a firmware or
driver issue.

You can fix this by applying the 'full-ts' hardware modification.
For more information follow the link in my signature.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: TS discontinuity with TT S-2300

[Jaroslav Klaus]

On 27.6.2010, at 14:37, Oliver Endriss wrote:

> Hi,
> 
> On Sunday 27 June 2010 01:05:57 Jaroslav Klaus wrote:
>> Hi,
>> 
>> I'm loosing TS packets in my dual CAM premium TT S-2300 card (av7110+saa7146).
>> Do you thing it is av7110 issue? Do you know any relevant limits of
>> av7110? What should I test/try more? Thanks 
> 
> The full-featured cards are not able to deliver the full bandwidth of a
> transponder. It is a limitaion of the board design, not a firmware or
> driver issue.

I thought full bandwidth is impossible to process but I thought 4 TV channel should be ok. It's too much obviously. Especially when peaks of all TV channels meet in the same time.

> You can fix this by applying the 'full-ts' hardware modification.
> For more information follow the link in my signature.

Great link. This really make sense. Thanks

Jaroslav

Re: TS discontinuity with TT S-2300

[Marko Ristola]

27.06.2010 15:37, Oliver Endriss wrote:
> Hi,
>
> On Sunday 27 June 2010 01:05:57 Jaroslav Klaus wrote:
>   
>> Hi,
>>
>> I'm loosing TS packets in my dual CAM premium TT S-2300 card (av7110+saa7146).
>>
>> I use dvblast to select 4 TV channels (~ 16 PIDs) from multiplex,
>> descramble them and stream them to network. Dvblast reports TS
>> discontinuity across all video PIDs only (no audio) usually every
>> 1-3 minutes ~80 packets. But sometimes it goes well for tens of
>> minutes (up to 1-2hours). Everything seems to be ok with 3 TV channels.
>>
>>     
> The full-featured cards are not able to deliver the full bandwidth of a
> transponder. It is a limitaion of the board design, not a firmware or
> driver issue.
>   
I noticed that saa7146 uses dvb_dmx_swfilter_packets().

I planned using of that function too for
Mantis 16K buffer delivery, but I found out that
hardware delivers sometimes additional bytes (corrupted partially lost
packets?)
between the full sized 204 byte packets:

Jun 26 16:20:37 koivu kernel: demux: skipped 49 bytes at position 3379
Jun 26 16:20:37 koivu kernel: demux: skipped 18 bytes at position 9868
Jun 26 16:20:37 koivu kernel: demux: skipped 30 bytes at position 10090
Jun 26 16:20:38 koivu kernel: demux: skipped 14 bytes at position 7208
Jun 26 16:20:38 koivu kernel: demux: skipped 114 bytes at position 7426

So dvb_dmx_swfilter(_204)() is needed to skip
these unwanted bytes. With simple usage of
dvb_dmx_swfilter_packets() the rest of the buffer
would have been lost. I wrote a faster version of these
functions, also for 188 sized packets today:
"Re: [PATCH] Avoid unnecessary data copying inside
dvb_dmx_swfilter_204() function"

CU
Marko

Re: TS discontinuity with TT S-2300

[Oliver Endriss]

On Sunday 27 June 2010 17:56:06 Marko Ristola wrote:
> 27.06.2010 15:37, Oliver Endriss wrote:
> > Hi,
> >
> > On Sunday 27 June 2010 01:05:57 Jaroslav Klaus wrote:
> >   
> >> Hi,
> >>
> >> I'm loosing TS packets in my dual CAM premium TT S-2300 card (av7110+saa7146).
> >>
> >> I use dvblast to select 4 TV channels (~ 16 PIDs) from multiplex,
> >> descramble them and stream them to network. Dvblast reports TS
> >> discontinuity across all video PIDs only (no audio) usually every
> >> 1-3 minutes ~80 packets. But sometimes it goes well for tens of
> >> minutes (up to 1-2hours). Everything seems to be ok with 3 TV channels.
> >>
> >>     
> > The full-featured cards are not able to deliver the full bandwidth of a
> > transponder. It is a limitaion of the board design, not a firmware or
> > driver issue.
> >   
> I noticed that saa7146 uses dvb_dmx_swfilter_packets().

Yes.

> I planned using of that function too for
> Mantis 16K buffer delivery, but I found out that
> hardware delivers sometimes additional bytes (corrupted partially lost
> packets?)
> between the full sized 204 byte packets:
> 
> Jun 26 16:20:37 koivu kernel: demux: skipped 49 bytes at position 3379
> Jun 26 16:20:37 koivu kernel: demux: skipped 18 bytes at position 9868
> Jun 26 16:20:37 koivu kernel: demux: skipped 30 bytes at position 10090
> Jun 26 16:20:38 koivu kernel: demux: skipped 14 bytes at position 7208
> Jun 26 16:20:38 koivu kernel: demux: skipped 114 bytes at position 7426

Are you sure that Mantis driver delivers garbage, not partial packets?
Please note that the dvb_dmx_swfilter[_204]() routines must accept
partial packets, i.e. the rest of the packet will be dellivered with the
next call.

> So dvb_dmx_swfilter(_204)() is needed to skip
> these unwanted bytes. With simple usage of
> dvb_dmx_swfilter_packets() the rest of the buffer
> would have been lost. I wrote a faster version of these
> functions, also for 188 sized packets today:
> "Re: [PATCH] Avoid unnecessary data copying inside
> dvb_dmx_swfilter_204() function"

dvb_dmx_swfilter_packets() expects complete TS packets from the driver.
The saa7146 does so. It does not deliver garbage data. (Otherwise this
would have been noticed a long time ago. The ttpci drivers are the
oldest DVB drivers and are very well tested.)

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: TS discontinuity with TT S-2300

[Marko Ristola]

27.06.2010 21:25, Oliver Endriss wrote:
> Are you sure that Mantis driver delivers garbage, not partial packets?
> Please note that the dvb_dmx_swfilter[_204]() routines must accept
> partial packets, i.e. the rest of the packet will be dellivered with the
> next call.
>   
Yes, I'm sure that the garbage comes from the PCI device itself:
garbage should be found at less than 204 byte position otherwise.

My latest mailed patch that I use makes sure 0x47 is found at
demux->tsbufp[0],
if there is at least one spared byte. Otherwise the resulting 188 sized
packet would be discarded eventually.

It would be good if Mauro would accept my patch for dvb_dmx_swfilter(_204)
functions some day. It increases robustness with garbage input, and
performance by avoiding unnecessary packet copying.

> dvb_dmx_swfilter_packets() expects complete TS packets from the driver.
> The saa7146 does so. It does not deliver garbage data. (Otherwise this
> would have been noticed a long time ago. The ttpci drivers are the
> oldest DVB drivers and are very well tested.)
>   
I'm very sorry I even questioned ttpci's and the hardware's robustness.

I'm delighted to hear that ttpci is so well implemented and tested and
so long :)
I was very impressed in the quality of the code with
dvb_dmx_swfilter_packets():
so simple and efficient.

Unfortunately I have had lots of problems with Mantis.
But because of that, I've learned DVB driver programming.

H.264 works now mostly in one TV channel without crashing Xine with
remote vdr.
I had to modify streamdev plugin too for vdr.

CU
Marko