Andrew de Quincey wrote: > On Tuesday 07 June 2005 14:30, Manu Abraham wrote: >>Andrew de Quincey wrote: >>>Hi, I've been having (another :) problem with the DVB drivers. Basically, >>>at certain sites and with certain channels, cards seem to lose the lock >>>after a while.... the average is about 10 hours, so I think its unlikely >>>to be that multiswitch incompatability with certain TT DVB-S cards. >>> >>>This doesn't affect all sites or all channels or all cards - the same >>>channels at another site can be rock solid with no issues for months. >>> >>>The driver is supposed to launch a zigzag scan if it loses lock. However >>>this doesn't ever seem to regain the lock with this problem. Simply >>>restarting our streaming software (without a reboot) however, _does_ >>>regain the lock (only to lose it again after a while). >>> >>>Snooping with dvbsnoop shows that the signal has been lost, but it does >>>appear to be zigzagging to try and require it, but failing (I see the >>>lock status varying between SIGNAL and SIGNAL|CARRIER|VITERBI, but never >>>above that). >>> >>>The difference between locking initially and losing a lock after a while >>>seems to be the call to dvb_frontend_init(). I'm going to try adding a >>>call to this in to the dvb_frontend_thread() loop if it loses the lock >>>after a while. >>> >>>I'm wondering if anyone else sees this? It seems to plague us constantly. >>I had that problem sometime back on the Twinhan cards, that time i >>thought it was because the tuners getting too hot.. As a temporary >>arrangement i tried a huge blower on the cards. This kept the 3 tuners >>cool. >> >>This never had any effect, whether the tuner was hot/cold. > > Yeah - I can't test the temperature directly as I'm over 400 miles away from > that machine - but I did read the HDD temperature with SMART, and it was 26C. > I'm informed the site is air conditioned, and there is loads of open space. I > really don't think this is temperature related either. > To test this fact, it is quite some time now, i had a separate airconditioner blowing using an axial fan on to the tuners (well the entire setup itself was in an air conditioned room). I can almost confirm that my problems were not temperature related.. >>The periods used to vary, don't know what exactly caused them to vary >>either. The variations used to happen something like what you said 10 ~ >>12 hours or sometime it was 48 hours. But 72 hours seemed the maximum >>that it would go many times. > > Interesting - thats exactly it.. so its across completely different card > architectures!? (I assume you're still talking about the twinhan cards here) > Exactly.. I am talking about different firmware based ones too FTA and CI based.. different generations too.. Regarding that issue i' am almost tied up in knots... :-( I had a revision AV7110 1.3 card, which was blown when i received itself from Galaxis as a sample given to one of our guys. Even an lspci did not show anything at all, on some motherboards inserting the card into the PCI slot itself would result in a hung BIOS. After that i decided that, i would never again go with one of those FF cards. (eventhough they are the same TT-PCI cards remarketed) That was the time i first started up with DVB, and in this region could not see any other hardware other than Twinhan and got my first card as well as suggested for many others as well as my company too. But the biggest problem their was drivers, whether be it Windows or Linux. well you know the rest.. >>Somebody at one of the universities in prague who was streaming in the >>unversity campus also had the same problems.... > > I seem to remember hearing from them as well, but we didn't manage to find a > resolution. > Those were with the TT-PCI, Same here too.. I had been going over the entire frontend/demux code over and over agian, without much of success. The first one that i met with was CRC32 problems, later on discontinuities, but even with CRC32 problems gone, and discontinuity problems (hopefully) fixed, but the same problems remained.. >>>I suppose these cards are really meant as consumer grade ones for zapping >>>channels, and not really designed for 24x7 reception on a single channel. >>I don't think it was the hardware, as the drivers from the manufacturer >>worked fine, eventhough they had their own share of the problems and >>bugs.. :-( > > I wonder whether those drivers lose the lock and retune quickly, or if they > don't lose the lock at all? > There were many bugs in the Twinhan driver what we had on Linux( many more to go), but (even logically) nothing much to loose a lock as it is directly from the MCU. The hardware does retuning if necessary, but that too did not seem to be working. At one point i was even looking at set_frontend, get_frontends too.. Found quite some bugs specific to Twinhan, but not anything that may cause a loss of lock. (There are some flags what i can see from the tuner what might be the cause, i will dig a bit deep into that) But the problem is that over 2 days or 3 days you have a lot of events, making it very difficult to know what exactly happened and at what point of time.. Right now, really chasing on that one only. Too many bugs/problems and a big TODO list is always irritating and somebody always calling you up in the amidst of something can be irritating to the core. > I'm hoping we can at least retune so its not such a big hassle - obviously > some data is going to be lost, but its better than nothing (certainly better > than it going down completely + irate clients etc). > I was looking at the schematics too, to check what the **** was going on.. I will try to see what's going on.. Manu
