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 ... 56 57 [58] 59 60 ... 103
856
Installation issues / Re: USBUIRT not transmitting in 10.04
« on: February 16, 2013, 11:56:31 pm »
But why, following this sequence, should the UIRT stop transmitting?

This all looks normal to me.  I see nothing that points to the problem here.  I'm not sure where to go from here.

Does the UIRT continue to receive from the remote when it stops transmitting?  Ie. does dcerouter get commands from the uirt/mce remote still?

J.

857
Users / Re: New audio scheme, and upgrades (Updated)
« on: February 15, 2013, 12:05:23 am »
I am very happy to hear that it is working for you!  Thanks for testing!

J.

858
Installation issues / Re: USBUIRT not transmitting in 10.04
« on: February 13, 2013, 08:47:04 pm »
jamo it *should* be working as you expect.

J.

859
Users / Re: New audio scheme, and upgrades (Updated)
« on: February 13, 2013, 08:36:32 pm »
pga: the process is not completely automatic, yet.  Couple of things:  After you create the multichannel sound card device you will need to run /usr/pluto/bin/UpdateAvailableSoundCards.sh.  This will fill in the missing device data you are referring to.  Select the proper card from the device data drop down. Next add the stereo virtual sound cards as children of the multichannel card and set the right and left channel #s for these devices.  Then you will run /usr/pluto/bin/SetupAudioVideo.sh.  This *should* generate an asound.conf and an /etc/pluto/alsa/virtual_cards.conf file.  This will create the virtual cards named: Virtual_XXX (where XXX is the device number of the virtual stereo sound card device in webadmin).  Set the Alsa Output Device of your squeezeslave devices to the appropriate Virtual_XXX device.  Quick Reload.

L3: SAV should completely ignore his audio cards and not create an asound.conf, EXCEPT for the virtual cards.  On my test headless core I got a broken asound.conf as I have not run AVWiz and do not plan on it (no mediadirector there).  AVWiz is completely optional.  Therefor SAV should only create the appropriate entries for a mediadirector sound card, xine, etc, if AVWiz is run.

J.

860
Users / Re: New audio scheme, and upgrades (Updated)
« on: February 12, 2013, 08:58:43 pm »
Hi pga,

The proper DeviceTemplates are being added to LinuxMCE.  You will be able to update your database to receive the new DeviceTemplates soon.

J.

861
Users / Re: New audio scheme, and upgrades (Updated)
« on: February 10, 2013, 10:29:28 pm »
ACC Multi-Channel

Thanks L3!  (And is 'AAC' - Advanced Audio Codec, fyi).  Great work on all the AV setup!

J.

862
Feature requests & roadmap / Re: Virtual 3D AI
« on: February 10, 2013, 10:16:18 pm »
Looking good!  Very neat stuff!

J.

863
Installation issues / Re: Multiple sound cards, selected at random?
« on: February 10, 2013, 10:11:28 pm »
Is Multi-Channel audio and Multi-Soundcard the same option?
Are multiple sound cards required for running multiple Slim Device players? (linuxmce + squeeze[anything] pulls search hits for softsqueeze, squeezeslave, logitech media server, slim-devices, and about 30 others I cant recall offhand.  I just want to use use Slim Device Squeezebox Players/emulators).

This may be of assistance with your initial issue of the sound card devices being detected in random orders on boot:
https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture#Set_the_default_sound_card

A multi-channel analog out (like on most Motherboards these days) can be split into seperate stereo outputs and used for seperate squeezeslaves.  This split is configured in asound.conf, here is an example:
http://forums.debian.net/viewtopic.php?p=422129

hth.

J.

864
Thanks posde!  I wasn't sure if it was in the repo yet or not.

J.

865
Users / Re: New Asterisk feature or is it my Gigaset?
« on: February 06, 2013, 11:35:05 pm »
Thanks posde!  I should have checked that first.

J.

866
Users / Re: New Asterisk feature or is it my Gigaset?
« on: February 06, 2013, 10:39:16 pm »
Okay, this sounds probably stupid on my part, but you're used to that from me, I suppose.
I'm using a Gigaset 610 IP together with LMCE and thats all working nicely so far. Today, when I came home I noticed a missed phonecall. Upon checking it on my Gigaset, I was astounded to see the full name of the caller in the display. It was somebody I knew, but didn't have the number for, so clearly this info came from somwhere else.
Right now I'm a bit confused, where this nice feature comes from...is Asterisk now automatically doing a reverselookup or is this something my Gigaset does on its own?
I'd appreciate your input.

Hey maverick, most callerid features that I've seen pass both the name and number of the called to the device.  Usually it's a feature of the provider that you can enable/disable in your voip account.  The gigaset does not do reverse lookup and to my knowledge LMCE is not doing any reverse number lookup either. 

Second, I also have a Gigaset 610 IP and I was just going to try implementing it and a voip line with my lmce production system.  Any advice on setup/integration with lmce? 

J.

867
I really want to beat whomever did the udev rules for these devices to a fucking pulp...

-Thom

Agreed.

J.

868
Sure, here it is on the accelerometer machine (hp6710b):

Thanks jamo!  You're device does not present ID_INPUT_JOYSTICK=1.  Your device will not be erroneously detected after the next snapshot is released.

J.

869
Thanks for having a look at this. I will try to apply and test your patches on my false positives (hp6710b notebooks accelerometer) and let you know. Will be great if this is addressed.

You're welcome, it's been buggin the crap out of me too :).  Just for completeness, could you post the output of:
Code: [Select]
udevadm info --query property --name /dev/input/js0for your accelerometer device.  (Accelerometer in my laptop doesn't present at /dev/input/js?)  I know it will not mis-detect a mouse device now but I'm not sure what the accelerometer presents as.

J.

870
There are two 'fixes' to repair the issue.  The first is script based only and will fix improper initial detection.  The USB_Game_Pad (c++) fixes the same issues AFTER a game pad has been detected.  USB_Game_Pad and the detection radars are independent.  All is working great here so I'm hopeful it will be rolled in soon.  I can provide copies of the scripts which, after you delete the existing GamePad devices in webadmin, will no longer detect and add new game pad devices.  Once a joystick device is plugged in it would create the game pad device and USB_Game_Pad takes over at that point.

If your issue is solely that you have erroneous detection and want that to stop.  You can use the following scripts as replacements then reboot the core/md in question (to reload the detection radar) and delete the existing game_pad devices from webadmin.  As long as you don't plug in anything that presents as a joystick then USB_Game_Pad should not run after this.

http://pastebin.com/nLSpwphr <- Gamepad_Detect.sh
http://pastebin.com/FbW50EiH <- AVWizard_Gamepad_Detect.sh

J.

Pages: 1 ... 56 57 [58] 59 60 ... 103