I'm currently working on MediMonkeyNet which is a C# library that reads information from MM5 and allows (rudimentary) remote control via javascript commands. It does so by opening a web socket to the chromium engine running MediaMonkey and then uses the Chrome DevTools Protocol to send javascript to MM.
With this I am able to trigger an exception in MediaMonkey if I send an app.player.getCurrentTrack() command. Now, since the exception only occurs if the command is sent from an external source it might very well be an issue on the side of my library. What makes me sceptical is the very specific set of conditions that is needed to trigger the issue.
Since the exception is thrown by the mediamonkey engine and not the chromium frontend I'm unable to really debug or even verify the issue, so I can't be sure what the actual problem is.
The exception can be triggered with the following steps:
- Start mediamonkey
- Play a song
- Click the 'Next' button to play the next song
- Send app.player.getCurrentTrack() -> exception
There are a couple of conditions that need to be met in order to trigger the exception:
- The exception only occurs in (public) revisions since 2123. In 2120 the same steps work perfectly fine.
- The exception only occurs if the comment property of the selected song is empty.
- The exception only occurs if the track is changed by clicking the 'Next' button while the MM is in full mode. The mini player works fine, as does changing the track by double clicking a song in the song list.
The problem seems to be exclusive to retrieving data about the currently playing track, other commands (e.g. app.currentSkin()) work fine, I therefore believe that it's somehow related to reading the track comment. The last couple of lines in the strack trace also seem to support this:
Code: Select all
;
; Line=9180 - Offset=30
; ---------------------
0140F706 B8A4F74001 MOV EAX, $0140F7A4 ; ($0140F7A4) BaseMedia.TSongListData.getCommentSync (Line=9182) UNICODE: 'Long texts not loaded, use getCommentAsync version' ; <-- EXCEPTION
0140F70B E8A8A3FFFE CALL -$01005C58 ; ($00409AB8) System._Assert
Could somebody provide insight into this problem? I'd be grateful for any pointers.