this is just a simple article about another development paradigm for Media Center Edition (MCE). the last article /mceSAPI showed how to create a MediaCenter Add-In that allowed you to control MCE using only your voice. another dev model which i have not explored yet is to use Hosted HTML. instead of a MediaCenter Add-In or Hosted HTML, this article will look at using the MediaState SDK. specifically, it will create a stand-alone windows forms application that will receive all the state change events that MCE fires.
the MediaState SDK allows you to determine the status of your MCE. the documentation suggests that this might be used by OEMs to drive external displays. from a software perspective, i could use this with the /mceSAPI application to determine when the song track changes and use Text To Speech (TTS) to speak the artist name and song title over the speaker system. this event would be fired regardless if MCE was being controlled by the remote, mouse, or voice. else i could have it listen for a command such as 'song title' or 'song artist', and the MediaState API could be queried to determine that info. then i would not have to turn on my TV to find out that info. it can either be polled by your application (yuck) or your app can subscribe to state change events. the event model can also be used in 2 ways. you can subscribe to specific events or subscribe to all events and then only take action for certain ones. the good news is that MCE provides alot of events, even down to 1 second increments of a song being played. the bad news is the MediaState API is somewhat of a 2nd class citizen. you can tell this by its namespace being Microsoft.MediaCenter.Samples.MediaState. also the steps that you need to go through to get it working. i'll detail this in the next section.
the MediaCenter 2005 SDK comes with 2 MediaState samples. FileWriter is a C++ sample that writes the state info to file; we wont be looking at this one. the other sample is a stand alone C# application called MediaDisplaySampleApplication. the code is kind of interesting because its using XML files to layout what the UI should look like. some sort of pseudo XAML type scheme using WindowsForms, but i'll leave that for you to look at. so the WinForms app will be receiving the event notifications and updating its UI to correspond with what is happening in the MCE shell. the other side of the equation is the MediaState Aggregation Service (MSAS). it is a COM server that fires the events. just so happens that the SDK samples includes an implementation that we just have to register. the final piece of the puzzle is a MemoryMapped file. this is how the COM server and the MediaState API communicate. the COM server writes to the MemMap and the MediaState API reads from the MemMap.
the 1st step is to register the COM server in the registry. this can be accomplished by running this file : MediaState.reg. this file has 2 modifications from what is provided in the SDK documentation. first, the version # of the .NET assembly is changed to match the version of the assembly provided with the installed SDK. second, the file path to the COM server has been set to the default installation path. after the registry entries were added, i restarted the computer for good measure
the 2nd step is to build the MediaDisplaySampleApplication. even though MCE is .NET 1.0 you can build this app using newer versions of .NET. the reason is that the MemMap file decouples the differences between the runtime versions.
finally, i ran the MediaDisplaySampleApplication and then started the MCE shell (not in full screen). when i selected and began to play an audio track, then the sample application updated its display to show the track info and the current playing time.
if that doesnt work, you might try to turn on logging for the MSASState assembly. just rename (to .config) and place the following .txt file in the same directory : MSASState.dll.config. the assembly should parse that file and write to the local log file if it has any errors. i've also seen an ErrorLog.txt file spring up in that directory, so you should look there anyway
the MedisStateSampleApplication is a pretty app, but i really wanted something ugly that would show me the full power of the MediaState API. specifically, i wanted to see all of the events that were being fired from MCE. so all i did was create a simple little WinForms app that hooks every event. all it does is startup, hooks the events, and then Connect(). it hooks the typed events 1st, and then the generic event. this is somewhat redundant, but will provide the most info. the typed events will not be indented and the string will be in the form SessionType_Event. the different SessionTypes include : MediaCenter, CD, DVD, PhoneCall, Pictures, Radio, TV, TVRecorded, TVRecording, Video. the Events will mostly include : Ended, Forwarding, MediaChanged, Pausing, Playing, Rewinding, SlowMotioning, Started, Stopping. each Session also contains other events that are more specific to it alone. the generic catch all event will be indented. notice how there are multiple generic events fired to represent some of the typed events (e.g. Music_TrackTimeChanged below).
the text files below show the results from some short runs.
that is a simple example of working with the MCE MediaState API. i think it is a very powerful API for the MCE platform. it makes perfect sense for applications that require a large amount of system resources to be aware of the state of MCE, so that your disk defragmenter or desktop search does not fire up when you are watching a movie and ruins your overall experience. my hope is that the next version of the SDK will move the MediaState API from a sample and into the supported codebase, as well as pre-installed registry settings. i would like to also see some extensibility points in the API so that our long running MediaCenter Add-Ins can send their own events through this same mechanism. plus, it could fire some more events, such as when a photo directory was selected.
this article (and code) is simple. really just put this out because i couldnt find much of anything else about this API and saw that people (myself included) were having problems getting the sample to run. thought about writing an actual application to go with it, but nothing really jumped out at me that i 'had' to write. some of the stuff i thought about doing was sort of using this to create the inverse of MCE Controller. where MCE Controller opens up a port and listens for incoming remote commands, you could use this to provide an outbound channel of state info. what that setup, you could then turn your PocketPC into a sort of PocketPC MediaCenter Extender that allows you to see the current state of MCE and send commands to it. an alternate application might be to monitor your children. you could enter keywords of music / videos you did not want them watching. then a service would run in the background and check the incoming media titles against the stop list. if something negative showed up, then it could be logged or you could be notified. its all about invasion of privacy. finally, i think it makes perfect sense to integrate this into the /mceSAPI app for TTS state notification as described above. this would be even more important if you put MediaCenter into your car. so you could use speech reco to ask what state the system is in and then command it appropriately without taking your eyes off the road
more MCE. its time for a Hosted HTML app ... later