On Sat, 25 Apr 2009, Luca Olivetti wrote: > > The above observations are so far, just observations, and I > > don't expect anyone to be able to `fix' anything > > They're nevertheless interesting, since I'm in a similar position: my vdr > machine is using (almost flawlessly) a Skystar 2 (though I don't believe in > this new fangled disecq thing and I use an old fashioned actuator to move my > dish) and it's running a 2.6.17 kernel. Rule number one -- never upgrade a working system ;-) Actually, it seems to be a tradeoff -- some things get fixed, or start working, work better, and a roughly equal number of things break. Make sure you can trivially revert to your known working system, or else bite the bullet, spend time figuring out what's broken, patch, hack, patch again, before giving up and reverting your system... If you don't use DiSEqC to switch between different LNBs, you may well not have a problem. My observations have been that I'd had little to no difficulty with services at position 1/4, which would be tuned by a device not supporting, or not set up to use DiSEqC switching. > I'll probably have to update one day (especially if I want to keep up with the > "latest and greatest" vdr), but I'm not really in a hurry, even less so seeing > your problems. Rather than immediately replace this card with a DVB-S2-able device that tunes better the frequency extremes, I decided to pull it out and experiment a bit more, in a different box. My observations: ============ Here's some more info, in case it would be of interest... I'd suffered interrupt and other problems with the test server I'm building, having tried the SkyStar2 2.6D card in it without major success -- apart from most transponders on position 1/4. Generally I'd have about a 1 in 10 to maybe 1 out of 5 chance of success when tuning the BBC radios on position 3/4 -- usually it would appear to lock to the ZDF transponder at position 3/4. Attempts to tune a particular transponder at 2/4 and at 4/4 would fail around 100% of the time. Usually my first attempt after a reboot would tune successfully. While operating, the machine somehow got in a state where the USB ports were no longer working completely right. Interestingly at this time, I'd be able to tune the SkyStar and get about a 50% success rate or better when tuning 2/4 and 3/4. Also, one higher-frequency transponder at 1/4 which would result in a TS with errors (and thus errors in the radio stream audio) then tuned cleanly. So I decided to strip as much out of the machine as possible and play a nice round of musical PCI-slots, in case there might be a magical slot where it would work, or where I would not be sharing the IRQ with anything. Unfortunately, none of the four freed slots worked with the SkyStar perfectly. Three of them were shown by /proc/interrupts as sharing an IRQ; the one which did not, was shown to be sharing the IRQ, with `lspci'. Now, I did confirm one thing -- after each reboot, all my first tuning attempts, regardless of position 4/4, 3/4, 2/4, or 1/4, were always successful. This using `dvbstream'. Any following attempts to repeat that tuning, or tune elsewhere, failed or had a negligible success rate, except for position 1/4. This appears to be the case both for cold boots from poweroff and for warm reboots. It doesn't appear to affect the case of the weak radio stream, which may be near the card's weakened sensitivity limit (it's become this way over time, it seems), that could vary in strength during the day. An attempt to `scan' the transponders at 3/4 got far more of the 1/4 transponders, and failed more than not with active 3/4 frequencies. If there's any pattern, it could be that the successful transponders were largely vertical, with horizontal polarised transponders rarely tuning. The same cable feeding a couple external USB boxen delivered clean signals on all tuning attempts. Probably I do need to bisect my way from 2.6.26-ish back to 2.6.14-ish to determine where things went boom. However, I've observed that a second PCI DVB-T card (BT878- based) has not only failed to deliver a clean signal, but has also resulted in normally-clean signals from USB devices becoming similarly corrupted every minute or so, so that card will also suffer the musical-PCI-slot treatment to see if it's an IRQ problem. And if I motivate myself, I'll see about trying the SkyStar in the two used slots, or trying to give it a truly-free IRQ. By which time I'll probably have become insane trying to keep track of which cards get which IRQs in which slots. Man, sometimes I wish PC hardware weren't so illogical, or that the logic were to be clearer... Preliminary results of juggling BT878-DVB-T card -- if it is sharing its IRQ with either my EHCI card (NEC, IRQ10), or the sound card (CMIPCI, IRQ7) at boot, the machine will lock up solid. Presumably an interrupt storm, or something, as I know little about such. Otherwise it appears to work fine, though with a few cards still missing. Experimentation continues. The corrupted streams I observed earlier haven't repeated. Unfortunately, after quite some time, one USB device goes wacky, some others continue to work, but no USB plug events are recognised, `lsusb' hangs, and looks like time to reboot. Grrr. barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
