Daniel Golle wrote: >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 Your success with Das Erste prompted me to temporarily re-align my dish (Sky minidish) to point to 19.2E to see if I could duplicate your results. The good news is that I get a perfect recording from Das Erste. I recorded about 15 minutes of data, then ran it through TSReader Lite to check for errors. There were absolutely no errors of any kind indicated ! I double checked this by viewing the recording in DVBViewer Pro under XP. This is interesting because the signal strength from Das Erste (as displayed by DVBViewer Pro under Windows XP) is much lower than I'm getting from Astra 28.2E (I'm based in the London area). Das Erste displays a signal strength reading of 41%, whereas the BBC channels at 28.2E (on which I'me seeing high error rates) show signal strengths of around 65%. I think this probably rules out signal quality as the issue, and suggests the problem is somehow related to the channel parameters. In case it's of interest for comparison, typical values returned by szap when tuning into Das Erste in my setup are: signal 0102 snr 004e ber 00000000 unc fffffffe regards, John > > 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
