try doing an sqlCVS update via the command line:

Code:

/usr/pluto/bin/sqlCVS -H schema.linuxmce.org -R 3999 -U anonymous~anonymous -r dce update

-Thom

Oh wow, thanks a bunch, can somebody test this? as I am roughly a thousand miles and change away from my core...

-thom

Ok, that is a very strange bug, that should never happen. Can you tell me the version of the lmce-usb-gamepad package that you have ?

-Thom

Gamepads typically do not have a _back_ button, and with the current code, while game play is happening, all game pad buttons literally are ignored by the USB Game Pad device, so I think you'll need to be a bit more specific, here.

-Thom

[The architecture is like this, in order to provide an exceptionally flexible method of sending media to different target devices. the Media Plugin simply deals with media types, and destination, and it asks each registered plugin for a media type to handle its requisite player devices independently. This allows for playback of a type of media on a wide range of heterogeneous devices, all at the same time, and to be able to arbitrarily move between these different devices.]

The Plugin runs on the core. The Player runs on each participating media director.

The Plugin's job, is to interface with the Media Plugin, and provide a specific stream type to the Media Plugin, a stream in this case, is mainly a media handler object specifying what type of media this is, where it is going to, and any information needed by the Player to be able to play the resulting media.

The Plugin's job is divided into several main functions:

* Register - to map the relationship between the plugins, and the players they ultimately take care of. This is cross referenced against the DeviceTemplate_MediaType table, and the Devices mapped into entertainment areas to determine whether an entertainment area has a player capable of playing a media stream specified by the Media Plugin.

* CreateStream - this function literally creates a subclass of MediaStream to handle your custom media type. The whole thing here is to determine which players in an entertainment area can take care of a device, fill out the MediaDevice entries for them, and include that in a custom MediaStream subclass, that is ultimately passed back to the Media Plugin.

* StartMedia - This function literally takes the information passed in from the Media Plugin, as it has processed the information it got back from CreateMediaStream to find destinations etc, to find all of the media player devices that match, and to send them a CMD_Play_Media for the target media. If a bookmarked position is passed in, here, it is also handled here as well, as well as if there are special considerations, such as starting media on "chapter boundaries" etc.

* StopMedia - This does the inverse of the StopMedia function, and sends a CMD_Stop_Media() to the resulting players, so that the media can be stopped as needed.

There is also the custom MediaStream subclass, which specifies any changes to MediaStream that need to happen, the most important being does it ContainsVideo, ContainsAudio, etc...so that the media plugin can only turn on the video pipes if it needs to, etc. The various Set Now Playing bits are also defined in the media stream subclass, as well.

The Player, on the other hand, runs on the media director, and literally provides the one to one mapping of commands that directly affect that player's operation. Play, Stop, Fast Forward, Rewind, Move up, Move Down, Left, Right, etc... Each of these commands get forwarded to the media plugin, which forwards them to the player's media plugin, which forwards them to the appropriate media player device, automatically (this is what the Register() method ultimately sets the stage for), so that we don't have to make a play button for each and every single media player type on the planet.

The only other aspect not mentioned here is streaming to multiple destinations. To LinuxMCE, streaming to multiple destination is simply passing a given URL, and a list of destination player devices, to the media plugin, which the media player plugin ultimately converts into a CMD_Start_Streaming command, at which point it is up to the plugin to determine how best to coordinate the effort between the different target devices, and send the appropriate playback commands to the players to accomplish the desired tasks.

One thing that DCE device skeletons provide, is an implementation stub for each and every single function. You can see the output of these on the console, as you run your device. Watch the output of these, as you do commands, to see the sequence of commands and what happens. The DCE Router log is also helpful in this regard.

The architecture is like this, in order to provide an exceptionally flexible method of sending media to different target devices. the Media Plugin simply deals with media types, and destination, and it asks each registered plugin for a media type to handle its requisite player devices independently. This allows for playback of a type of media on a wide range of heterogeneous devices, all at the same time, and to be able to arbitrarily move between these different devices.

-Thom

Hello,

Once again, going to try to see if anyone will take this up, before I do.

It is not only possible, but trivial to write a media player for Youtube, that utilizes http://www.youtube.com/tv .

An embedded WebKit window with HTML5 video playback will more than do the job. Since this web site has very well defined contexts and input modes, at the very least, orbiter screens for Hulu can be re-used verbatim.

In addition, any events that trigger a page change can be monitored for specific URLs (e.g. /watch), so that LinuxMCE can be notified when a phone or a tablet pairs with the TV and starts sending searches and requests.

What you will need:

* Development tree in SVN: http://svn.linuxmce.org/svn/trunk
* Read "Developing a DCE Device" on the LinuxMCE wiki
* Read the source code for Hulu Plugin and Hulu Player, as a reference guide.
* make changes to the database tables: MediaType, DeviceTemplate_MediaType, Screen, Screen_DesignObj, MediaType_DesignObj.
* make orbiter screens if you want, look at my HADesigner Screencasts for a reference, but the existing Hulu screens should work as a bootstrap at least.

This would take a weekend's worth of work to get something visible. If nobody attempts it, I will start on it, after the AirPlay Streamer is done.

Come on guys, let's get some more developer participation, for once!

-Thom

Brilliant design. Somebody let me know when this appears, and I'll get one, and whip up a driver.

-Thom

Jumbo frames can vastly improve performance in some cases, however, the rest of your network must be set up to properly handle it too, both your switches, and your target devices.

If you wish to use this, you will need to find out the size of the jumbo frames that all of your devices can support, and use that value for all your devices.

-Thom

To do more advanced programming like what you would want, and to do it automatically, you would need to make an Orbiter.

Orbiters register themselves with the Orbiter Plugin using Device Registered, and at that point, get all sorts of information, such as the status of each user, etc..

Orbiters then send commands to different devices, such as the media plugin, to do things like change the volume in a room (this is derived from the room the orbiter is currently set to, and the media plugin then traverses the appropriate pipes to do the right thing.).

Of course, any DCE device can manually send commands to the target device, you just have to form the right message, and then use SendCommand() to send it off. Look at Developing a DCE Device.

-Thom

You may want to read the Developing a DCE device page on the wiki, and then read the GSD, and Generic Serial Device pages on the wiki, as well.

-Thom

If there is a protocol that these devices use, then a DCE device can be made for them that uses IRReceiverBase, to translate messages appropriately.

-Thom

Those devices, do indeed, work.

For testing purposes, make sure that Windows or NFS file sharing is enabled.
Make sure that there is at least one visible share, preferrably public.

If it is not finding the device, you can try checking the Advanced > Configuration > Unknown Devices page, in the web admin for your NAS.

You can also check the SambaScanner.log and NFSScanner.log files in /var/log/pluto to see if the system is seeing your device.

-Thom

Essentially, the IR database is not downloaded to a LinuxMCE installation, in its entirety.

(when you see me talk camel case, I am talking about database tables)

/usr/pluto/bin/WebDB_GetIR.sh is used to grab the relevant PK_InfraRedGroup from the InfraredGroup table. This is linked to the DeviceTemplate (as a FK_InfraredGroup).

So basically, this script is asking my web server for a particular code group, and it comes back, and the relevant rows are altered in your database.

This is where things get a little murky...

We have a very cleverly designed system called sqlCVS, which loosely replicates a master database, amongst potentially tens of thousands of LinuxMCE users, this is done using the psc_* tables and columns in each table to implement a global primary key, which is carried across to multiple installations.

When you sqlcvs update, it checks your psc_* stuff, against the master server, to figure out (1) which rows have been deleted, (2) which rows have been added, and (3) which rows have been modified...and then executes a series of transcactions to get things in sync.

These psc_* numbers are used to figure out what the next primary key ID should be, when a new infra red group, device template #, whatever, is added...and since this database has had a LOT of modification, deletions, etc.. those primary key numbers have a big gap between the primary key, and what the global primary key is, (e.g. device templates right now, are somewhere around 2254, where the psc_id for that table is now in the 2400s, so new device templates will have a primary key # of 2401, UNTIL THEY ARE cHECKED IN, at which point, when they are approved, they get renumbered in the process, to 2255, or whatever... the same is for the IR groups...SOMETIMES THIS WORKS...SOMETIMES IT DOESN'T... this is why it is critical, if you're developing templates etc, t ALWAYS KEEP YOUR DATABASE IN SYNC, BEFORE YOU MAKE CHANGES, to try and mitigate these problems...

We really need database people to come in and try to improve this situation, it's a clever schema that was hoisted upon us by a mad scientist (Aaron Baalbergen, the guy who founded Pluto, and we've had to live with it, and while some of us understand the concepts very well, none of us have audited or tried to understand sqlCVS code to try and solve these problems.

I don't know if i've managed to explain anything, or if i've confused the shit out of you, but let me know.

-Thom

I am sorry this happened, what device template is it? I will try to find the relevant IR group, most likely it got clobbered due to an anonymous commit. Was this change approved?

-Thom

The Motion Wrapper talks to Motion, to get both individual JPEG frames, that we process, as well as generate Sensor Tripped events that we use for security events.

-Thom