Reply to thread

Message

I fully agree. The problem is how to detect as early as possible that the DiSEqC command needs to be resent. In your specific case (Hauppauge), at each step in the proposed algorithm:

1. Send DiSEqC command: the provider returns success.
2. Run graph: still okay.
3. Resend: assumed not required because the provider returned success.

It is impossible to detect that the command failed to be sent or the switch didn't change until you find that you can't lock. Perhaps we need to be more proactive? A better algorithm (???):

1. Try send DiSEqC command normally (before graph is running).
2. Run graph.
3. Before checking for lock, resend the DiSEqC command if the provider (for example, Hauppauge) often fails to send the command properly. This can be customised to each provider.
4. Resend the DiSEqC command every 2 seconds during LockedInOnSignal().

The only concern I would have about this 2nd algorithm is that some hardware/drivers might not handle this. I don't know of any cards like that but there are bound to be some out there.

Also, resending a DiSEqC command can take quite a lot of time. According to the standard you have to wait 100ms after sending each command. That is on top of the time it takes for the driver to send the command. It adds up pretty quickly. Also, what happens when someone (probably me ) comes along and extends DiSEqC support to cascaded switches/motors?

The providers each have an OnRunGraph() callback so it is easy to resend the DiSEqC command after the graph has started. Anything that needs to be done while checking for lock (LockedInOnSignal()) would have to be done for all providers in TvCardDvbBase/TvCardDVBS.

It should definitely be possible to add an optional interface to hardware providers that allows them to specify their lock detection behaviour (perhaps as an extension to the custom tuning interface?). For example, for some cards, signal quality > 0 might indicate that the card is locked. If you add such an interface then it would be possible to define custom DiSEqC behaviour for the LockedInOnSignal() function. I'd much rather leave that until after the main refactoring is complete and confirmed as stable. There is already quite a high risk involved in this patch...

Okay - thanks for mentioning that.

<blockquote data-quote="mm1352000" data-source="post: 684705" data-attributes="member: 82144">I fully agree. The problem is how to detect as early as possible that the DiSEqC command needs to be resent. In your specific case (Hauppauge), at each step in the proposed algorithm:1. Send DiSEqC command: the provider returns success.2. Run graph: still okay.3. Resend: assumed not required because the provider returned success.It is impossible to detect that the command failed to be sent or the switch didn't change until you find that you can't lock. Perhaps we need to be more proactive? A better algorithm (???):1. Try send DiSEqC command normally (before graph is running).2. Run graph.3. Before checking for lock, resend the DiSEqC command if the provider (for example, Hauppauge) often fails to send the command properly. This can be customised to each provider.4. Resend the DiSEqC command every 2 seconds during LockedInOnSignal().The only concern I would have about this 2nd algorithm is that some hardware/drivers might not handle this. I don't know of any cards like that but there are bound to be some out there.Also, resending a DiSEqC command can take quite a lot of time. According to the standard you have to wait 100ms after sending each command. That is on top of the time it takes for the driver to send the command. It adds up pretty quickly. Also, what happens when someone (probably me <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink&nbsp; &nbsp; ;)" loading="lazy" data-shortname=";)" /> ) comes along and extends DiSEqC support to cascaded switches/motors?The providers each have an OnRunGraph() callback so it is easy to resend the DiSEqC command after the graph has started. Anything that needs to be done while checking for lock (LockedInOnSignal()) would have to be done for all providers in TvCardDvbBase/TvCardDVBS.It should definitely be possible to add an optional interface to hardware providers that allows them to specify their lock detection behaviour (perhaps as an extension to the custom tuning interface?). For example, for some cards, signal quality &gt; 0 might indicate that the card is locked. If you add such an interface then it would be possible to define custom DiSEqC behaviour for the LockedInOnSignal() function. I'd much rather leave that until after the main refactoring is complete and confirmed as stable. There is already quite a high risk involved in this patch...Okay - thanks for mentioning that.</blockquote>

[QUOTE="mm1352000, post: 684705, member: 82144"] I fully agree. The problem is how to detect as early as possible that the DiSEqC command needs to be resent. In your specific case (Hauppauge), at each step in the proposed algorithm: 1. Send DiSEqC command: the provider returns success. 2. Run graph: still okay. 3. Resend: assumed not required because the provider returned success. It is impossible to detect that the command failed to be sent or the switch didn't change until you find that you can't lock. Perhaps we need to be more proactive? A better algorithm (???): 1. Try send DiSEqC command normally (before graph is running). 2. Run graph. 3. Before checking for lock, resend the DiSEqC command if the provider (for example, Hauppauge) often fails to send the command properly. This can be customised to each provider. 4. Resend the DiSEqC command every 2 seconds during LockedInOnSignal(). The only concern I would have about this 2nd algorithm is that some hardware/drivers might not handle this. I don't know of any cards like that but there are bound to be some out there. Also, resending a DiSEqC command can take quite a lot of time. According to the standard you have to wait 100ms after sending each command. That is on top of the time it takes for the driver to send the command. It adds up pretty quickly. Also, what happens when someone (probably me ;) ) comes along and extends DiSEqC support to cascaded switches/motors? The providers each have an OnRunGraph() callback so it is easy to resend the DiSEqC command after the graph has started. Anything that needs to be done while checking for lock (LockedInOnSignal()) would have to be done for all providers in TvCardDvbBase/TvCardDVBS. It should definitely be possible to add an optional interface to hardware providers that allows them to specify their lock detection behaviour (perhaps as an extension to the custom tuning interface?). For example, for some cards, signal quality > 0 might indicate that the card is locked. If you add such an interface then it would be possible to define custom DiSEqC behaviour for the LockedInOnSignal() function. I'd much rather leave that until after the main refactoring is complete and confirmed as stable. There is already quite a high risk involved in this patch... Okay - thanks for mentioning that. [/QUOTE]