Reply to thread

Message

<blockquote data-quote="CyberSimian" data-source="post: 1256286" data-attributes="member: 141969">I played around with this again this morning, and stumbled upon a test sequence that clearly illustrates the problem, and which is repeatable (logs attached). The test case is this:(1) Exit MP with MP volume set to maximum.(2) Start MP.(3) Display EPG.(4) Select a programme to watch and start watching TV.(5) Press and hold the VOLUME_DOWN button on the Ortek. The typamatic action works correctly, the volume bar in the OSD gradually reduces in length to zero, and the audible sound level gradually reduces to silence.(6) Press and release the VOLUME_UP button repeatedly, about once per second. The volume bar increases in length by one unit for each press, reaching maximum after 16 presses. But the audible sound level is very much less than the level I started with in (1).(7) Press and hold the VOLUME_UP button. The volume bar in the OSD does not change (it is already at maximum length), but the audible sound level increases to the level I started with in (1).The log file shows many double entries for the audio mixer, but not all of the time. During step (7), the log has lines like this:[code][2019-03-16 09:08:40,949] [Log&nbsp; &nbsp; ] [MPMain&nbsp;&nbsp; ] [DEBUG] - Centarea: Command &quot;786888&quot; not mapped[2019-03-16 09:08:40,950] [Log&nbsp; &nbsp; ] [MPMain&nbsp;&nbsp; ] [DEBUG] - Centarea: Command &quot;175&quot; mapped[2019-03-16 09:08:40,951] [Log&nbsp; &nbsp; ] [8&nbsp; &nbsp; &nbsp; &nbsp; ] [DEBUG] - Mixer: AudioEndpointVolume change, new muted = False, new volume = 27525, old muted = False, old volume = 65535[2019-03-16 09:08:40,972] [Log&nbsp; &nbsp; ] [MPMain&nbsp;&nbsp; ] [DEBUG] - Centarea: Command &quot;786888&quot; not mapped[2019-03-16 09:08:40,973] [Log&nbsp; &nbsp; ] [MPMain&nbsp;&nbsp; ] [DEBUG] - Centarea: Command &quot;175&quot; mapped[2019-03-16 09:08:40,974] [Log&nbsp; &nbsp; ] [8&nbsp; &nbsp; &nbsp; &nbsp; ] [DEBUG] - Mixer: AudioEndpointVolume change, new muted = False, new volume = 28835, old muted = False, old volume = 65535[2019-03-16 09:08:41,012] [Log&nbsp; &nbsp; ] [MPMain&nbsp;&nbsp; ] [DEBUG] - Centarea: Command &quot;786888&quot; not mapped[2019-03-16 09:08:41,012] [Log&nbsp; &nbsp; ] [MPMain&nbsp;&nbsp; ] [DEBUG] - Centarea: Command &quot;175&quot; mapped[2019-03-16 09:08:41,013] [Log&nbsp; &nbsp; ] [8&nbsp; &nbsp; &nbsp; &nbsp; ] [DEBUG] - Mixer: AudioEndpointVolume change, new muted = False, new volume = 30146, old muted = False, old volume = 65535[2019-03-16 09:08:41,051] [Log&nbsp; &nbsp; ] [MPMain&nbsp;&nbsp; ] [DEBUG] - Centarea: Command &quot;786888&quot; not mapped[2019-03-16 09:08:41,051] [Log&nbsp; &nbsp; ] [MPMain&nbsp;&nbsp; ] [DEBUG] - Centarea: Command &quot;175&quot; mapped[2019-03-16 09:08:41,052] [Log&nbsp; &nbsp; ] [8&nbsp; &nbsp; &nbsp; &nbsp; ] [DEBUG] - Mixer: AudioEndpointVolume change, new muted = False, new volume = 31457, old muted = False, old volume = 65535[/code]Notice that the &quot;old volume&quot; level is always 65535 in this section of the log, but the &quot;new volume&quot; level is increasing by about 1300 for each log entry. It looks as though there are two separate memory locations that are being used to store the current volume level, but they have got out of step for some reason.One point (you may already be aware of this): the Ortek transmits keyboard shortcuts for WMC. Some of these are identical between WMC and MP, but others are not. In addition, some of these are recognised by Windows itself (i.e. when WMC is not running), for example VOLUME, MUTE, ENTER. Finally, there is the mapping layer for the &quot;Centarea HID&quot; that can alter the meaning of each button. What I don't know is what happens to the button presses in any particular case. Maybe one or more of these:Ortek --&gt; Windows receives keyboard shortcutOrtek --&gt; Centarea HID --&gt; (no change) --&gt; MP receives keyboard shortcut.Ortek --&gt; Centarea HID --&gt; config definition --&gt; MP internal function invoked (e.g. display EPG)I still have my test system for MP 1.20 around, so I tried that (it has some modified DLLs; I don't recollect what changes they contain, but it may have been your EPG fixes). The test described above does not exhibit the problem behaviour when used with the Ortek. Do you want logs from this system, for comparison purposes?-- from CyberSimian in the UK</blockquote>

[QUOTE="CyberSimian, post: 1256286, member: 141969"] I played around with this again this morning, and stumbled upon a test sequence that clearly illustrates the problem, and which is repeatable (logs attached). The test case is this: (1) Exit MP with MP volume set to maximum. (2) Start MP. (3) Display EPG. (4) Select a programme to watch and start watching TV. (5) [b]Press and hold[/b] the VOLUME_DOWN button on the Ortek. The typamatic action works correctly, the volume bar in the OSD gradually reduces in length to zero, and the audible sound level gradually reduces to silence. (6) [b]Press and release[/b] the VOLUME_UP button repeatedly, about once per second. The volume bar increases in length by one unit for each press, reaching maximum after 16 presses. But the audible sound level is very much less than the level I started with in (1). (7) [b]Press and hold[/b] the VOLUME_UP button. The volume bar in the OSD does not change (it is already at maximum length), but the audible sound level increases to the level I started with in (1). The log file shows many double entries for the audio mixer, but [i]not[/i] all of the time. During step (7), the log has lines like this: [code][2019-03-16 09:08:40,949] [Log ] [MPMain ] [DEBUG] - Centarea: Command "786888" not mapped [2019-03-16 09:08:40,950] [Log ] [MPMain ] [DEBUG] - Centarea: Command "175" mapped [2019-03-16 09:08:40,951] [Log ] [8 ] [DEBUG] - Mixer: AudioEndpointVolume change, new muted = False, new volume = 27525, old muted = False, old volume = 65535 [2019-03-16 09:08:40,972] [Log ] [MPMain ] [DEBUG] - Centarea: Command "786888" not mapped [2019-03-16 09:08:40,973] [Log ] [MPMain ] [DEBUG] - Centarea: Command "175" mapped [2019-03-16 09:08:40,974] [Log ] [8 ] [DEBUG] - Mixer: AudioEndpointVolume change, new muted = False, new volume = 28835, old muted = False, old volume = 65535 [2019-03-16 09:08:41,012] [Log ] [MPMain ] [DEBUG] - Centarea: Command "786888" not mapped [2019-03-16 09:08:41,012] [Log ] [MPMain ] [DEBUG] - Centarea: Command "175" mapped [2019-03-16 09:08:41,013] [Log ] [8 ] [DEBUG] - Mixer: AudioEndpointVolume change, new muted = False, new volume = 30146, old muted = False, old volume = 65535 [2019-03-16 09:08:41,051] [Log ] [MPMain ] [DEBUG] - Centarea: Command "786888" not mapped [2019-03-16 09:08:41,051] [Log ] [MPMain ] [DEBUG] - Centarea: Command "175" mapped [2019-03-16 09:08:41,052] [Log ] [8 ] [DEBUG] - Mixer: AudioEndpointVolume change, new muted = False, new volume = 31457, old muted = False, old volume = 65535[/code] Notice that the "old volume" level is always 65535 in this section of the log, but the "new volume" level is increasing by about 1300 for each log entry. It looks as though there are two separate memory locations that are being used to store the current volume level, but they have got out of step for some reason. One point (you may already be aware of this): the Ortek transmits [b]keyboard shortcuts for WMC[/b]. Some of these are identical between WMC and MP, but others are not. In addition, some of these are recognised by Windows itself (i.e. when WMC is not running), for example VOLUME, MUTE, ENTER. Finally, there is the mapping layer for the "Centarea HID" that can alter the meaning of each button. What I don't know is what happens to the button presses in any particular case. Maybe one or more of these: Ortek --> Windows receives keyboard shortcut Ortek --> Centarea HID --> (no change) --> MP receives keyboard shortcut. Ortek --> Centarea HID --> config definition --> MP internal function invoked (e.g. display EPG) I still have my test system for MP 1.20 around, so I tried that (it has some modified DLLs; I don't recollect what changes they contain, but it may have been your EPG fixes). The test described above does not exhibit the problem behaviour when used with the Ortek. Do you want logs from this system, for comparison purposes? -- from CyberSimian in the UK [/QUOTE]

Verification