Reply to thread

Message: <blockquote data-quote="deeptho" data-source="post: 1152221" data-attributes="member: 215446">Your messages point out what the problem is: some kind of timing issue.Are you running the drivers in a virtual machine?However, the solution is not a good one: the original code waits 10ms in case of a temporary error and tries that 10 times. That does notwork for you. Your fix risks waiting 10x 100ms =1 second in the worst case.  Note that this is 1 second per transmitted byte. That could make the driver "soft lock" for several seconds.Also I suspect that the problems may be related to powering up the lnbd and swicth (see below).Then the amount to wait depends on what happened before sending the diseqc command.In any case, waiting should not be done in this low level drivercode but at a higher level (either in dvb_frontend.c) or in user space. This is because in general the needed amount to wait depends not on a specific call (in this case diseqc sending) but also on what happened before (e.g., was the voltage switched from 0 to 18V or was it already 18V for a long time) So only higher level code can estimate the optimalvalue because it involves multiple system calls.So a solution in the driver (like your fix) needs to always make the worst case estimate (e.g., alwayswait 100 ms because the LNB may have been only just powered up, even if this delay is not always needed). As a result all these delays will pile up, resulting in slower channel change.Another issue is that all drivers need to behave in the same way (either all of them sleep for safety,or none should do that; most other drivers don't seem to wait either).So I would not recommend this fix.Here is some more info on things I have noticed myself (and which may be different from your problem):I have noticed in reality is all kinds of weird behaviour with switches and motors during power up. The main thing is that after powering up from 0 voltage you need to wait longer than the specs state.Also, when powering a rotor behind a switch the motor can go into "overload" if you power up from 0 to 18 Volt.So neumodvb first switches to 12 Volt and a moment later to 18 volt.None of this should actually be needed according to the specifications, but this is is based on experiments, including an oscilloscope and even measuring currents. Most programs introduce some delays, but the values are based on the specs and do not take into account weird behaviour.I have also noticed that some tbs usb devices are more sensitive in this respect, probably because theycreate more complex startup behaviour due to usb current limitations. And of cours, the longer the cables, or the poorer the connectors, the more risk of problems.It is quite possible that such problems are only seen with the blindscan drivers, for the following reason:many of the (not modified by me) tbs drivers rarely power down the lnbs. I do not think this is a good idea,and it may be the reason why have seen many of my lnbs fail after a few years of usage by tvheadend: I have noticed that switches and the selected lnbs stay powered on (even in power save mode), which needlessly consumes energy and which could (just a theory of mine) reduce lifetime.Instead my blindscan drivers power down lnbs whenever the driver knows they are not being used. That of course means  powering up at each "device open", and if some devices react poorly to power up problems, it also means more problems. With the regular drivers, you will see these problems only once per boot (the first time you use the device) because the 2nd, 3rd... time the switch is already powered up.I am not sure what is the proper fix in your case. Obviously, you do not want to modify all user programs.One work around may be the "repeat diseqc" option that many user space apps offer. This works because programs wait before repeating, and by that time power up has happened.In any case, this could be something to experiment with, just to see if the problem is related to powering up.You could also insert a 100 or 200ms delay in the tsduck code before sending diseqc. This will shed somelight on the nature of the problem.</blockquote>

Verification