Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - phenigma

Pages: 1 ... 58 59 [60] 61 62 ... 104
Alright, after conversation with tschak on irc I understand the issue a little bit more and it will require a bit more refactoring of the detection scripts and of the USB_Game_Pad device to function the way it needs too.  I'm am first fixing the detection scripts to detect ANY joystick existing on /dev/input/js?.  Then (hopefully) figure out USB_Game_Pad so that it will ignore non-joystick devices that present at /dev/input/js?.


awesome. patch it :)


Working on it.  :)  Here's a and that are no longer detecting my mouse as a game pad.  I'll submit to svn if I can get confirmation that it works for someone else with a gamepad and for someone who has always had the issue of improper detection of non joystick devices. <- <-


To illustrate my previous e-mail, and as tschak pointed out earlier, devices will either have or not have ID_INPUT_JOYSTICK=1. 

Here is the udev output from the mouse in my VirtualBox Virtual Machine that is consistently detected as a joystick, notice there is no ID_INPUT_JOYSTICK=1, it has ID_INPUT_MOUSE=1 instead.  Why it is mapped to /dev/input/js0 as well as the normal mouse input I have no idea.

Code: [Select]
# udevadm info --query property --name /dev/input/js0
DEVLINKS=/dev/char/13:0 /dev/input/by-id/usb-VirtualBox_USB_Tablet-mouse /dev/input/by-path/pci-0000:00:06.0-usb-0:1:1.0-mouse


OK, so the package is installed if required, but I can't see why the GamepadCmd variable is set because I can't figure out where/if it's ever used?
 snag is... that "GamepadCmd" bit... what is that used for and where does it come in. Is it a necessary step I'm missing out?

The GamepadCmd environment variable is read by the actual AVWizard (a C++ program) and it's contents are executed by AVWizard to start the GamePad device.  It also takes care of removing the device when the AVWizard completes.

When AVWizard completes, the GamePad Radar ( takes over detection..

It seems to me that the easiest way to implement this might be to simply alter the existing detection scripts.  Run 'udevadm info --query property --name /dev/input/js0' on each detected device and grep it for 'ID_INPUT_JOYSTICK=1', if that returns a value then activate the gamepad.  Likewise don't activate the device in the radar (or set GamepadCmd) if the grep returns nothing.  The udev rule would likely be more efficient on cpu resources.


Installation issues / Re: USBUIRT not transmitting in 10.04
« on: February 02, 2013, 08:27:46 pm »
I know the embedded transmitter (usb uirt embedded transmitter) is a child device, sort of a dummy device as referred to by Tshak, but should it still have a log file? Only the parent has a log file in my case (the parent being the receiver, which is working).

I do get the "some devices failed to start" message when I start up my MD. How do I track down which devices? Is it possible that the embedded transmitter is the one failing? Is it supposed to start (being a dummy/child device and all)?

Hmm, try the log for the Orbiter?


Installation issues / Re: USBUIRT not transmitting in 10.04
« on: February 02, 2013, 08:24:40 pm »
Haven't had a chance to look into this further yet, still fiddling with the remote mapping for the receiver, but I wanted to ask if anyone has one (USBUIRT) working as a transmitter in 10.04? If so, when you transmit a code (say in "Test" mode when you are entering codes and you press the test button), can you see a flash from the unit? I've tried using my mobile phone camera to watch the unit and I don't see anything so I'm presuming it isn't happening.

The USBUIRT will flashes the same red led when it emits an IR code that it flashes when it reads an IR code.  You will see it.

I see there was a bug in 07.10 and there are a few references in the wiki to transmission problems and I haven't tried any of those fixes, assuming they are no longer an issue in 10.04?

Anyone care to comment?

You should not need any fixes from 0710.  I have been using 2 USBUIRTs on 1004, for a couple of years now, and have never had a problem with them.

As possy says, not emitting a code is usually due to room differences between the device and the UIRT.


Installation issues / Re: LinuxMCE on raspberry pi
« on: February 02, 2013, 08:09:14 pm » has some attempts to get LinuxMCE running on RPi.
Can someone elaborate on why it is not possible to run LinuxMCE on RPi?
Seems like it should.

For some more information check this out:

Currently I have a raspberry pi running as a MD (no AV yet).  DCERouter *could* run on a pi, it would not handle media and orbiter regens would be painfully slow.  I have not built any of the database requirements to run a pi as a core, nor have I worked out an installation path for a core on rpi as I do not see it as necessary.  LMCE needs a beefier system as a core to properly operate.

Or, as hari says, look into agocontrol which is primarily home automation and is intended to run on lower power devices like the Raspberry Pi.


Users / Re: Media list (grid) scroll/page down button on IR remote
« on: January 30, 2013, 09:51:16 pm »
Heres my DCERouter.log as I move up the UI2 menu and select the Audio datagrid.  No Set Screen Type command is sent on my system, I'm using a standard XP MCE remote.


Users / Re: Media list (grid) scroll/page down button on IR remote
« on: January 30, 2013, 08:02:39 pm »
Jason, do you not see this if you open the log and search back to the point where you first opened the grid? you have to go back quite a bit...

Nope, I'm not getting that command.  I will check again but I select enter on the remote to open the grid and then got only 3 more commands, not including a Set Screen Type, as the grid displayed.


Users / Re: Media list (grid) scroll/page down button on IR remote
« on: January 29, 2013, 11:05:06 pm »
Can you verify that when the screen changes from the main menu, to the file list view, that there is a Set Screen Type being sent, and that the destination is your USB UIRT device ?

When the screen changes from the main menu to the file list view I see three commands, a 'Populate Datagrid' and 2x 'Get Datagrid Contents'.  No Set Screen Type command appears to be sent.  I'm tailing DCERouter.log for this info.

This would explain why the ch+/- button commands are being sent to the Media Plugin rather than the Orbiter?  While playing media my media control buttons are not working either, I assume a similar 'Set Screen Type' command is missing there.

This is pretty critical to proper operation by IR remote, I'm going to create a ticket.


Users / Re: Media list (grid) scroll/page down button on IR remote
« on: January 28, 2013, 03:29:59 am »
I need you both to tell me, if there is more than one Infrared Interface connected to your media director, and which one is set as the primary interface (look in Web Admin -> Wizard > media directors).. NOTE: USB Game Pad counts as an IR interface.

I have a single USB-UIRT, a single Windows XP MC Remote and no USB Game Pad devices attached to my core.


Users / Re: Media list (grid) scroll/page down button on IR remote
« on: January 27, 2013, 10:34:41 pm »
Set up the remote that comes with the Zotac AD04 box in LinuxMCE and it works really nicely - the receiver being my new USBUIRT. But my only gripe is that in media lists I have to scroll right to the bottom before I can get the list to scroll. How do I set up a button to page down on the media list?

Any ideas? I've tried the chanup, chandown buttons and, in fact, just about every other button but none seems to do that.

On standard MCE remotes these buttons used to scroll the mediagrids for me, that stopped working with my standard MCE remote some time ago.  Don't remember when.  Haven't worked for quite some time in 1004 imho.  Forgot all about it till now and just tested it.  No scroll with my standard MCE remote.


Users / Re: Raspberry Pi as Media Directory
« on: January 27, 2013, 10:29:00 pm »
Who watches stuff at 720p these days?! ;)

;D 1080P works very well on the pi in my experience!  There used to be some choppiness with DTS audio, not sure the status of that right now, but AAC and AC3 audio both work wonderfully!


Developers / Re: New Device Template (Samsung PN-51E 5-Series)
« on: January 27, 2013, 10:22:09 pm »
Hey Dennis,

I did a lot of playing with that script a couple years ago.  It was converted to create a serialized output rather than a .php script sometime before I started playing with it.  In it's last posted form I believe it was working well.  I have used it to move my device templates from system to system during re-installs many times with great success.  It is not a supported method of submitting/moving devices around right now.

It would be great to have the templates submitted to sqlCVS so they would be available for others to use.  Have a look at:


Developers / Re: Raspberry Pi builder
« on: January 27, 2013, 08:51:18 pm »
Clarifying my omxplayer babbling.

When I speak of creating an omx player device for lmce many people seem to think I am talking about a dce wrapper for the console based omxplayer.  This is not what my intentions are. 

omxplayer is essentially a console interface to a statically compiled omx library.  My intention is to port the player portion to dce so that it is a native device like xine, not a console wrapper like mplayer.

:)  Just wanted to clear that up in case there were any misconceptions about my intentions for the device.


Pages: 1 ... 58 59 [60] 61 62 ... 104