The Media Center Sandbox

I already know about MediaMetadata["Title"] the problem is that if I am playing a playlist I have no way of figuring out what my position is in the playlist.

I have a gut feeling I am going to post a nasty reflection hack soon. 

Unlikely reflection hacks will work here.

The data lives in ehshell.exe, plugins run in ehexthost.exe,  MediaExperience is just hiding a little proxy object behind it called MCMediaExperience that does all the work, out of process.

What this means is that, you can not reach deeper into the object stack of any Objects not inheriting off ExtensibilityPublicAPI.

I can see the data inside there, but reflection will blow up on objects that do not support proxying.

Bottom line.

This can not be done.

Plugins can not figure out the name of the file currently playing. Yay.

Hi sambo99,

how about having your own "managed playlist" - you could write a class (ManagedPlaylist) that actually manages your collection of media files and handles the PropertyChanged event of the current MediaExperience/MediaTransport (PlayState & PlayRate). If one file finished playing, you simply play the next file + this also give you some great binding options if you represent each media file as a specific bindable object (i.e.: MediaFile: Title, SubTitle, Durations, Date, Rating, Tags, etc etc).

Olcay,

This sounds like a great idea, but have you actually tried doing this?  The ability to consistently get events from MediaTransport.PropertyChanged seems to be difficult at best and impossible at worst from everything that has been posted here previously (unfortunately).

Cheers,
Andrew

Hi Andy,

yes worked for me on two commercial projects in the past. I will try to get a clean and bit more abstract version of it ready this weekend.

Btw, can you point to some of those difficult solutions?

Thanks,
Olcay

Olcay,

That's a brilliant idea, I will do that! Only problem is that is will not work in Fiji, but I guess I don't really want to support fiji anyway till its fixed.

Thanks
Sam 

Olcay,

Let me know if you would like to contribute your implementation to video browser. I will be more than happy to give you check in access.

Cheers
Sam

sambo99:

Unlikely reflection hacks will work here.

The data lives in ehshell.exe, plugins run in ehexthost.exe,  MediaExperience is just hiding a little proxy object behind it called MCMediaExperience that does all the work, out of process.

What this means is that, you can not reach deeper into the object stack of any Objects not inheriting off ExtensibilityPublicAPI.

I can see the data inside there, but reflection will blow up on objects that do not support proxying.

Bottom line.

This can not be done.

Plugins can not figure out the name of the file currently playing. Yay.

There isn't a supportable way to do this.  But MC is just another application running on Windows.

Pre-Fiji, you could also load up some of the unsupported assemblies and figure out recorded tv playback.  I never needed to determine video or dvd playback so I can't speak to those experiences, but I wouldn't be surprised if something is there as well.  Fiji changed that, there is an additional layer of abstraction.  It may still be possible, but I didn't find a way although to be honest I didn't put much effort into it either.

It's also possible to examine file handles.  MC can only playback one file at a time so it's not difficult to get the file by examining the extension.

A less scalable approach is to use restart manager.  The biggest drawback to this one is that you have to work off a known list of files and query on each one.

The last approach that I'm aware of is to pull the graph and enumerate the filters looking for the file source.  This works great for tv and dvds, but I don't think that the video playback engine publishes the graph so different approaches would have to be taken for different experiences.

Olcay:

Hi Andy,

yes worked for me on two commercial projects in the past. I will try to get a clean and bit more abstract version of it ready this weekend.

Btw, can you point to some of those difficult solutions?

Thanks,
Olcay

I'm going from the experiences of others in the performance of the Transport object, and some understanding of my own of how it works internally, so this may not be 100%.

The Transport object is a wrapped MBRO which you can't get to to extend the lifetime of, so you lose the object unless you continuously poll it, however continuously polling it seems to have a long term effect on it's operation (i.e. if you poll it every second, your add-in will die after a few minutes).

If you change experiences, the Transport object sometimes gets destroyed and recreated for the new experience, sometimes not.  Sometimes it gets destroyed/created even within the same experience. On TV Pack it's broken completely under some scenarios (e.g. TV).

Cheers,
Andrew

babgvant,

Re: "It's also possible to examine file handles."

Sure, but I'm going to have to inject a device driver to get that, and it a pain to get it to work with both 64 and 32 bit.

What about just using EVRPlay for playback, and ditching PlayMedia? I'm dreading making our app less stable just cause I want resume support.

You don't need to inject a device driver to do this!   You use the NtQuerySystemInformation API - you don't even need to be running elevated to get the info!

Cheers,
Andrew

Andy,

I had a look at http://www.codeproject.com/KB/shell/OpenedFileFinder.aspx?fid=422864&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26&select=2277170

In particular: "For an object of type file, the value bObjectType in SYSTEM_HANDLE is 28 in Windows XP, 25 in Windows Vista and 26 in Windows 2000.Since this application supports only XP/Vista, we can ignore all the items with values other than 28/25. In SYSTEM_HANDLE, there is another important member for us, the pAddress. For each file handle, there is a FILE_OBJECT associated with it and the pAddress is a pointer to that structure. Unfortunately, this address points to kernel memory space and a user mode application cannot access this memory. Here comes the role of a driver. Using the function DeviceIoControl, the pAddress is passed to the driver. The driver accepts this address and copies the file name from FILE_OBJECT, setting it in the out parameter of the DeviceIoControl function."

Have you got any sample code that is able to get file names without the driver?

Cheers
Sam

I haven't got any sample code I can share as it was developed for a commercial project, but I can tell you that it definitely works, and works without elevation.

Sorry I can't be more specific.

Cheers,
Andrew

sambo99:

babgvant,

Re: "It's also possible to examine file handles."

Sure, but I'm going to have to inject a device driver to get that, and it a pain to get it to work with both 64 and 32 bit.

What about just using EVRPlay for playback, and ditching PlayMedia? I'm dreading making our app less stable just cause I want resume support.

no custom device driver required.

there's some [deprecated] code in DTB that does this (I found the base on a forum somewhere and had to make several modifications to make it work on x86, it crashes horribly on x64).  i didn't try making it work in an unelevated context, so I can't say it if does (although I'm really surprised that AndyC was able to).  Elevation isn't hard when you use a COM server.

I didn't say it was a good solution (IMO there isn't one), just that it's possible :)  Support for addins that want to enhance OOTB experiences is lacking in MC, it would be really nice if this got better in Win7 (I've been asking Charlie for more here for a long time, hopefully long enough to get something).

EVRPlay was mostly born out of frustration with MC's lack of flexibility (and a little with SageTV's lack of EVR support).  It has some slick features (full fidelity multiple DVD bookmarks is my favoriate (took 30 min to implement, why doesn't MC do this OOTB?)), but I don't know if it would translate well as shelled from MC application.  That said, I am working on making the 10" experience better; if you have a specific feature request let me know.