Getting MPlayer to stop stuttering

I recently found a website that plays, for free, the French In Action videos used in my college French courses.  In combination with this other website which plays the audio exercises #1-26 #27-52 from the same series (also for free), it’s an excellent way to learn French.  However, the catch on the audio site seems to be that you have to install Internet Explorer and possibly Windows Media Player – yes, this can be done in GNU/Linux, but that’s another tutorial for another day – and they’re not free software so I avoid them anyway.

Unfortunately, MPlayer stopped and started so badly on my other half’s openSUSE 11.1 system that the videos were impossible to watch.  I don’t remember MPlayer ever being so problematic this way in the past, so I assume something new somewhere has gummed up the works.  Here’s what I did to get it to behave.  Videos take a little longer to start playing because of the extra buffering, but the stuttering is gone.

First, even though setting it to use ALSA audio has worked fine in the past, it doesn’t seem to in this case.  Open MPlayer, right-click in the playback window, and select Preferences from the context menu.

MPlayer preferences

MPlayer preferences

Next, click OK on the little reminder that pops up.  On the Audio tab, select “oss  OSS/ioctl audio output.”

MPlayer oss audio

MPlayer oss audio

Continue reading

Advertisements

Recovering from a system boot issue related to UNetbootin

Incorrectly configuring UNetbootin can lead to system boot issues, such as not being able to boot to your original desktop any more. One way this can happen is by selecting the Show all drives option. There is a popup dialog in UNetbootin warning you about the boot issues this option could cause:

UNetbootin - Show all drives option

UNetbootin - Show all drives option

If you ignore this warning for whatever reason, things can get sticky.  I did it during one of my first attempts to install UNetbootin to a separate, dedicated ISO partition.  Here is my test setup.   The following two commands can be used to verify your own configuration.  My hard drive is /dev/sda , so if yours is different, such as /dev/hda, adjust your commands accordingly.  (The -l is a lower-case L.)

g33kgrrl@home ~ $ sudo fdisk -l /dev/sda

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device     Boot   Start   End     Blocks    Id  System
/dev/sda1   *        1    1200    9638968+  83  Linux
/dev/sda2         1201    1735    4297387+  82  Linux swap / Solaris
/dev/sda3         1736    9437   61866315   83  Linux
/dev/sda4         9438    9729    2345490   83  Linux
g33kgrrl@home ~ $ df -h
Filesystem   Size  Used  Avail  Use%  Mounted on
/dev/sda1    9.2G  2.1G  6.6G   25%   /
/dev/sda3     59G   13G   46G   21%   /home
/dev/sda4    2.3G  1.4G   29M   99%   /mnt/iso

g33kgrrl@home ~ $

Continue reading

Recovering from crashes

Crashing, otherwise known as locking up or freezing, is a well-known and all-too-frequent phenomenon in the Windows world.  With Linux systems, on the other hand, it is not uncommon for servers and other always-on systems to go for months without needing a single reboot.  I’ve used Linux for roughly… oh around 9 years now, and Windows since the days of 3.x in the early 90’s, and can tell you from experience that Linux crashes are few and far between… especially when compared to the rate of Windows crashes.  That said, it can happen from time to time, and it’s better that you know how to recover from them.  Just powering off while everything’s running is not good for any operating system, Windows or otherwise, and may damage your data, so it’s best to avoid it if you can and try to get everything to shut down in an orderly manner.  Here are some ways to do it.

Track it down and kill it!

If a certain program has locked up but the computer is still functional, meaning you can still move the mouse, select menu items, etc., and it’s not practical or desirable to reboot the machine, then killing the program will do the trick.  (You may feel like killing it if you just typed up a long document without saving and it has locked up, potentially losing all your work, but that’s not what I’m talking about.)  You can open a terminal window (also known as Console, shell, or command prompt) and type in:
ps -ef | less
(If you haven’t seen that vertical bar  |  before it’s called a “pipe,” often found on the backslash \ key.  It looks like two little vertical lines, one stacked on top of the other, but when you type it it’s one solid line.) This will give you a long list of processes that the computer is currently running.   Here’s a little snippet of my listing as an example:
lisa 5861 1 14 Dec23 ? 01:41:47 /usr/lib/firefox/firefox
lisa 9522 5861 2 Dec23 ? 00:07:03 /usr/lib/nspluginwrapper/i386/li
lisa 11147 5510 0 00:27 ? 00:00:02 gnome-terminal
lisa 11149 11147 0 00:27 ? 00:00:00 gnome-pty-helper
lisa 11150 11147 0 00:27 pts/0 00:00:00 bash

You can now use the cursor up or down keys to scroll through your list and look for the name of the misbehaving program.  For the sake of argument, and because it’s what I have running at the moment, let’s say my Firefox has crashed.  The first column is my username, and the second is the process ID (pid for short).  The last column tells me the name of the process (program).  Take note of the pid’s of any processes that bear the name of the program giving you trouble.  In this case I’m looking for anything with firefox in it.  I can see Firefox is running with a pid of 5861, so I hit Q to quit out of the listing and type
kill 5861
Some distributions may complain that you don’t have the right to do this.  If so you will need to do it as the root user (aka administrator).  To do that in Ubuntu and other distributions based on it such as Kubuntu and Mint, add sudo in front of all the commands, as in sudo kill 5861.  It will ask for the root password the first time you do this.  For most other distributions type su and hit enter.  It will ask you for the root password (not your user password, remember) and after that the prompt will end with a # instead of a $, and you can just enter the commands as they appear here. If this fails to close the program, and you took note of more than one pid to kill for this program, repeat the kill command for each remaining pid. If this still doesn’t do it, use the same kill command(s) but with -9 option.  In my case:
kill -9 5861
Granted, the kill -9 option is not the nicest or neatest way to kill a program, which is why it’s a last resort, but it is the silver bullet… if nothing else does it this will.  If it doesn’t, you have probably missed another pid that needs to be killed or you aren’t properly running kill as the root user.

There are shortcuts to this process if you know the name of the program – that is, what you would type in at a terminal to start it up, you can just type pkill followed by the program name.  In this case, I happen to know it’s firefox.  So I can type
pkill firefox
and then
ps -ef | grep firefox
to check if it actually stopped the program and all its processes.  If not, the -9 option above works with pkill too.
pkill -9 firefox
That’s great, you say, but what if my whole system seems to have locked up?

Continue reading