i also noticed glitches on some channels, but not all. Using szap2 (or the patched version of VDR 1.5) on Astra 19.2E Das Erste:11836:hC34M2S0Z0:S19.2E:27500:101:102=deu,103=2ch;106=dd:104:0:28106:1:1101:0 works perfect and didn't show a single error in several hours of recording, while ORF2E:12692:hC56M2S0Z0:S19.2E:22000:170:171=deu:505:0:13014:1:1117:0 rarely gives any complete picture at all - usually vdr-softdevice crashes after some seconds... this pointed me to a possible dependency on the symbol rate, but i didn't investigate it further. as I'm currently waiting for a new LNC to be delivered, i cannot run any meaningful test at this moment (but hopefully next week). regards Daniel On Thu, 2007-12-13 at 13:20 +0100, linux-dvb-request@xxxxxxxxxxx wrote: > Although this device is not yet officially supported, I've been trying > to get it working following success reported by others in an earlier > thread. I've followed the instructions in the DVB wiki entry for this > device, and have succeeded in tuning the device using the patched > version of szap, and recording a transport stream (using > cat /dev/dvb/adapter0/dvr0 > recording.ts). > > However, the transport stream shows up discontinuity errors which > manifest as glitches in the playback. From the stats produced by TS > Reader the rate of loss is typically around 1 packet in 700, though it > varies from run to run. > > I realise the simplest explanation for this would be a poor quality > signal. However, the device performs flawlessly under Windows XP in > exactly the same hardware configuration (same computer, dish, and sat > feed) when tuned to the same channels. This seems to rule out signal > quality as a cause unless the linux driver does not configure the > device's error correction properly. Is there any possibility this > could be the case ? > > I've also tried running the linux configuration on two different > computers - an AMD X2 4600 with Asus M2NPV-VM mobo, and a Via EPIA5000 > system (with a PCI 5-port USB2.0 card). The same problem occurs on > both systems. > > I'm using kernel version 2.6.18-2. I also have two DVB-T USB adapters > which work with the same software configuration with no packet loss. > > The channels I've tried are BBC 1 London and BBC HD. Obviously, the > data rate is much higher on the HD channel. I've cross-checked with > the XP configuration to make sure that the frequencies, polarity, etc. > are correct in the channels.conf file. > > Note that during the BBC HD trial from Crystal Palace I was able to > record this channel from a DVB-T adapter without packet loss even on > the EPIA5000 (533 MHz Via Eden processor). > > I'm unable to determine at what point in the processing chain the > packets are being lost. I temporarily inserted some checks for > continuity errors on a specific pid in the 'dvb_dmxdev_ts_callback' > function in dmxdev.c. This showed packets had already gone missing at > this point in the driver. I don't know my way around the code well > enough to be able to pursue it further. In particular, I can't tell > whether the packets are being discarded somewhere in the driver, or > within the device itself. The only kind of errors which I detect are > continuity errors. Does the device filter out all packets in error or > does it pass them through to the driver with the appropriate error > flags set in the packet header ? > > Has anybody succeeded in getting an error free transport stream from > this device ? If not, are there any ideas about where the problem > might be ? > > Thanks, > John _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
