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 - esev

Pages: 1 2 3 [4] 5 6
46
Developers / Touch Orbiter and Web Orbiter speed improvements
« on: October 20, 2010, 10:56:16 am »
The Touch Orbiters, including the Web Orbiter feel slightly less responsive than a normal DCE Orbiter.  This is because they are polling once per second to see if any updates have taken place.  If an Orbiter update takes place while they are not polling there is a delay before the updates are shown.

Currently, to poll for changes, a Touch Orbiter client issues a "ANYNEWS?" request to the Proxy Orbiter.  This is a short lived call which simply returns "yes" if changes have been made since the last poll, or "no" if there haven't been any changes.  If "no" is returned, the client typically waits a second, then makes another "ANYNEWS?" request.

A slight tweak to the ANYNEWS? request can be made in order both speed things up and to eliminate having to poll every second.  The tweak would make the request look like this: ANYNEWS? [<lastImageSent> <maxWaitMs>] (ex: ANYNEWS? 1 30000)  Where the two extra parameters are optional so as to not break existing clients.  The response could also be tweaked to return lastImageSent (which is just a one up counter that increments each time the Orbiter screen changes) instead of "yes" or "no".  This has the added advantage that the Proxy Orbiter never gets out of sync with the client and the client knows that the Proxy Orbiter supports the extra paramters.

When calling ANYNEWS with these extra parameters, the semantics of the call change. If there has been a change since the last poll, the call will return immediately.  If there haven't been any changes, the call will block until either an Orbiter update occurs or <maxWaitMs> milliseconds have expired.  If an Orbiter update occurs while the request is blocked, the request will immediately unblock and reply with the new lastImageSent number.  This cuts down on the number of ANYNEWS requests that need to be made and at the same time also allows the client to know immediately when an Orbiter change occurs.

If you'd like to experiment with these changes, please see the attached patch file.  I'm not sure all the bugs are worked out yet, but the Web Orbiter is a lot more responsive with these changes.

Edit: Deleting the patch file. Use the patches in the message below

47
Wow!  From the screenshots this looks great!

Any chance you could get it working on iOS 3.1.3?  I'd love to use it on my first generation phones.

48
Thanks for your replies guys.  Sounds like it is something that is do-able, but not likely to fit in very well with other features.  I'll put this one on the back burner for now.  There are plenty of other tickets that I can contribute to.

jimbodude, thanks for the list of issues Standalone Mode would cause.  Kind of puts the effort into perspective.

Hari, nice idea to use arpwatch for PnP detection!

49
One of the common first questions people ask on the forums is "why can't I use just one network card".  I understand that today using just one network card will break DHCP based plug-and-play and network booting the media directors, but is there a reason we cannot solve these issues?

To make DHCP plug-and-play work without being a DHCP server, the Dhcpd-Plugin could be extended to perform arp requests for each IP on the subnet.  Any new MAC/IP addresses that appears can then be sent to the Plug and Play plugin.  This can be further extended by listening on the DHCPD port for DHCPDISCOVER requests.  When one is seen from a previously unknown MAC address, then the scan can start again to try to discover what IP address was assigned to it.

To make the media directors boot from the network, couldn't a ProxyDHCP server be used?

Besides QoS, and possibly hard coded 192.168.80.1 issues, are there any other features that would break with only having one NIC?

Disclaimer: I'm not trying to personally setup anything other than the standard two NIC setup, I personally like to have a separate segment for media and home automation devices.  I'm merely wondering if it would be technically possible to make some small-ish changes that would make things easier for new people who would like to experiment with LinuxMCE.  I'm also not advocating making these changes right away, just trying to learn the downsides of using only one NIC.

50
Users / Re: Anyone using MythTV outside the USA?
« on: October 19, 2010, 05:21:33 pm »
Thank you very much for your reply.  I hadn't considered deleting the capture cards from LinuxMCE.  That would get around the mythfrontend dies after one minute issue.  Clever!

This is the only thing that works for me because I have no clue what linuxmce-default is doing, and I cannot make head or tails out of the manuals, I just do not get it.

You've hit on the issue exactly. :)  LMCE-Default is tricky.  It disappears if you add a second video source and it causes problems if you assign it to an input.  It's one of the parts of the MythTV Plugin that I'm aiming to fix and to make easier for all of us who have had to develop our own workarounds.

My plan is to tame the MythTV Plugin a bit and add a MythTV configuration page inside the Advanced->Configuration menu in the admin website.  From this page you'll have more fine-grained control over what LinuxMCE is doing with MythTV.  I'm hoping to take the feedback from this forum topic and use that to solve the specific issues people have been developing workarounds for.  So thanks much for your input!

Eric

51
Users / Anyone using MythTV outside the USA?
« on: October 19, 2010, 04:33:22 pm »
Like a lot of folks here using LinuxMCE I am living outside the USA and need to perform some manual setup of MythTV to get it working properly.  As you've probably already discovered, LinuxMCE tries to manage your TV capture cards within MythTV.  If you're like me, you first noticed this when LinuxMCE erases any changes you make to the capture cards within mythtv-setup.  The current solution for this is to select the "Dont Auto Configure" option on your MythTV Plug-in device.

This solution has a few problems.
  • If the capture cards are detected in a different order on your next boot (i.e. /dev/video0 becomes /dev/video1), LinuxMCE will no longer update MythTV with these settings
  • If new capture cards are added to your system, they are not automatically available in MythTV
  • If you create a new Media Director after selecting "Dont Auto Configure", mythfrontend dies after one minute

I'd like to make this better.  I think I can make a few changes to the MythTV Plugin such that you won't need to select "Dont Auto Configure" any more when making modifications directly inside mythtv-setup.  But before I do that, I need your help.  If you've had to enable the "Dont Auto Configure" option, could you describe why you needed to do that and how you've configured MythTV for your setup?

I'm specifically looking for information about how you defined your Video Sources and Input Connections and if you had to make any changes to the capture cards.  Also, were there any other reasons for selecting the "Dont Auto Configure" option beyond issues with Input Connections?

Thanks in advance for your input!
Eric

52
Users / Re: TrickleStar ZWave auto detection script - testers needed
« on: October 19, 2010, 03:30:05 pm »
Just a quote note before work- I ran through the (28) individual Spawn_PNP Detection ***** logs and all of them were blank.  Possible I missed the one with something in it, so I will look again after work.

As for lsusb:

....

BTW- I was looking at the Spawn files from the MD that I have my usb-to-serial adapter plugged into... not the core where I have my z-wave device.  I do not have any Spawn PNP...  files in my /var/log/pluto/ directory on the device where I currently have my tricklestar and my aeon labs z-wave usb device plugged in (the core).


huh,

Which computer (MD or Core) did you install the /usr/pluto/pnp/ZWave.sh script on?  You'll need to have it on both for this to work properly.

I think the Spawn* files get automatically cleaned up after a day.  It is possible that is why you're not seeing them on the core.

I'd really like to know if the script works on your MD, as that is one aspect I haven't tested yet.  You definitely have the right USB/Serial adapter to test with.

Thanks!
Eric

54
Users / Re: TrickleStar ZWave auto detection script - testers needed
« on: October 19, 2010, 01:53:45 pm »
Unfortunately got tied up tonight- but I have at least 4 different zwave devices (I am assuming because I have 4 different numbers in front of the .ZWave.log files.  All but one is empty- this is in the one:

Thanks huh!  Looks like it detected your ZWave device properly.  Would you still happen to have any of the /var/log/pluto/*ZWave.sh* files around?  Or have they been deleted?  An example filename is Spawn_PNP Detection 9435 ZWave.sh_19831.log.  Inside you should see one of two things.  Either this if the script detected a ZWave device:
Code: [Select]
ZWave Detection script queue 9435, serial port /dev/ttyUSB0
\06\01\10\01\15Z-Wave 2.36\00\01\91
It is a ZWave interface
RESP: OK

Or this if it was unable to detect a ZWave device
Code: [Select]
ZWave Detection script queue 9897, serial port /dev/ttyUSB0
It's not a ZWave interface
RESP: OK

Thanks so much for giving this a try!

55
Users / Re: TrickleStar ZWave auto detection script - testers needed
« on: October 19, 2010, 04:04:27 am »
I picked up a USB/serial converter tonight.  The pl2303 chipset must be pretty common because the serial adapter that I picked up luckily matches the vendor id on the TrickleStar.

I can now confirm that the script does what it was intended to do.  I'll submit this as a Trac ticket to get it included in LinuxMCE.  It'll be a nice addition to have this automatically detected right out-of-the-box. I'm guessing most folks will buy these TrickleStar dongles when getting started with ZWave, as they are highly recommended according to the wiki page.

56
Developers / TiVo custom orbiter screen crashes DCErouter (#851)
« on: October 18, 2010, 10:26:59 pm »
When support was added for the Series 2 TiVo, a new Orbiter screen was added to control some of the special features of the device.  When the entry for these screens was added to the MediaType_DesignObj table in pluto_main, the UIVersion field was left blank.  See ticket #851 for details, but the end result is that DCERouter is crashing as it is exiting.  Is anyone familiar with the custom HADesigner screens for the TiVo Series 2?  If so, are they built for UIVersion 1?

Sorry for cross posting this on the forums, but I thought it might get the issue to a larger audience in hopes someone might be able to fill in the missing information so the ticket can be resolved and closed.

57
Users / Re: TrickleStar ZWave auto detection script - testers needed
« on: October 18, 2010, 08:19:36 pm »
Just so there isn't any confusion on what I'm asking, see the attached screenshot for what the new Plug & Play section of the ZWave device template (1754) should look like.

The intent of the script is two-fold.
1. It will allow the Tricklestar 300ZW ZWave device to be detected and automatically added to LinuxMCE
2. It will not add a ZWave device when an ordinary USB/serial adapter is added to the system.

For this to work correctly, both the Vendor Model ID and the PNP detection script need to be added to the Plug & Play section of the device template.  If only the Vendor Model ID is added there is a risk of similar Serial devices being incorrectly detected as a ZWave interface.  If only the PNP detection script is added, the 300ZW ZWave device will never get detected.

If my understanding of how the PnP plugin works is correct, using both the Vendor Model ID and the PNP detection script should cause LinuxMCE to run the PNP detection script any time a device with Vendor Model ID 067b2303 is plugged in.  If the detection script determines this is a ZWave interface, it'll inform LinuxMCE to add a new ZWave device using the ZWave template.  If the detection script cannot determine if this is a ZWave device, it is supposed to fail gracefully and let LinuxMCE know that this device is NOT a ZWave interface.  In the case of this script failing, LinuxMCE should choose another device template that also uses the 067b2303 Vendor Model ID.

I'm able to verify that one half of this is working properly: that the script automatically detects my 300ZW dongle as a ZWave device.  But I don't have any USB/Serial adapters to test to make sure the script fails gracefully, not adding a ZWave device, when a pl2303 USB/Serial adapter is added to the system.

If you can test that this script works for either of its intended purposes, please post any /var/log/pluto/*ZWave.sh* log files that get created when LinuxMCE does its auto-detection.  That will help me know whether or not the script worked properly.   Thanks in advance for anyone who is able to test this!!

BTW: I'm basing all this off what is described on the wiki page for the Plug&Play plugin.  If that page is out of date, please let me know.

58
Users / Re: TrickleStar ZWave auto detection script - testers needed
« on: October 18, 2010, 05:30:45 pm »
My PLCBus USB uses the same usb/serial converter (recognized in lsusb as pl2303 USB/Serial adapter), that would mean that my system would detect it as zwave controller too?

I'm hoping not, but that's why I'm asking for testers. :)  It looks like there might be several devices that all use that same USB vendor ID.  I think LinuxMCE can only auto detect USB devices by their vendor ID.  Correct me if I'm wrong, but if two USB devices share the same vendor ID, then to be properly auto detected, each device needs to have its own PNP detection script.

The PNP detection script sends commands that only one specific device should respond to and makes sure it gets a valid response back from that device.  In the case of this script, it sends a ZWave formatted query to the device asking for Version information from the device.  If the device responds to that query, and the response contains the string "Z-Wave" then the script tells LinuxMCE that this is a ZWave device.

I'm hoping that other devices that use the same pl2303 won't respond the same way to a ZWave command.  If that is the case, the script is supposed to tell LinuxMCE that the device isn't a ZWave device.

Would you be willing to try this out on your system?  You'd have to make the changes I mentioned in the first post, delete your PLCBus USB, and then quick reload the router.  If the script works correctly, it shouldn't add a new ZWave device to your system.  If you are able to test, please post any /var/log/pluto/*ZWave.sh* files that get created during the detection process so that I can verify the script works as expected.

59
Users / Re: Bug Fixing our way to an RC
« on: October 18, 2010, 04:53:43 pm »
I'd really like to contribute to bug-fixing but find I'm being held back by some of the issues that are being discussed in the aforementioned thread. One thing that might help is if the more experienced devs can identify some bugs that would be easier for the less experienced to tackle (if there are any). That way, the experienced devs can focus on the bugs that only they (at present) can tackle, and we have a more efficient system of delegation.

Great idea davegravy!  I'm in about the same position as you.  I'm new to LinuxMCE and would like to contribute to bug-fixing so that I can learn more about how the internals work.  I have Linux development experience and know C++, but just don't know where to jump in and be helpful with a project this big.

So far I've just been fixing small bugs that I've encountered along the way.  I was going to work on ticket 831 which deals with getting MythTV working smoother for those of us outside the US.  But if there is something more important that I can work on, please let me know.

TIA,
Eric

60
Users / Re: TrickleStar ZWave auto detection script - testers needed
« on: October 18, 2010, 04:00:32 pm »
Hari,

I see you have some pl2303 USB/Serial adapters in your setup.  If you have a chance, could you verify that this script doesn't incorrectly detect them as ZWave devices?

TIA
--Eric

Pages: 1 2 3 [4] 5 6