home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
Submit: code patches (MediaPortal/TV-Server/etc.)
TV Server hardware-specific code refactoring
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="mm1352000" data-source="post: 684585" data-attributes="member: 82144"><p>Hi gibman</p><p></p><p>Thank you for the comment!</p><p>There is currently a very bad (in my opinion) hack in the code to try and support DiSEqC switching on Hauppauge cards. What it does is to:</p><p></p><p>1. Try send DiSEqC command normally (before graph is running).</p><p>2. Run graph.</p><p>If DiSEqC command failed:</p><p>3. Don't check for lock.</p><p>4. Stop the graph.</p><p>5. Tune again.</p><p></p><p>I am aware through experience with my card that some cards require the DiSEqC commands to be sent <strong>*after*</strong> the graph is running. This is exactly why I even started making this patch - to support DiSEqC switching on my card which was not working unless the command was sent after the graph was started. MediaPortal currently sends the command <strong>*before*</strong> the graph is running and most cards seem to work okay. In fact there are probably some cards that require the commands to be sent at that time. Maybe some of the Hauppauge cards are like mine?</p><p></p><p>We could try to take out the hack and do the following (for all cards - more robust):</p><p>1. Try send DiSEqC command normally (before graph is running).</p><p>2. Run graph.</p><p>3. Before checking for lock, resend the DiSEqC command if the first command failed.</p><p></p><p>Very easy to implement for switch control from within the ConditionalAccess class after my refactoring <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin :D" loading="lazy" data-shortname=":D" /></p><p>Not so easy to implement for motor control. Do you have a dish motor?</p></blockquote><p></p>
[QUOTE="mm1352000, post: 684585, member: 82144"] Hi gibman Thank you for the comment! There is currently a very bad (in my opinion) hack in the code to try and support DiSEqC switching on Hauppauge cards. What it does is to: 1. Try send DiSEqC command normally (before graph is running). 2. Run graph. If DiSEqC command failed: 3. Don't check for lock. 4. Stop the graph. 5. Tune again. I am aware through experience with my card that some cards require the DiSEqC commands to be sent [B]*after*[/B] the graph is running. This is exactly why I even started making this patch - to support DiSEqC switching on my card which was not working unless the command was sent after the graph was started. MediaPortal currently sends the command [B]*before*[/B] the graph is running and most cards seem to work okay. In fact there are probably some cards that require the commands to be sent at that time. Maybe some of the Hauppauge cards are like mine? We could try to take out the hack and do the following (for all cards - more robust): 1. Try send DiSEqC command normally (before graph is running). 2. Run graph. 3. Before checking for lock, resend the DiSEqC command if the first command failed. Very easy to implement for switch control from within the ConditionalAccess class after my refactoring :D Not so easy to implement for motor control. Do you have a dish motor? [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
Submit: code patches (MediaPortal/TV-Server/etc.)
TV Server hardware-specific code refactoring
Contact us
RSS
Top
Bottom