- September 1, 2008
- 21,578
- 8,227
- Home Country
-
New Zealand
Hi team
I would like to ask for your advice. I've been helping a user who has been having trouble with his TV setup. He has a single DVB-S TV card which he is using for watching satellite channels. His dish setup includes two LNBs (1 linear, 1 circular) connected via a DiSEqC switch as well as a DiSEqC motor to move the dish:
[card] --> [motor] --> [switch]
He reports that he's been having trouble getting his tuner to lock when the motor has to move. If the motor doesn't have to move then the tuner usually doesn't have any problem getting lock....
Let's "cut to the chase". I have worked with the user to try to find out what is causing his problems. My first suspicion was that his tune timeout simply wasn't long enough to allow the motor to get into place, however we proved this wrong. It turns out that the switch port seems to be reset when the motor moves. Attempts to resend the switch command before the motor has stopped moving have proved fruitless. The only way we have been able to solve (for ~90% of tunes) his problem is by detecting motor movement, giving the motor a chance to move into position with a fixed wait time, and finally resending the DiSEqC switch command. The idea is that the switch command must be sent after the motor has stopped moving.
Now that we have found a way to solve the problem the user would obviously like the TV Server code to be patched. I would like to know what the team thinks about my solution. In particular, the fixed wait time for motor movement.
1. Would a patch like this be accepted, or would more sophistication be required?
2. Can you think of any alternative approaches for solving this problem?
In the course of our troubleshooting, one other issue has been discussed that I would also like feedback about. When TV Server tunes a channel, it does not send a completely new tuning request unless the channel is on a different transponder from the previous channel. This is done to save time in the tuning process. I was wondering if it would be a good idea to also send a new tuning request after a failed tuning process. In most cases this would have no effect on current behaviour, however it has the potential to improve the general robustness of the TV Server tuning process. This improvement could be particularly important for users with satellite tuners in situations like the one I described above involving DiSEqC. Implementation would not be difficult. I just wanted to know if the team might accept a patch like this...
Any thoughts are welcome
I would like to ask for your advice. I've been helping a user who has been having trouble with his TV setup. He has a single DVB-S TV card which he is using for watching satellite channels. His dish setup includes two LNBs (1 linear, 1 circular) connected via a DiSEqC switch as well as a DiSEqC motor to move the dish:
[card] --> [motor] --> [switch]
He reports that he's been having trouble getting his tuner to lock when the motor has to move. If the motor doesn't have to move then the tuner usually doesn't have any problem getting lock....
Let's "cut to the chase". I have worked with the user to try to find out what is causing his problems. My first suspicion was that his tune timeout simply wasn't long enough to allow the motor to get into place, however we proved this wrong. It turns out that the switch port seems to be reset when the motor moves. Attempts to resend the switch command before the motor has stopped moving have proved fruitless. The only way we have been able to solve (for ~90% of tunes) his problem is by detecting motor movement, giving the motor a chance to move into position with a fixed wait time, and finally resending the DiSEqC switch command. The idea is that the switch command must be sent after the motor has stopped moving.
Now that we have found a way to solve the problem the user would obviously like the TV Server code to be patched. I would like to know what the team thinks about my solution. In particular, the fixed wait time for motor movement.
1. Would a patch like this be accepted, or would more sophistication be required?
2. Can you think of any alternative approaches for solving this problem?
In the course of our troubleshooting, one other issue has been discussed that I would also like feedback about. When TV Server tunes a channel, it does not send a completely new tuning request unless the channel is on a different transponder from the previous channel. This is done to save time in the tuning process. I was wondering if it would be a good idea to also send a new tuning request after a failed tuning process. In most cases this would have no effect on current behaviour, however it has the potential to improve the general robustness of the TV Server tuning process. This improvement could be particularly important for users with satellite tuners in situations like the one I described above involving DiSEqC. Implementation would not be difficult. I just wanted to know if the team might accept a patch like this...
Any thoughts are welcome