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
Improvement Suggestions
Tuner Factory - Tuner Plugins
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="randell" data-source="post: 193054" data-attributes="member: 47127"><p><strong>Started on:</strong> 2007-10-16</p><p><strong>last update:</strong> 2007-10-16</p><p></p><p><strong>Summary:</strong></p><p>Revamp code and database to provide a way to allow users to easily write a .dll that can be used to control unsupported hardware. (R5000-HD, etc)</p><p></p><p><strong>Description:</strong></p><p>I was looking at the code, trying to trace everything out in hopes of adding support for the R5000-HD hardware modifications done by Nextcomwireless. I found it a bit daunting.</p><p></p><p>I was thinking, why not revise the code and implement a Factory type model for tuners. You would have all the implementation specific code for a tuner type (ATSC, DVB, IPTV, QAM, Custom, etc) inside its respective dll (aka MediaPortal.Tuners.ATSC.dll, MediaPortal.Tuners.DVB.dll, etc). In the database, just specify the name of the class and .dll for each tuner and load it at runtime.</p><p></p><p>Adding support for some future device could be as simple as inheriting from a base class, overriding a couple methods, adding the tuner to the database and which dll should be used.</p><p></p><p>This could be extended out to include channel changing support. The tuner entry in the database would have a field that named the .dll for the tuner and the .dll for channel changing.</p><p></p><p>This would add a great deal of flexibility to the TV configuration and it would easily allow other people to create tuner "plugins".</p><p></p><p></p><p>Cheers!</p><p></p><p>Randell</p></blockquote><p></p>
[QUOTE="randell, post: 193054, member: 47127"] [b]Started on:[/b] 2007-10-16 [b]last update:[/b] 2007-10-16 [b]Summary:[/b] Revamp code and database to provide a way to allow users to easily write a .dll that can be used to control unsupported hardware. (R5000-HD, etc) [b]Description:[/b] I was looking at the code, trying to trace everything out in hopes of adding support for the R5000-HD hardware modifications done by Nextcomwireless. I found it a bit daunting. I was thinking, why not revise the code and implement a Factory type model for tuners. You would have all the implementation specific code for a tuner type (ATSC, DVB, IPTV, QAM, Custom, etc) inside its respective dll (aka MediaPortal.Tuners.ATSC.dll, MediaPortal.Tuners.DVB.dll, etc). In the database, just specify the name of the class and .dll for each tuner and load it at runtime. Adding support for some future device could be as simple as inheriting from a base class, overriding a couple methods, adding the tuner to the database and which dll should be used. This could be extended out to include channel changing support. The tuner entry in the database would have a field that named the .dll for the tuner and the .dll for channel changing. This would add a great deal of flexibility to the TV configuration and it would easily allow other people to create tuner "plugins". Cheers! Randell [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
Improvement Suggestions
Tuner Factory - Tuner Plugins
Contact us
RSS
Top
Bottom