Messages

31

Developers / Re: What features do YOU want in an Insteon Interface?

« on: December 17, 2007, 09:58:20 pm »

on another note, does ANYONE know how I may be able to SAVE certain state information?
Eg:  I'd like to be able to read a device's database, then it's delta.  SAVE it's delta for future comparison..possibly in the Child itself??
I really don't want to have to create a file and save it there..

Suggestions?

>> on another note, does ANYONE know how I may be able to SAVE certain state information?

First, if the data you want to store for a child device is the unique address or id that the parent uses to identify that child, you should use the device data: DEVICEDATA_PortChannel_Number_CONST 12  This is the standard.  So, for a light switch that is controlled by an X10 controller, that device data is something like C8.  If the light switch is part of an EIB system, it may be: 10.37.1.  And so on.

Now assume you need some special device data for your light switch that is totally unique to Insteon, and is separate from or in addition to the standard id that the switch has (which is device data 12).  Let's call this "Insteon Status".  The usual way is to go into the device template (say generic on/off switch) and add a device data ("Insteon Status"), and set the 'set by device' to true.  I don't recommend this, though, because the device templates for the child devices (like lights) are shared by all the interfaces (ZWave, EIB, etc.).  You don't want to add this to the template because then it will be there for all non-Insteon light switches too.  The best solution is to set the device data for devices in code without defining it in device template.  For example, add a new record to Device Data "Insteon Status".  The next time pluto2cpp generates the header pluto_main/Define_DeviceData.h there will be a #define for it.  Then in your Insteon interface, call the Command_Impl::SetDeviceDataInDB, passing in the device id and the new #define for your device data.  This will set it in the database, but this won't force it into the template, so it won't effect EIB and others.  Each time the router reloads and you get your pointer to the Insteon Device (DeviceData_Impl) you can call: m_mapParameters_Find with your device data to get the value.  That will get the value that was in the database when the router was last reloaded.  This is best, since you probably are keeping a copy of the current value in memory.  if you don't and need to do a database hit to retrieve the current value you already set, call m_pEvent->GetDeviceDataFromDatabase() (from Event_Impl.h)

32

Developers / Re: MAME Plugin Progress Thread

« on: December 17, 2007, 05:24:25 pm »

Thom.  Do you have Skype?  Or can we have a quick call on the phone?  You can send me a private email to aaron.b [at] plutohome[dot]com.  I think all this talk about the ContainsVideo is kind of getting lost in the weeds and a diversion since it's so trivial and something you'll never need to touch to do a games plugin.  You shouldn't need to touch that table either unless you want to create a custom remote control screen for your plugin.  We were able to add new plugins for VDR and VLC and never touched anything in the database or the base classes.  So I think the real issue is somewhere else and this ContainsVideo is just a red herring.  The big problem is the lack of documentation.  Because there's no clear overview, I understand it must be frustrating to try to reverse-engineer everything and figure out the architecture based on the code.  This has been a major issue with all the coders on the project (myself included) in that nobody likes to write documentation no matter how important we all know it is, and the Pluto code isn't well documented and only a couple people know how all the pieces fit together. 

33

Developers / Re: people who have made a media plugin, ANSWER!

« on: December 17, 2007, 04:58:11 pm »

>> but it does have references to a hardcoded list of types of subclasses.

I don't see where it has any hardcoded references to sub classes.  StoredVideo, StoredAudio, LiveTV, InternetRadio are not sub classes.  They are the types of media that any of the sub classes can handle.

The base class is MediaStream.  The subclasses (so far) are XineMediaStream, VDRMediaStream, MythTVMediaStream, now MPlayerMediaStream, in the future GStreamerMediaStream, and so on.

All of them share the same list of media types, and play one or more of those types.  They can all play a subset of Video, Audio, LiveTV, InternetRadio, etc.  And whether you're using Xine, MPlayer, VDR, Myth, etc., the type 'Video' and 'LiveTV' always contain video, and the type 'Audio' and 'InternetRadio' do not.  The purpose of ContainsVideo is simple.  It's just to know if the TV should be turned on or not.  I still don't see what's wrong with having this list in the base class as *a default fallback*.  If you're creating your own media plugin and in your case InternetRadio does contain video, then in your derived media stream just define ContainsVideo and put your own logic in there.

I wrote the VDR Plugin, for example.  It took me less than 1 hour to write VDR Plugin and get to the point where there's a VDR button on the menu and when you choose it, the TV comes on, goes to the right inputs, the stereo, etc., any other media in the zone is stopped, and the VDR device is started.  And it took very little code.  This is because 99% of the logic is the same between VDR, Myth, Xine, and the other media plugins.  So having default behavior, like a function 'ContainsVideo' which knows that media type LiveTV has video, saved a ton of coding and time, and reduced the chance of errors a lot.  If the base class didn't have this functionality and to add my VDR Plugin I had to write all the code all over again which, for example, determines that LiveTV has video, and to turn on the TV, and all that other stuff, it would have taken a lot longer and introduced a lot more possibilities for errors.

Note: I'm not saying the design is great, nor that VDR only took 1 hour to implement.  I'm sure the design could be improved upon, and welcome all the feedback.  It just seems the function in question is very, very trivial and insignificant.  It's a tiny piece of logic that just that returns true for Video and LiveTV since there's a video component, and for Music and Internet Radio returns false.  A lot of the code in Media Plugin does get really complex.  And there's a lot of spaghetti code that could be much improved.  This 'ContainsVideo' function represents 0.000001% of the work and logic in Media Plugin, and is just a tiny trivial function.  So I humbly suggest that while it may be possible to improve it, spending this much effort engineering an OO to a function that is so simple is really over-engineering.  I still have trouble understanding how it could possibly get in anybody's way.  Again, if you're doing your own derived Media Stream and don't like the hardcoded list, just change it in your derived class.  It can't possibly get in your way since you can change it if you like.  But since Xine, Myth, VDR, VLC, MPlayer, etc. all use the same list the same way (ie in all of them Video and LiveTV have video, and Audio and InternetRadio do not), why remove this code from change the base class, forcing us to copy/paste the same identical code into each of the derived classes?

BTW, there was already a media type for games anyway, which you'll see is in the list.  So if you just give your derived MediaStream for games that media type, the TV should come on without you needing to write any code.  But back to Thom's original post that he can't create a new plugin because he doesn't like the behavior of ContainsVideo in the base class, just override it in your derived class and then this much maligned code in the base class will never get called.

34

Developers / Re: MAME Plugin Progress Thread

« on: December 17, 2007, 08:10:19 am »

I posted a reply in the rant forum...  http://forum.linuxmce.org/index.php?topic=3489.0   If there's a flaw here I welcome having someone point it out.  But I've read the rant and I can't see the flaw Thom is referring to....

35

Developers / Re: people who have made a media plugin, ANSWER!

« on: December 17, 2007, 08:08:48 am »

Thom,

I know the media plugin well and wrote a lot of it.  I don't see where a base class was ever calling a derived class.  I looked through the code snippets you copied and didn't see them there.

I understand your frustration about why the base class for MediaStream has a hardcoded list of the types of media that contain video, which is needed so the media plugin knows if it should turn on the tv or only the receiver.  This code snippet was my doing.  The logic behind it is that the types of media streams (ie video, audio, pictures, live tv, etc.) don't ever change.  And whether the plugin is for xine or mplayer or gstreamer or something else, if the media type is 'MEDIATYPE_pluto_StoredVideo' it contains video, and if it's 'MEDIATYPE_pluto_storedAudio' audio it does not.  I could have made it a pure virtual function that each derived stream had to overwrite, but since it seemed the in virtually every conceivable application the list of media types was always the same, and the list of what types of media have video content and what types do not is the same, it seemed to make the most sense to put this 'default' functionality in the base class rather than forcing each developer of each and every plugin to write the exact same duplicate code in each of the derived media streams.  This approach seemed more fool proof.  If the derived media streams (Xine, MPlayer, VLC, MythTV, VDR, Generic) each had to duplicate the same code over and over, then it would introduce (a) a lot of possibility for error in that if for any derived class the user forgot to put the same list in the same way it would make his plugin work differently than the rest, and (b) if at some point down the road there is a new type of media stream we haven't conceived you'd have to make the change in a bunch of different places rather than making it in one.

I don't really see the design flaw here, or how this conflicts with the principles of OOP.  After all, the whole premise behind OO code is re-usability and reducing duplicate code.  So, since 99% of the time the derived MediaStream will need the exact same code, it seems like the correct OO way is to put this default code in the base class, and then if for some reason a particular derived media stream wants to handle it differently, then it can always override the ContainsVideo function.  Having the default behavior in the base class doesn't mean you CAN'T change in your derived class, it just means you don't have to since, to date, nobody has ever wanted to.

And the same thing is true for UpdateDescriptions.  99% of the time the way we display descriptions is the same.  Whether you're using Xine, MPlayer, or VLC (all have plugins), when music is playing the description is Artist / Album / Song Title.  So, again, it seems logical to me to put this default behavior in the base class so you're not required to duplicate the same code over and over and over again in each of the derived classes.  It also introduces uniformity.  If we took it out of the base class and put it in each of the derived classes as you suggest, then it's up to each programmer (and xine, mplayer and vlc plugins were all done by different programmers) to implement the description display the same way.  That means when listening to a song through Xine, it may appear as Artist / Album / Song, but when you move to another room where it's played through MPLayer, it's displayed as Song / Album Artist.  Again, having the default behavior in the base class doesn't mean you CAN'T change the way descriptions are handled in MPlayer, it just means you don't have to, and if you leave it alone, there will be a consistent, uniform way of presenting descriptions across all plugins.

How is this creating a problem for you?  If you want to override the default 'ContainsVideo' and 'UpdateDescriptions' for your particular media plugin, how does having the default versions in the base class hurt you?  And where do you see a base class ever call a pointer to a derived class?  Can you show me what line you saw that in?  I agree if that happened it would be bad, but I just don't see where it ever did.

You can email me to aaron.b  [at] plutohome [dot] com