Making a program automatically restart

Mythbackend crashes a lot, well at least until you get your configuration stable (which has never happened to me). To create a usable system I wanted to configure myth to restart automatically when it crashes. Here's how I did it. First locate the mythbackend binary, mines in /usr/bin (Debian Lenny, debianmultimedia.org install). Rename it to mythbackend.real. Create a file in the same directory called mythbackend.run with the following contents:

#!/bin/bash
myvar=0
while [ $myvar -ne 10 ]
do
    echo $myvar
    mythbackend.real
    myvar=$(( $myvar + 1 ))
done

Make sure it's executable. This script runs our renamed mythbackend ten times in a row (we're only going to restart mythbackend 10times). Then create a file called mythbackend with the following contents:

#!/bin/bash
mythbackend.run&

Again make it executable. This just fires off our mythbackend.run script in the backround. So there you go!

Lazy mans udev fixed device names

One of the constant annoyances of USB devices under Linux is that they don't get assigned fixed names. In my case I have two USB digital TV receiver cards, one for satellite and another of digital terrestrial. They can be accessed though the device directories: /dev/dvb/adapter0 and /dev/dvb/adapter1. However you never know which will be which and in order for MythTV to work correctly they need to fix these. For example adapter0 must always be the DVB-T and 1 the DVB-S. There is a long and complicated explanation of how to modify the udev rules to do something not entirely unlike this here: http://mythtv.org/wiki/index.php/Device_Filenames_and_udev
however, I can't figure out how to get it to work in my case (dvb devices have a more complicated directory structure) so I made this quick hack.

First you need to make sure that udev no longer maps your DVB cards to /dev/dvb/adapter0/1 but rather /dev/dvb/adapter_real0/1. On Debian you can do this by modifying /etc/udev/rules/udev.rules changing the line that reads:

KERNEL=="dvb*",                 PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter%%i/%%s $${K%%%%.*} $${K#*.}", ACTION=="add", \
                                NAME="%c"

to:

KERNEL=="dvb*",                 PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter_real%%i/%%s $${K%%%%.*} $${K#*.}", ACTION=="add", \
                                NAME="%c"

Now create an rc script to assign the fixed device names and place it somewhere in your startup directories. In my case I needed to make it start before mythbackend so I created the file /etc/rc2.d/S23dvbsyms (remember to make it executable) with the following contents:

#dvbs
if [[ `udevinfo -a -p /class/dvb/dvb0.frontend0  | grep UDST702X -c` == "1" ]]
then
  echo "DVBS is adapter 0"
  ln -s /dev/dvb/adapter_real0 /dev/dvb/adapter1
fi

if [[ `udevinfo -a -p /class/dvb/dvb1.frontend0  | grep UDST702X -c` == "1" ]]
then
   echo "DVBS is adapter 1"
   ln -s /dev/dvb/adapter_real1 /dev/dvb/adapter1
fi

#dvbt
if [[ `udevinfo -a -p /class/dvb/dvb0.frontend0  | grep VP7041  -c` == "1" ]]
then
   echo "DVBT is adapter 0"
   ln -s /dev/dvb/adapter_real0 /dev/dvb/adapter0
fi

if [[ `udevinfo -a -p /class/dvb/dvb1.frontend0  | grep VP7041 -c` == "1" ]]
then
   echo "DVBT is adapter 1"
   ln -s /dev/dvb/adapter_real1 /dev/dvb/adapter0
fi

udevinfo -a -p /class/dvb/dvbX.frontend0 dumps a bunch of information about the device, including product codes. I then grep for these and create a symlink to the real device accordingly. You can find the class path to use with udevinfo with:

udevinfo -a -p $(udevinfo -q path -n /dev/video0)

Where /dev/video0 is the device your after in /dev. One you've put these scripts in place the devices will get fixed names as boot. Of course this doesn't help much if you are plugging in and removing devices but it's a hack that works well enough for me.

dvb-usb-vp702x-02.fw

This is the firmware file for a Twinham Starbox 2 USB DVB-S receiver. For some reason it's not on the linuxtv website. It's closed source, and I'm probably not allowed to distribute it. However you'll need it if you want to get a Twinham Starbox working under linux. Here is it: http://www.gamesrant.com/linuxjunk_pics/dvb-usb-vp702x-02.fw

Nvidia TV Out xorg.conf

The following xorg works with my TV. It outputs to the TV ONLY (no dual display stuff):

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 1.0  (buildmeister@builder3)  Wed Jun 13 18:39:30 PDT 2007

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0"
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
EndSection

Section "Files"
    RgbPath         "/usr/X11R6/lib/X11/rgb"
EndSection

Section "Module"
    Load           "dbe"
    Load           "extmod"
    Load           "type1"
    Load           "freetype"
    Load           "glx"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Unknown"
    HorizSync       30.0 - 50.0
    VertRefresh     60
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    Option "TVOutFormat" "Composite"
    Option "TVStandard" "PAL-I"
    Option "ConnectedMonitor" "TV"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
        Modes      "640x480"
    EndSubSection
EndSection

Nvidia driver installation on Debian Lenny 2.6.21-2

Using the Nvidia driver installer you get the error:

   FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'para
   virt_ops'

This basically means Linux people don't like you compiling non-GPL code against the kernel. I guess that's fair I blame Nvidia. Anyway from what I understand it's all being put back so we can install evil code nice an easily in 2.6.22. But for now you need to patch some of the kernel build scripts. Here's a list of instructions for Debian, bastardised from the Redhat version at: http://www.nvnews.net/vbulletin/showthread.php?t=87541:

apt-get source linux-image-2.6.21.2-686
cd linux-2.6-2.6.21/
cd scripts
cd mod
vi modpost.c

# delete the lines reading:
#if (!mod->gpl_compatible)
#   check_for_gpl_usage(exp->export, basename, exp->name);

make mk_elfconfig
make empty.o
cat empty.o | ./mk_elfconfig FORCE > elfconfig.h
gcc modpost.c file2alias.c sumversion.c -o modpost.new
cp modpost.new /usr/src/linux-headers-2.6.21-2-686/scripts/mod/
mv /usr/src/linux-headers-2.6.21-2-686/scripts/mod/modpost /usr/src/linux-headers-2.6.21-2-686/scripts/mod/modpost.old
mv /usr/src/linux-headers-2.6.21-2-686/scripts/mod/modpost.new /usr/src/linux-headers-2.6.21-2-686/scripts/mod/modpost

sh NVIDIA-Linux-x86-100.14.11-pkg1.run --extract-only
cd NVIDIA-Linux-x86-100.14.11-pkg1
cd usr/src/nv
make module
PARAVIRT_OPS=`grep "D paravirt_ops" /boot/System.map-2.6.21-2-686 | colrm 9`
ld -m elf_i386 --defsym paravirt_ops=0x$PARAVIRT_OPS -r -o nvidia.ko nvidia.o nvidia.mod.o
cp nvidia.ko /lib/modules/2.6.21-2-686/kernel/drivers/video/
modprobe nvidia
dpkg-reconfiugre xserver-xorg

You will also need to install the X11 nvidia driver the easiest way to do this is to run the nvidia installer with the "--no-kernel-module" flag ie:

./nvidia-installer --no-kernel-module

Then update your xorg.conf (you can use nvidia-xconfig to do this for you). It appears to be working... but I'm now trying to get it configured to do TV Out...

error: cannot compute sizeof (char) with configure

I received the error "cannot compute sizeof (char)" from a configure script when using the Pathscale compiler. Turned out I was using pathcc (I guess the c compiler) instead of pathCC (I guess C++).

Resuming a crashed scp transfer

Mercilessly robbed from here: http://joen.dk/wordpress/?p=34

scp doesn't have a resume option, so continue the transfer with rsync:

rsync --partial --progress source dest

This isn't encrypted like scp though, in order to do that you need to tell rsync to use ssh as it's shell. The following example uses rsync to transfer a file over ssh with ssh running on a nonstandard port on localhost (like you might setup with a tunnel):

rsync --partial --progress --rsh="ssh -p 2250 " -r  MyDirectory new@localhost:/media/stuff