In my previous posts, I reviewed the Logitech F710 gamepad and I commented on the lousy support I received from Logitech. While I recommended the gamepad before, I can no longer do so. Originally, when I tested the gamepad, I did so with the gamepad only a couple of feet from the computer. However, I'm using this gamepad to play games on my HTPC which means that the signal has to travel about 8 feet from the front of the computer to my couch. I've had tons of intermittent signal drops. When this happens, the controller is unresponsive and then the mode light blinks when the gamepad gets signal again. 8 feet and line-of-sight should be no problem, but it is.
I've tried all of the normal things, like checking the batteries and trying it on other computers, but the fact is that the wireless range on this controller is pathetic.
Considering that I found two-and-a-half year old forum posts on Logitech's website describing the same problem, this seems to be a design flaw that Logitech doesn't seem interested in fixing. Normally, I'd contact support, but as you saw in my previous post, you can't expect much help there either.
The point is that if you want a good gaming controller, I would suggest you steer clear of Logitech's offerings and see what Microsoft or Razer have available.
Monday, February 18, 2013
Saturday, February 16, 2013
The Logitech F710 Gamepad
UPDATE (2/18): See my new post on the wireless range.
This is part one of a two part post. This part focuses on the gamepad itself, while part 2 is a look at the absolutely terrible customer service I received from Logitech.
Once upon a time, I bought a Logitech Cordless Rumblepad 2.
It was great. I liked the button layout, the feel in my hands, the weight, everything. It used DirectInput at the driver level and it worked well in both Windows and Linux.
And then Microsoft started pushing a new input method, XInput, which was incompatible with DirectInput and they started selling the XBox 360 Controller for Windows. Many newer games only support XInput. Logitech could have extended support for XInput games to the Rumblepad 2 through a driver update, but they decided to release a new series of gamepads instead. The flagship of this new series is the F710.
Look familiar? It should. It's the Rumblepad 2 all over again. The only real difference is that there is now a physical switch on the back that changes it from DirectInput to XInput mode. So, I bought one and it, as the Rumblepad before, worked perfectly in Linux.
Windows was another story.
I'm running Windows 7 Ultimate 64-bit with Service Pack 1 installed. That is the absolute "best" version of Windows you can have right now for gaming. Everything should be compatible with it. And I use this computer for gaming and gaming only, so the firewall is shut off and there is no anti-virus software. In other words, I've done everything I can to make sure that this computer is as compatible with everything as it can be.
So I plug in my F710, install the drivers off of the included CD and I find that when the switch on the controller is set to XInput, Windows can't find the driver to make it work. So, I check the manual and it says that when set to XInput, the drivers will be installed automatically.
Just to verify, I tried playing Batman: Arkham Asylum, which according to Logitech's own compatibility page, should work in XInput mode. Nope, nothing. I finally managed to make it work by force installing the XBox 360 controller driver. To do so, tell Windows you want to install a driver from off your hard drive, then ask it for a list of all drivers, select all drivers, select Microsoft as the manufacturer and then "XBox 360 Controller" is one of the last entries in the hardware list.
In the middle of the process of figuring this out, I emailed Logitech's customer service to see if they could help. That exchange is the focus of my next post.
In the end, I'm glad I got this controller and it is awesome. But it shouldn't have been so much work to make it work.
UPDATE (2/18): See my new post on the wireless range.
This is part one of a two part post. This part focuses on the gamepad itself, while part 2 is a look at the absolutely terrible customer service I received from Logitech.
Once upon a time, I bought a Logitech Cordless Rumblepad 2.
Look familiar? It should. It's the Rumblepad 2 all over again. The only real difference is that there is now a physical switch on the back that changes it from DirectInput to XInput mode. So, I bought one and it, as the Rumblepad before, worked perfectly in Linux.
Windows was another story.
I'm running Windows 7 Ultimate 64-bit with Service Pack 1 installed. That is the absolute "best" version of Windows you can have right now for gaming. Everything should be compatible with it. And I use this computer for gaming and gaming only, so the firewall is shut off and there is no anti-virus software. In other words, I've done everything I can to make sure that this computer is as compatible with everything as it can be.
So I plug in my F710, install the drivers off of the included CD and I find that when the switch on the controller is set to XInput, Windows can't find the driver to make it work. So, I check the manual and it says that when set to XInput, the drivers will be installed automatically.
Just to verify, I tried playing Batman: Arkham Asylum, which according to Logitech's own compatibility page, should work in XInput mode. Nope, nothing. I finally managed to make it work by force installing the XBox 360 controller driver. To do so, tell Windows you want to install a driver from off your hard drive, then ask it for a list of all drivers, select all drivers, select Microsoft as the manufacturer and then "XBox 360 Controller" is one of the last entries in the hardware list.
In the middle of the process of figuring this out, I emailed Logitech's customer service to see if they could help. That exchange is the focus of my next post.
In the end, I'm glad I got this controller and it is awesome. But it shouldn't have been so much work to make it work.
UPDATE (2/18): See my new post on the wireless range.
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.
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.
Saturday, February 2, 2013
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:
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:
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:
4. Verify the data burned. First of all, this won't work:
The easiest way to verify the data is like this:
If this ends with:
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:
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:
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.
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.isoThe 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.
dd if=/dev/sr0 | 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.
Subscribe to:
Posts (Atom)