Author Topic: Scenarios and Plug-in relationships  (Read 5543 times)

kyfalcon

  • Guru
  • ****
  • Posts: 390
    • View Profile
Scenarios and Plug-in relationships
« on: February 03, 2012, 07:39:53 pm »
It is my understanding that the scenarios define what is seen on an orbiter. For example if you have a radio scenario defined for a room then the radio button will show up under the media. How does that scenario tie to a plugin? Is it by PK_MediaType? How does a plugin know what it is supposed to be handling?

tschak909

  • LinuxMCE God
  • ****
  • Posts: 5549
  • DOES work for LinuxMCE.
    • View Profile
Re: Scenarios and Plug-in relationships
« Reply #1 on: February 04, 2012, 01:21:29 am »
well, let's untangle this a bit:

Scenarios are simply what we call internally CommandGroups. They are groups of commands that get executed when asked by the DCERouter. The Execute Command Group command sent to DCERouter is what executes scenarios, given a PK_CommandGroup #.

If you look into the anatomy of a scenario, (go to Advanced > Scenarios in web admin), you will see that each scenario has a SPECIFIC command and a destination device the command is going to. Some commands go to individual devices (Turn this lamp on, turn another off), some commands go to the Plugins (i.e. sending a Set Level to the Lighting Plugin, to turn the lights in a room to a certain level, it knows which room by the from device on the orbiter).

So where are these scenarios generated? look in src/UpdateEntArea. UpdateEntArea is basically a utility that is run at each router reload. It has a boat load of heuristics throughout its .cpp source to determine if certain devices are available and if so, create certain sets of scenarios based on a set of rules. It is very simplistic at the moment, and should be rewritten to handle very complex rules, but this will happen in time.

What plugins DO handle, are essentially callbacks. The most common of these callbacks are:

* Event Interceptors: these handle events that happen throughout the system, and are used to do useful things when events happen, such as storing state, or sending out a bunch of messages when events happen.

* Datagrid Generators: These generate the dynamic rows and columns of data seen throughout the system, you create a DataGridTable, and fill it with DataGridCells, and return the finished pointer to the datagrid table when done.

* Media Plugins: These are plugins which extend media plugin to create new media streams, and as of Apr 2008, can also be used to extend the media source grids in the file browser. This is what you're doing.

I hope this has untangled things a little.

-Thom

kyfalcon

  • Guru
  • ****
  • Posts: 390
    • View Profile
Re: Scenarios and Plug-in relationships
« Reply #2 on: February 04, 2012, 02:22:20 am »
Thom,
I was trying to follow along with your game plugin / game scenario because this is how I would like to model my plugin. How does the game scenario know to populate the datagrid with just the games? I am assuming If I create a scenario called 'Sat Radio' and make the command 'Show File List' and PK_Media_Type = 14 for sat radio. That will get my scenario built. Then I go and create a DCE device Sat_Radio_Plugin and do all the sqlcpp stuff to get the stubs created. I then go and change that to do the create, start, stop media etc. Now comes the fun part. I want to load the stations into the database instead of populating using the PopulateGrid, that way I am assuming all the stations will show up and by adding attributes I can only show the genres just like audio/video. So the question becomes whats the best way to add the stations to the db? I can create dummy files that contain the name/genre/img. If I do this I assume once the entries are in pluto_media, the media_plugin will handle the grid population. Am I correct? If this is the case then when I hit play how does the the DCE router know that the play button should route this command to my new plug in? Am I on the right track?

Thx,
Kevin

tschak909

  • LinuxMCE God
  • ****
  • Posts: 5549
  • DOES work for LinuxMCE.
    • View Profile
Re: Scenarios and Plug-in relationships
« Reply #3 on: February 04, 2012, 02:55:32 am »
In my case, I am dealing entirely with file based media, so UpdateMedia simply cross references against the MediaType table for the extensions I am looking for.

In your case, you will need to read this:
http://wiki.linuxmce.org/index.php/MediaSourcePlugin

-Thom

kyfalcon

  • Guru
  • ****
  • Posts: 390
    • View Profile
Re: Scenarios and Plug-in relationships
« Reply #4 on: February 04, 2012, 03:08:51 am »
Thom,

I understand the MediaSourcePlugin, that is how I handled thing when I was just bastardizing the shoutcast plugin. I would like to make mine filebased as well, I would create x number of files station.xm or station.sir, in these files would be the stationid, image, genre, description etc. I could right a script to populate the pluto_media db with needed info so it shows up in the grid. When play is called on this file I would then use the file to get the streamURL. This way when I choose sat radio under media, all the stations show up, and I can narrow it down by selecting a genre. This way it works just like the Audio. If you can do it with the games plugin, then the only difference I see is how the plugins work and then how to populate the data in the pluto_media db.

Kevin

tschak909

  • LinuxMCE God
  • ****
  • Posts: 5549
  • DOES work for LinuxMCE.
    • View Profile
Re: Scenarios and Plug-in relationships
« Reply #5 on: February 04, 2012, 05:07:03 am »
I had to make changes to UpdateMedia in order to pull the necessary bits out and create attributes for them, look at the RomFileHandler, for an example. Even so, I'm not so sure that making this a file based plugin is such a good idea. Your call, though.

The other relevant tables of course are MediaType, MediaType_DesignObj, and DeviceTemplate_MediaType. Of course, then there is Screen, Screen_DesignObj, and the tables that HA Designer touches for a remote.

-Thom

kyfalcon

  • Guru
  • ****
  • Posts: 390
    • View Profile
Re: Scenarios and Plug-in relationships
« Reply #6 on: February 04, 2012, 11:22:11 pm »
Ok so I went back to bastardizing the shoutcast plugin for the time being like you suggest. Getting the grid populated. When I hit play I get the message cannot play this media. Perhaps there is not a valid device in this entertainment area.

It is not even getting to my CreateMediaDevice code. Am I missing something? By the way I am just passing a number as my url, I will use this when I make the call to sirius to get the url needed to play. Do I need to add something else onto this and then parse it?

         FileBrowserInfo *pFileBrowserInfo = new FileBrowserInfo(station.name2,"!E," + sToken + "," + StringUtils::itos(station.id),4,StringUtils::SQLDateTime("2008-02-8"));

tschak909

  • LinuxMCE God
  • ****
  • Posts: 5549
  • DOES work for LinuxMCE.
    • View Profile
Re: Scenarios and Plug-in relationships
« Reply #7 on: February 05, 2012, 02:24:55 am »
Just touched down in Texas, a little zombied...

Do you have an entry in DeviceTemplate_MediaType for your media type and player device template?

Also, did you register the media type in your plugin's Register() method?

Does something happen when you send an MH Play Media command to the media plugin with the media type, entertainment area, and filename filled in?

-Thom

kyfalcon

  • Guru
  • ****
  • Posts: 390
    • View Profile
Re: Scenarios and Plug-in relationships
« Reply #8 on: February 05, 2012, 02:57:04 am »
thom, i will have to check that in th am. Probably not. Enjoy yor evening in the lone star state