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
Support
Input / Output interfaces
Mini Display
Zalman HD135 VFD (VlSys Mplay)
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="Herr R aus B" data-source="post: 220366" data-attributes="member: 62807"><p>And here are the results from the German jury... Hm... You might not understand that joke, coz it's european... Anyway - I tested like hell and had a big grin in my face. Now it's time to also add some tool tips to the config dialogue containing bad remote bashing words, especially describing your very personal relation to 0x7E occurences <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></p><p>I first tested just repeating on different repeat frequencies using just the UP button. Here is what I watched:</p><ol> <li data-xf-list-type="ol">Default repeat frequency: Not possible to determine whether each repeat scrolls two items or one, but most of the times after releasing the remote button, the menu scrolls one item back</li> <li data-xf-list-type="ol">Repeat frequency 100ms: Obviously still that behaviour of scrolling one item at the first repeat and then consequently two items each following repeat. Partly jumping one item back after releasing the button</li> <li data-xf-list-type="ol">Repeat frequency 200ms: same as above</li> <li data-xf-list-type="ol">Repeat frequency 300ms: behaves OK</li> <li data-xf-list-type="ol">Repeat frequency 400ms: behaves OK</li> <li data-xf-list-type="ol">Repeat frequency 500ms: behaves OK</li> </ol><p>Afterwards I did some excessive UP, DOWN, LEFT, RIGHT, OK all over the menus. Got one frozen screen that got alive after some time again. Don't think that's related to your driver tho...</p><p></p><p>Then I also tested fan control a little bit. Unfortunately fan control seems to be dead - is that deliberately disabled at this time? I tested two scenarios:</p><ol> <li data-xf-list-type="ol">Fan 1 set to manual control at 100%, fan 2 set to automatic control according to the default values, started and immediately stopped MP</li> <li data-xf-list-type="ol">Fan 2 set to manual control at 100%, fan 1 set to automatic control according to the default values, started and immediately stopped MP</li> </ol><p>The result was absolute silence as in nothing happened.</p><p></p><p>My interpretation especially of the remote behaviour would be that you should return to reading single byte bursts (well, bursts...) and maybe you are somehow taking over yourself regarding speed - especially using a repeat frequency below 300ms. Just a guess. As this coding just looking at logs must be a real pain I have in mind that I try to set up a little program here to maybe code a base algorithm for all this reading and writing. I dunno, how the serial port arbitration is done in MP. I would do it using a number of threads:</p><ol> <li data-xf-list-type="ol">thread to read single bytes and put the bytes read in two different queues: One queue for remote codes, one for non remote codes</li> <li data-xf-list-type="ol">thread to arbitrate the remote code queue (including our beloved 0x7E)</li> <li data-xf-list-type="ol">thread to arbitrate the rest of the receivings</li> <li data-xf-list-type="ol">probably additional thread to handle outbound bytes</li> </ol><p>Whether or not the serial port should be secured using a semaphore or whatever synch mechanism I cant decide. I assume it should be able to process in full duplex mode. Furthermore I would read bytewise and then decide for each byte what to do - using kinda grammar tree or whatever one should call it to make decisions and control the associated state machine.</p><p></p><p>I think the biggest problem is that state machine, as you are coding blindly. I remember that I once set up a state machine within a CTI client simulating a telephone with all its function and getting asynch signals from a CTI server. That state machine had about 15 flags controlled by some 25 boolean equations - it was a nightmare <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" /> So coding this all without being able to immediately see the results of your algorithms must be a nightmare, too...</p><p></p><p>If I make it to do some coding here, it surely would be either in Java or more likely in C++ as I don't have any clue about C# that you obviously are using. Maybe Java would be better, as it seems to be rather similar to C# from what I saw. But I dunno whether I'll be able to address the COM port using Java on a XP64 machine... Never tried that. Would that be of any help for you, or would that rather insult your coder's honour? ;-) Hopefully you are not of klingon decent then... <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /></p><p></p><p>I am proposing that, because you are fighting this now since almost one week and as I am sitting in front of that bloody device I should support you as much as possible...</p><p></p><p>Greetings</p><p></p><p>Axel</p><p></p><p>PS: What about a neat little splash screen showing the MP logo and keeping the user informed about the driver? <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" /> There could also be a banner telling the declined user all the names of all the ppl who worked on that driver <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /> Maybe it shouldn't exceed 10 minutes playing time, but could also contain a clear and almost political statement by you regarding the world economy and peace under circumstances where there are too many 0x7Es which should be controlled similar to all these chinese birth control laws and... WELL! <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></blockquote><p></p>
[QUOTE="Herr R aus B, post: 220366, member: 62807"] And here are the results from the German jury... Hm... You might not understand that joke, coz it's european... Anyway - I tested like hell and had a big grin in my face. Now it's time to also add some tool tips to the config dialogue containing bad remote bashing words, especially describing your very personal relation to 0x7E occurences :D I first tested just repeating on different repeat frequencies using just the UP button. Here is what I watched: [LIST=1] [*]Default repeat frequency: Not possible to determine whether each repeat scrolls two items or one, but most of the times after releasing the remote button, the menu scrolls one item back [*]Repeat frequency 100ms: Obviously still that behaviour of scrolling one item at the first repeat and then consequently two items each following repeat. Partly jumping one item back after releasing the button [*]Repeat frequency 200ms: same as above [*]Repeat frequency 300ms: behaves OK [*]Repeat frequency 400ms: behaves OK [*]Repeat frequency 500ms: behaves OK [/LIST] Afterwards I did some excessive UP, DOWN, LEFT, RIGHT, OK all over the menus. Got one frozen screen that got alive after some time again. Don't think that's related to your driver tho... Then I also tested fan control a little bit. Unfortunately fan control seems to be dead - is that deliberately disabled at this time? I tested two scenarios: [LIST=1] [*]Fan 1 set to manual control at 100%, fan 2 set to automatic control according to the default values, started and immediately stopped MP [*]Fan 2 set to manual control at 100%, fan 1 set to automatic control according to the default values, started and immediately stopped MP [/LIST] The result was absolute silence as in nothing happened. My interpretation especially of the remote behaviour would be that you should return to reading single byte bursts (well, bursts...) and maybe you are somehow taking over yourself regarding speed - especially using a repeat frequency below 300ms. Just a guess. As this coding just looking at logs must be a real pain I have in mind that I try to set up a little program here to maybe code a base algorithm for all this reading and writing. I dunno, how the serial port arbitration is done in MP. I would do it using a number of threads: [LIST=1] [*]thread to read single bytes and put the bytes read in two different queues: One queue for remote codes, one for non remote codes [*]thread to arbitrate the remote code queue (including our beloved 0x7E) [*]thread to arbitrate the rest of the receivings [*]probably additional thread to handle outbound bytes [/LIST] Whether or not the serial port should be secured using a semaphore or whatever synch mechanism I cant decide. I assume it should be able to process in full duplex mode. Furthermore I would read bytewise and then decide for each byte what to do - using kinda grammar tree or whatever one should call it to make decisions and control the associated state machine. I think the biggest problem is that state machine, as you are coding blindly. I remember that I once set up a state machine within a CTI client simulating a telephone with all its function and getting asynch signals from a CTI server. That state machine had about 15 flags controlled by some 25 boolean equations - it was a nightmare :D So coding this all without being able to immediately see the results of your algorithms must be a nightmare, too... If I make it to do some coding here, it surely would be either in Java or more likely in C++ as I don't have any clue about C# that you obviously are using. Maybe Java would be better, as it seems to be rather similar to C# from what I saw. But I dunno whether I'll be able to address the COM port using Java on a XP64 machine... Never tried that. Would that be of any help for you, or would that rather insult your coder's honour? ;-) Hopefully you are not of klingon decent then... ;) I am proposing that, because you are fighting this now since almost one week and as I am sitting in front of that bloody device I should support you as much as possible... Greetings Axel PS: What about a neat little splash screen showing the MP logo and keeping the user informed about the driver? :D There could also be a banner telling the declined user all the names of all the ppl who worked on that driver ;) Maybe it shouldn't exceed 10 minutes playing time, but could also contain a clear and almost political statement by you regarding the world economy and peace under circumstances where there are too many 0x7Es which should be controlled similar to all these chinese birth control laws and... WELL! :D [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Support
Input / Output interfaces
Mini Display
Zalman HD135 VFD (VlSys Mplay)
Contact us
RSS
Top
Bottom
