Logitech Support

In my last post, I detailed the trouble it was to get my new Logitech F710 gamepad to work as advertised. When I first encountered trouble, I fired off an email (via Logitech's web form) to their support department. In the interim between my email and their first reply, I managed to fix the problem, but I decided to go ahead and continue to play the role of confused customer to see how quickly Logitech would resolve the problem.

Recall, the issue is that in order to get the Logitech F710 to work, you must force the installation of the XBox 360 controller driver. Logitech does not supply the correct driver with their device and they do not provide instructions on how to use the Microsoft one.

My first email:


From: Lord Byron II
Sent: 1/10/2013 7:04PM
Message: Whenever I switch the gamepad from DirectInput to XInput, it loses connection with the PC and I must use the F710 re-connection program to re-establish the connection. Further, the Logitech game profiler software can't find the Gamepad when it is in XInput mode and Windows shows the driver to not be installed when it is in XInput mode.


The condensed nature of my message is due to the restrictions of sending a message through their web form. Had they supplied a real email address, I would have sent a longer, more detailed message, but this does get the point across. I received an almost instantaneously reply from their automated system with a couple of unhelpful links and a promise of a reply within 48 hours. I ended up getting a reply from a human 6.5 days later:


From: Logitech Support
Received: 1/17/2013 11:45AM
Message: Thank you for contacting the Logitech Customer Care Team. My name is Jay-R, and I am glad to assist you. Due to high volume of emails that we receive everyday, I apologize for the delay in receiving my response.

Your support reference number is: 130111-003764. Your reference number is a way for us to track your support request.

Please indicate or mention your support reference number for quick and future reference of this particular case.

From your e-mail, I understand that whenever you switch your Logitech Wireless Gamepad F710 to Xinput, it loses connection to your computer and your Logitech Profiler cannot find it.
I do apologize for the inconvenience that you've had with the product. I will certainly do my best to resolve your concern.

About your inquiry, I would like to inform you that the Xinput refers only to Xbox 360. If you are going to use it on your computer, you should always use the Dinput. You can also use the Xinput on your computer if your computer has an Xbox driver.

If you have any additional questions, please feel free to visit our website at http://www.logitech.com, or reply to this e-mail.

If you need assistance with logging into your account, please click on this link: http://logitech-en- amr.custhelp.com/app/answers/detail/a_id/17111.

Thank you for choosing Logitech.


He incorrectly states that the XInput switch is for use with the XBox 360. However, the gamepad is not an XBox 360 gamepad. He also states that I can use XInput if I have "an Xbox driver". But he gives no instructions and no download link. I replied back with links to Logitech's website stating that the controller does work with Windows in XInput mode and that I need a link to the driver. After only nine hours, I get a reply:


From: Logitech Support
Received: 1/21/2013 3:30AM
Message: Thank you for contacting Logitech Customer Care again and I do apologize for the confusion.

XInput is the preinstalled, modern gamepad standard on Windows 7 and Vista. It can also be installed on Windows XP (SP1 or greater).
Use XInput to play games in Windows whenever possible. This input mode is intended to make the gamepad work natively with modern games.
If you're playing a new game with the F310 gamepad, we suggest you set the Input Mode switch to "X". If you want to customize the input functionality, try using DirectInput mode instead.

Thank you for choosing Logitech!


Now, he correctly states that I should be using the XInput mode, but still doesn't give me a driver link or instructions. He also talks about Windows Vista and XP, despite my having told him twice before that I am using Windows 7. I reply with my system specs again and ask him for the required driver. This time, I get a reply back in a little over 4 days:


From: Logitech Support
Received: 1/27/2013 10:42AM
Message: Thank you for contacting Logitech Customer Care again and we appreciate your reply.

You may need to contact your computer manufacturer and they should provide you the native driver prior to make the gamepad work.

Thank you for choosing Logitech!They want me to contact my computer manufacturer for support with their gamepad! Imagine what would happen if you called Dell/HP/Lenovo and asked for a driver for a gamepad they don't sell or support. They would send you right back to Logitech. In my case, I had built my computer myself and I sent that information back to Logitech.

At this point, I should add that Logitech closes the support ticket if they don't receive a reply from you within a week.

The next email I received from Logitech came 8 days after my last reply:


From: Logitech Support
Received: 2/5/2013 4:59PM
Message: How's everything going?

I just wanted to update you regarding this incident, because you will be receiving an automated email stating that this will be closed.
If I may ask, is there anything else I can help you with? If your issue has not been resolved, please do not hesitate to update me.
Please respond first before completing the survey so that I can offer further assistance to resolve this matter.
I'm looking forward to your update. Have a wonderful day!

If you have any additional questions, please feel free to visit our website at http://www.logitech.com or reply to this e-mail.
For reference purposes this is your support reference number: 130111-003764.
Thank you for choosing Logitech.


First, this email does not address anything I had written in my previous email and it still does not address the problem I was having. Second, because it took them over a week to respond, a few hours after receiving this email, I received a second automated one stating that the support ticket was now closed.

In the period of a month, Logitech completely failed to address the problem I was having, offered no usable advice, and eventually closed the ticket because of their own inability to respond in a timely matter. This is no way to run support and I will definitely take this experience into account the next time I'm looking at purchasing a Logitech product.

Recording a (data) Blu-ray from the command line

In this post, I'll show you how to build an iso image, burn it to a Blu-ray disc, and verify that the burn was successful. These steps are for creating a data Blu-ray. Authoring a movie is a whole different subject, however if you already have the movie files created, then you can use these steps for the burn.

Nothing here is specific to Blu-ray, so these steps will work equally well with a CD or DVD, but I encountered a bug in K3B that prevents a successful burn using Blu-ray discs.

But first, let me warn you about the bug that I encountered in K3B, the GUI burner that comes with OpenSUSE. In 12.2 (and at least back to 11.3), K3B will not complete a burn.  The (closed) bug report is here: https://bugzilla.novell.com/show_bug.cgi?id=656502. Basically, with around 100MB of data left to burn, K3B will report an "input/output error" and stop. Some suggestions for working around this problem include using BD-RE (rewritable) discs instead of BD-R discs, which I didn't try. Also suggested was using the original branch of the cdrtools and using the "create image" options, neither of which worked for me. I did get the burn to work via the command line, which is why there is this post.

Back to the burning. To create a burnable image:

1. I did use the original branch of the cdrtools. I don't know if this is necessary or not, but I was convinced from what I read about this branch versus the one that ships with OpenSUSE that it was better just to use this one. First, you'll need to download the source from http://cdrecord.berlios.de/private/cdrecord.html. I used version 3.01a11. Untar it, and then do a:

make && sudo make install

You'll need to have make and gcc installed, of course. The binaries are installed in /opt/schily/bin.

2. Create the image. Say you have the files you want to burn in /home/user/disc/. Then, from /home/user, you would:

/opt/schily/bin/mkisofs -J -r -iso-level 3 -allow-multidot -allow-leading-dots -joliet-long -o IMAGE.iso disc/

 The "-J" and "-r" flags just specify how the file names are stored (specifically using Joliet and Rock Ridge) so that your file names are not mangled. "-iso-level 3" enables support for files over 4GB in size. "-allow-multidot" and "-allow-leading-dots" allow files with multiple dots and leading dots in the filename, such as ".myfile.txt". "-joliet-long" provides Joliet support for longer filenames.

You will need, of course, enough free space on your drive to store an entire copy of the files you wish to burn. It is possible to pipe the output of mkisofs into the burner in the next step, but I prefer to do it in two stages, because you'll need the image in order to perform a MD5sum in order to verify that the burn was successful.

I also found that each time you create the image, the md5sum is different. I'm not sure why this is, but my guess is that the metadata (most likely something time related) changes. So definitely keep the image until you have either written down or verified the MD5sum.

3. Burn the image. Stick a blank disc in the drive and then:

/opt/schily/bin/cdrecord dev=/dev/sr0 -v -pad -data IMAGE.iso

4. Verify the data burned. First of all, this won't work:

md5sum IMAGE.iso
dd if=/dev/sr0 | md5sum

The problem is that when you use dd to read the disc, it will invariably read some blank bytes past the end of your data resulting in a completely different MD5sum.
The easiest way to verify the data is like this:

dd if=/dev/sr0 | cmp IMAGE.iso

If this ends with:

cmp: EOF on IMAGE.iso

then it was successful. The EOF means that the end of the image file was reached without finding a difference between the two. Everything else on the disc is just padding.

The only problem here is that you will presumably delete the image at this point and if later, you want to verify that the disc is still intact (say, you want to verify that a backup disc is still in good shape six months from now), you need a way to calculate the MD5sum from the disc. You could do so with:

md5sum IMAGE.iso
dd if=/dev/sr0 bs=1 count=IMAGE_SIZE | md5sum

where image_size is just the number of bytes of the image ("ls -al IMAGE.iso" will work). However, this will take a very long time (several hours) to complete since it's reading the bytes off of the disc one at a time. You can speed this up significantly by reading the bytes off in powers of 2. As long as the size of your image file is divisible by two, you're set; I believe that all images will always be divisible by 2048 bytes. In my case, my image had a size of 16,378,150,912 bytes, which when divided by 2^14=16384 is 999,643. That left me with a verify command like this:

md5sum IMAGE.iso
dd if=/dev/sr0 bs=16384 count=999643 | md5sum

It takes a little bit of math, but it will finish in 10-20 minutes and not hours later.

Once you have the MD5sum, I suggest writing it on the disc label for later use. In my case, I only write the last four digits (out of laziness), but the chances of a disc with an error generating the same last four digits in an MD5sum is 1 in 16^4=65,536. That's good enough for me.

Script to record the IP address of your computers

I like to keep a simple script on all of my machines that routinely checks in with a server and records the current IP of the machine. It's great for ssh'ing into a machine that has a constantly changing IP address (like a laptop) and in case of theft, it could help track down the stolen machine.

I like to have the clients check in with a webserver, instead of a machine I own. Basic websites are cheap (like GoDaddy) and have high availability.

There will be three files that this project will use:
-CheckIn.php will be on the server and will record the IP.
-CheckIn.txt will store the IP addresses.
-CheckIn will be on the client. It will use wget to contact the server.

1. Here is CheckIn.php:

<?php
//Begin Setup - Change these variables
$filename = "CheckIn.txt"; //The name of the text file to save the IP addresses to.
$my_pass = "password"; //The password to see the IP addresses.
$max_lines = 100; //The maximum number of IP addresses to store. 0 for no limit.
//End Setup

if (!function_exists('file_put_contents')) {
    function file_put_contents($filename, $data) {
              $f = @fopen($filename, 'w');
          if (!$f) {
                  return false;
               } else {
                    $bytes = fwrite($f, $data);
                 fclose($f);
          return $bytes;
               }
   }
}

$computer = htmlentities($_GET['user']);
$password = htmlentities($_GET['password']);
$contents = file_get_contents($filename);
if(!$computer){
if($password==$my_pass){
            echo "<table border=1 cellpadding=2 cellspacing=2>";
            echo $contents;
            echo "</table>";
      }
} else {
       $output = "<tr>";
       $output = $output."<td>".$computer."</td>";
     $output = $output."<td>".$_SERVER['REMOTE_ADDR']."</td>";
       $output = $output."<td>".date("ymd H:i D")."</td>";
       $output = $output."<td>".time()."</td>";
        $output = $output."<td>".$_SERVER['HTTP_REFERER']."</td>";
      $output = $output."<td>".$_SERVER['HTTP_USER_AGENT']."</td>";
     $output = $output."</tr>\n".$contents;
        $counter = fopen("Stats", 'w');
     fwrite($counter, $output);
  fclose($counter);
   if($max_lines!=0){
            $array = file($filename);
           for($i=sizeof($array); $i>=$max_lines;$i--){
                     unset($array[$i]);
          }
           $array=array_values($array);
          file_put_contents($filename,implode($array));
       }
}

?>

This code should work on all machines running PHP v4.3 and later. Change the filename, password, and max_lines at the beginning of the file to the values you want to use.

2. CheckIn.txt is an empty file to start with:

touch CheckIn.txt

3. Upload Checkin.php and Checkin.txt to your webserver. Setup the permissions so that Checkin.php is accessible, but Checkin.txt is not:

chmod 644 CheckIn.php
chmod 600 CheckIn.txt

4a. Add an entry to CheckIn.txt whenever there is a new Internet connection. This only works if you are using NetworkManager. As root, create the file /etc/NetworkManager/dispatcher.d/CheckIn:

#!/bin/sh

if [ "$2" = "up" ]; then
   wget http://URL_TO_CHECKIN.PHP?user=COMPUTER -O /dev/null > /dev/null 2> /dev/null
fi

and make it executable:

chmod +x /etc/NetworkManager/dispatcher.d/CheckIn

4b. Add an entry to CheckIn.txt every 10 minutes. Either as a regular user, or as root, create a crontab:

export EDITOR=`which pico`
crontab -e

The choice of editor is completely up to you. Put the following in your crontab:

*/10 * * * * sh /root/script.sh > /dev/null 2> /dev/null

where the "*/10" indicates that the command should be run every 10 minutes. Wikipedia has an great page on the format of crontabs.

Finally, check to make sure that the crontab was installed correctly:

crontab -l

The case against Swap

Swap, that extra partition you keep around in case you run out of memory, is actually, in most situations, a bad thing to have. Here's why.

Why swap was a good thing.

1. Hard drives and RAM memory used to have similar speeds. RAM was faster, but not by so much that it meant the system was unusable if it was run off of the hard drive instead. When this is the case, it makes sense to use the hard drive as a backup, but slower memory.

2. Applications tended to fill the RAM. Imagine you have a system with 16MB of memory. You have a word processor that uses 12MB and an image editor that uses 12MB. To have both open simultaneously, you need to have an extra 8MB of storage somewhere. It makes sense to use the hard drive. This way, you can keep the entire word processor in memory when you're using it and when you switch to the image editor, the system can swap the word processor to disk and bring the image editor back to RAM. You'll experience a word processor and image editor that both run at full speed and the only slowdown you'll see is when you switch applications.



Why swap is (now) a bad thing.

1. RAM memory is now so much faster than the hard disk that the system is unusable if it runs off of the hard drive. Maybe this will change again someday as SSD's pickup speed, but for now, it's better to have an application crash or fail to open rather than have an almost frozen and completely unusable system.

2. In most cases, no single application consumes a majority of the RAM. Today, a large application might consume 15%-20% of the available RAM on your system. This makes it unlikely that you'll need to have one application's memory on disk while the other one is in RAM. Running out of RAM today is more likely due to having far too many applications open. The solution is not to mask it by swapping to disk, but rather to either change user behavior (keep fewer applications open) or install more RAM.

3. If the machine starts to thrash (i.e., access the swap continuously), it can be rough on a hard drive, especially if you're using a SSD, where the number of writes is limited.



Why not having swap is a good thing.

It can stop bugs. I had a buggy version of Adobe Acrobat that after you "closed" it, it would remain open in the background and slowly consume memory. After a couple of hours, all of the RAM would be gone and it would start in on the swap. After a couple of more hours, the system would be thrashing the disk and completely unusable. Without swap, after Acrobat used up all of the RAM, it would request more, the request would fail, and it would crash (and close). Of course, it would have been better if Adobe had produced a bug-free version of Acrobat, but consider in this case not having swap prevented my system from being brought down due to a buggy application.



Why not having swap could be a bad thing.

If you have a particular use case that requires you to use more memory than you have RAM, then you will need to have swap. But let me suggest that instead of permanently keeping around a swap partition, use a swap file instead and only activate it when you know you're going to be needing it.


My conclusions.

I think for most users, swap is an outdated concept and causes more trouble than its worth. And your applications probably don't require as much memory as you think. A couple of real-world examples:

I have an old P4 system with 384MB of RAM and no swap that's been running fine for word processing and Internet use for years. It has OpenSUSE 11.1 on it with XFCE.

I also have a laptop with 512MB of RAM and no swap, running OpenSUSE 11.1 with KDE 3.5. I use it for word processing, web surfing, watching Hulu and YouTube videos. I even use a TV tuner card to record shows. I used this machine to write a 100 page technical manual filled with graphics (both vector and bitmapped). Again, I've had no problems due to the lack of swap.

Absolutely silent wget

I had an application where I wanted to use wget to request a file from an http server, but I wanted absolutely no output. No status, no errors, nothing to the console and nothing written to the disk. This is for a laptop "anti-theft" script I'm working on. Everytime an Internet connection is established, the local script calls a PHP script on my webserver, which records the IP address it was called from. As a result, I get a nice list of IP addresses where my laptop has been. However, I don't want the disk filling up with a bunch of HTML files, as is the standard practice for wget. The solution is this:

wget http://URL -O /dev/null > /dev/null 2>&1

The "-O" directs the HTML file to /dev/null, then ">" directs the standard output to /dev/null, and then "2>&1" directs the standard error to the standard output which goes to /dev/null. As a result, this is an absolutely silent (even if its fails) wget.

One quick word of warning, the "2>&1" does not work in the sh shell. So, in your script files, instead of:

#!/bin/sh

you'll need to use another shell (like bash):

#!/bin/bash

or, not use that fancy redirect at all and use "2> /dev/null" instead.