Reply to thread

Great. :)

Strange that the motor would get confused in that way though. I would've thought that the motor would keep track of its position in terms of degrees/steps in rotation and/or elevation relative to a reference position, and that each stored position would just be a count of steps away from that same reference position. Therefore the motor would be able to go to any stored position from any arbitrary position with great precision. Seems I'm wrong.



Well, the SkyStar HD2 puzzles me. We've previously discussed the driver's "relock monitor" variables. I don't understand why those variables don't seem to have any effect for you.



From TV Server's perspective it's very simple. Tuners provide some information about the connected signal state:

  • is the tuner locked onto signal (yes/no)
  • is signal detected [even if not locked] (yes/no)
  • strength
  • quality

The method of locking on signal is simply to check the first detail ("is the tuner locked...") every 20 ms until the value changes to "yes". There's also a time limit which is the tune time-out setting that we've previously discussed.


Code here:

https://github.com/MediaPortal/MediaPortal-1/blob/master/TvEngine3/TVLibrary/TVLibrary/Implementations/DVB/Graphs/TvCardDvbBase.cs#L793-L835


I can't tell you anything about the internal driver or hardware logic that sets the values of the above details.



We pass on all the details that you see in the user interface: frequency, polarisation, symbol rate etc. This should be enough to uniquely identify a transponder unless the transponder details on 2 satellites are identical.


I don't know a lot about the internal workings of tuner drivers and their hardware, but I do know that some tuners auto-detect some parameters instead of using the details that we provide. We can't force the tuner to use specific details.



From the TV Server side: it's always the same method. There are no relevant differences from tuner to tuner.

From the tuner side (setting the value of signal details, and the tuning algorithm in general): I have no comment because tuner drivers are closed source, which means I can't check and compare their code.



With the greatest respect, I think this view is too simple. The reality is more complex. For example, I've tried to explain that some tuners will try to lock on signal repeatedly/continuously. For those tuners, high time out should result in success.



I've already answered this question as best as I can in this and other replies. Sorry, I have nothing to add.



The wiki's "DiSEqC - motor" column is not a claim that certain tuners are working with DiSEqC motors. Rather, it's an indication that TV Server has the capacity to send DiSEqC motor control commands for those tuners. The "working" part is your interpretation. In reality, we don't have the access or ability to individually test all those tuners. In fact, I don't think any of the active team members currently have a motor.



Yes, that's true. Tuner behaviour varies, and we don't have the ability to test all tuners.



Yes, I agree... but this is not in our control.



I don't think I've said that adding a delay would solve the problem. You asked if it would be possible to add delay, and I answered that code modifications would be required. That's all. Please keep in mind that I've never owned a motor myself. Therefore even if I said something like that, I should never be so confident that I would say that I'm sure.



We've talked about this before:

https://forum.team-mediaportal.com/threads/tired-of-skystar-hd2-need-a-new-card.134744/page-2#post-1190214



No. TV Server is smart enough to know that it doesn't need to resend the "goto X" command when the motor/dish is already be in the right position. If you added the delay where the commands are sent, the delay would only be applied when the motor has to move.


Top Bottom