My setup and reason for it is documented here:
http://wiki.linuxmce.org/index.php/Alx9r%27s_Network_Attached_Storage_Setup

I now have 2x DNS-323 each with 2x 1.5TB drives.  That is where I keep all my media.  They have performed flawlessly.  The second drive in each DNS-323 is a full backup of the first.  I got my second DNS-323 about 6 months ago.  It worked out to a pretty good price per TB for a self-contained fully backed up solution.

If you are considering any sort of RAID as part of your media storage, I encourage you to google "RAID is not backup" first. 

Regards,

Alex

I know this is digging up an old topic but I've been trying to use this feature to backup my TV and Receiver device templates in 0810b2 and I'm getting some errors and no apparent output file.

This may be an old thread, but I think it's still quite an important topic.  I think it's important to be able to import/export/share device templates without the permanence of sqlCVS.  To explain what I mean:

 - device template import/export would be for moving around experimental, untested, unproven, half-working, questionable quality device templates between installations
 - sqlCVS is for permanently storing and sharing well-tested, proven-working templates

Right now, I'm pretty sure this script is the closest thing to the former that exists.

I'm thinking of doing a fresh install and would love to backup these templates first.  Is this working for anyone else right now?

I did get the script working for one of my many templates, however, it didn't work for most.  I can't remember if in the end it was failing out on execution, or if it was garbling the ruby code -- although I have seen it do both of those things.

This script is exactly the right idea, cheers to everyone who has got it this far.  It just needs to be progressed to the point where it works reliably.

Alex

Matt's comment prompted me to do some more testing. 

Doing a tail -f /var/log/pluto/XX_USB_UIRT_0038.log on both MD#1 and MD#2 yielded the following result:

MD#1: two distinct and exactly repeatable IR codes for each button
MD#2: a variety of IR codes for each button.  the exact code never seems to be received twice for the same button.

I swapped USB-UIRTs (I have a couple spares) on both MDs.  The non-repeatability does not follow the USB-UIRT -- it stays with the MD.  The problem occurs on at least two of the USB ports on the MD.

The MD is an asus eee box b202.

Has anyone else seen this?

Alex

Remote controls do not send the same ir signal every time you press the same button.

On the wiki page you referenced there is a section regarding the key codes to be placed in the remote configuration device data - there can be multiple codes for each key.

:Matt

I am aware of this.  I actually put that information on that wiki page myself some time ago.  With a well functioning USB-UIRT/remote setup, I usually see exactly two different codes for each button. 

The problem I am describing is not the two distinct codes from the remote.  Rather, the problem is that for the same button, the two codes that are received on each of MD#1 and MD#2 do not match.  That is, if you learn the codes on MD#1, they are different from those learned on MD#2.

Alex

I have determined that different specimens of USB-UIRT devices produce different IR codes from the same remote.  Here is what I did to determine this:

(using 0710rc2 throughout)

MD #1:
- Windows MCE remote #1 (from PVR-150)
- USB-UIRT #1

MD #2:
- Windows MCE remote #2 (from PVR-150)
- USB-UIRT #2

I learned the IR codes for the MCE remote on MD#1 both using this method:
http://wiki.linuxmce.org/index.php/Add_support_for_new_remote_controls
After doing so, both remote #1 and remote #2 worked reliably to control MD #1.  

I then used the IR codes learned on MD#1 in the device template for the remote control on MD#2.  Both remote #1 and remote #2 very unreliably controlled MD#2.

I re-learned the IR codes on MD#2 and created another device template for the MCE remote and assigned it to MD#2.  Both remote #1 and remote #2 controlled MD#2 reliably.

Hypothesis
I suspect that some critical characteristics of USB-UIRT devices vary enough from specimen to specimen that IR codes from the same remote will be different for different USB-UIRT specimens.  

If this hypothesis is true, then IR codes cannot be reliably shared when using USB-UIRT as a receiver.

Has anyone else noticed this behavior?

Thanks a lot!

That fixed it.

No problem.  Glad it worked for you.

Alex

I have been using clonezilla recently and have done probably 2 dozen image and restores.. both to the same hardware and different hardware i have not had one failure of any images. I have imaged both windows xp  machines as well as linuxmce.   However i have not imaged drives over 500 gb.

Tim,
That's a pretty high success rate.  I'm always interested in other people's real-world experiences.  Can you tell me what version of clonezilla you are using?  I'm also curious what tools you are using for partition editing and backing up your mbr. 

Regards,

Alex

First and foremost: Regardless of which tool you use, I strongly recommend you test that the image files produced can indeed restore your system from bare metal. 

All drive image tools that I have used can produce image files that they themselves cannot read.  The tools may well work in one situation but not another.  In my experience, it is a question of which tool works in more of the situations I encounter than the next tool.  Partition size (especially large ones), the file system type being imaged, and the file system type where the image is being stored seem to be factors that affect whether a tool succeeds.

Using a second otherwise-unused hard drive as a target is safe way to test your tools.

I image, partition, and restore a variety of computers regularly.  The tools I am currently using are as follows:

Drive Imaging: partimage
Partition Editing: fdisk
MBR Backup: dd

I use the versions exclusively on the System Rescue CD (www.sysresccd.org).  System Rescue CD seems to be more actively maintained than any of the other rescue CDs that I have encountered.

I have used these tools for Windows XP, LinuxMCE, Windows Vista, Ubuntu, and grub partitions.  Many of those partitions were part of multipartition, multi-boot systems.  So far, I have not found a situation that those tools cannot handle.  I have seen partimage produce unusable images when used with some non-default parameters, but it is still the most reliable way to take drive images that I have found.

Here are my experiences with other tools:
GParted
*cannot perform some operations on large hard drives (~1TB and greater)
*cannot be used to create a partition table that matches another arbitrary partition table to the sector

sfdisk
*cannot perform some operations on large hard drives
*does not reliably create partition tables from a file (which is its only real purpose)

Clonezilla
*Outputs image files that it cannot read without reporting errors.  In my experience, clonezilla creates usable files only in about 1 in 3 situations. 

Properly backing up and restoring the MBR, partition table, and partition contents is quite an involved task.  If you think it will be helpful, I will write a wiki on how I do this next time I do it on my LinuxMCE system (i.e. when I take the plunge to 0810).

Hopefully this helps someone.  There are few things worse than realizing that the image you have of a critical system cannot be restored.

Alex

Thanks for confirming that you've seen this too Seth.  I too, was wondering whether the USB to serial adapter was actually the cause or whether there was something else going on.

Cheers,

Alex

I encountered the same "Unable to download UpdateBinary" error on my new vista machine and was able to fix it:

Here is the wiki to workaround it:
http://wiki.linuxmce.org/index.php/Control_LinuxMCE_using_a_Windows_device_as_an_Orbiter#Special_Steps_for_Windows_Vista

Here is the trac ticket:
http://svn.linuxmce.org/trac.cgi/ticket/232

Alex

I seem to have eliminated this problem by switching the serial port to which the CM11A is connected.  I moved the CM11A from the USB to serial adapter to a com port that is onboard the motherboard.  I also moved my receiver's control connection from the onboard to the usb com port.  So far both the receiver and the CM11A are working well.

Anything that uses the PL2303 chip (Prolific Technology) will work fine, plug and play.

It's not always obvious which adapters are using which chips.  I can confirm that the last two Startech ICUSB232 adapters that I have purchased use the PL2303.  That adapter seems to be readily available in Canada at least.

I didn't have any values in the Volume Up / Volume Down Ruby Codes boxes #90 and #89 fields...I also seem to be missing the following from your Template.

#350
#313

Do you know why that would be?

Hmm...I have found that the contents of some ruby rectangles in device templates can get deleted when editing seemingly unrelated parts of the device template.  I haven't had this happen, however, unless I was editing the template.

Alex

I am using a CM11A to control one X10 appliance module for testing right now.  The CM11A is connected via a usb to serial adapter.  I am using the same adapter model without issue to control a TV on another media director.

I am able to control the X10 appliance module from linuxmce, however, I have found that the CM11A device gets disabled about once or twice a day. 

Has anyone else encountered this problem?

To get it working again, all I have to do is re-assign the correct serial port and uncheck disabled on both the CM11A and lighting module. 

Regards,

Alex

Here is the log for the CM11A device:

Code:

10      05/26/09 21:51:09.743           Receive string: MESSAGE 74             <0xb7145b90>
10      05/26/09 21:51:09.743           Received MESSAGE 74             0x806f740 device: 137 <0xb7145b90>
10      05/26/09 21:51:09.743           Received Message type 1 ID 192 from 0 to 138 (device: 137) resp 0 <0xb7145b90>
10      05/26/09 21:51:09.743           Child device 138 has channel A1. <0xb7145b90>
10      05/26/09 21:51:10.416           We have data to send for CM11A. <0xb6944b90>
10      05/26/09 21:51:10.416           Sending address with HouseCode=6, DeviceCode=6. <0xb6944b90>
10      05/26/09 21:51:10.416           Sending packet with HighByte=4, LowByte=66. <0xb6944b90>
10      05/26/09 21:51:10.416           Sending header with Checksum: 6a. <0xb6944b90>
10      05/26/09 21:51:10.428           Got response: 6a from CM11A. <0xb6944b90>
10      05/26/09 21:51:10.428           Sending ACK. <0xb6944b90>
10      05/26/09 21:51:10.860           Got response: 55 from CM11A. <0xb6944b90>
10      05/26/09 21:51:10.860           Address sent successfully. <0xb6944b90>
10      05/26/09 21:51:10.860           Sending function with Code: 2. <0xb6944b90>
10      05/26/09 21:51:10.860           Sending packet with HighByte=6, LowByte=62. <0xb6944b90>
10      05/26/09 21:51:10.860           Sending header with Checksum: 68. <0xb6944b90>
10      05/26/09 21:51:10.871           Got response: 68 from CM11A. <0xb6944b90>
10      05/26/09 21:51:10.871           Sending ACK. <0xb6944b90>
10      05/26/09 21:51:12.364           Receive string: MESSAGE 67             <0xb7145b90>
10      05/26/09 21:51:12.364           Received MESSAGE 67             0x806f740 device: 137 <0xb7145b90>
10      05/26/09 21:51:12.364           Received Message type 7 ID 0 from 14 to 137 (device: 137) resp 0 <0xb7145b90>
10      05/26/09 21:51:12.615           Command_Impl::OnQuit forwarding quit's to children <0xb7145b90>
10      05/26/09 21:51:12.615           Socket m_Socket 6/0x806f740 Command_Impl1 Dev #137 m_bQuit=1 <0xb7145b90>
10      05/26/09 21:51:12.615           Requesthandler 0x806f740 (device: 137) Closing request handler connection <0xb7145b90>
13      05/26/09 21:51:12.615           Exiting BeginHandleRequestThread thread... <0xb7145b90>
13      05/26/09 21:51:12.616           Exiting MessageQueueThread_DCECI thread... <0xb7946b90>
10      05/26/09 21:51:12.617           Destroying CM11A <0xb79476c0>
10      05/26/09 21:51:12.617           Destroying Thread - before Wait <0xb79476c0>
01      05/26/09 21:51:25.871           No response from CM11A device. <0xb6944b90>
10      05/26/09 21:51:26.421           Destroying Thread - After Wait <0xb79476c0>
10      05/26/09 21:51:26.422           Waiting for message queue thread to quit <0xb79476c0>

I was asked to hack away at this script and this is what I came up with.
It now has a web user interface and prompts to save/load template files to the user's local drive. Encapsulation of the data is now done using php's serialize function which should prevent it from attempting to resolve any php tokens in the data.

merkur2k,
That sounds great. 

I do not have a system to test out the import on so the best I have done for testing on that part is look over the generated sql queries. I would appreciate it if those with test systems could install it and test out a few different templates, particularly the ones giving problems above.

When I ran the output of the original script, it would generate a new copy (with the aforementioned problems of course) of the output device template.  The point is that you should be able to test the import by running the script on the same machine where the export took place -- it should generate an identical device template with a different device template id.

Regards,

Alex