I think it is a codec problem

From reading stuff on the net I came across the idea of deleting the preinst script for libc6.
/var/lib/dpkg/info/libc6.preinst , but it seem a bit a radical so I didn't do it. However the contents was interesting so I'm posting some of the info therein:

      echo "A non-dpkg owned copy of the libc6-i686 package was found."
      echo "It is not safe to upgrade the C library in this situation;"
      echo "please remove that copy of the C library and try again."
      exit 1
    fi
  fi
  if [ -n "$LD_ASSUME_KERNEL" ] ; then
    if dpkg --compare-versions "$LD_ASSUME_KERNEL" le "2.6.1"; then
      echo
      echo "POSIX threads library NPTL requires kernel version 2.6.1"
      echo "or later. It appears that LD_ASSUME_KERNEL is set to $LD_ASSUME_KERNEL."
      echo "It is not safe to upgrade the C library in this situation;"
      echo "Please unset this environment variable and try again."
      exit 1
    fi
  fi

  # glibc kernel version check
  system=`uname -s`
  if [ "$system" = "Linux" ]
  then
      # Test to make sure z < 255, in x.y.z-n form of kernel version
      # Also make sure we don't trip on x.y.zFOO-n form
      kernel_rev=$(uname -r | sed 's/\([0-9]*\.[0-9]*\.\)\([0-9]*\)\(.*\)/\2/')
      if [ "$kernel_rev" -ge 255 ]
      then
          echo "WARNING: Your kernel version indicates a revision number"
          echo "of 255 or greater. Glibc has a number of built in"
          echo "assumptions that this revision number is less than 255."
          echo "If you\'ve built your own kernel, please make sure that any"
          echo "custom version numbers are appended to the upstream"
          echo "kernel number with a dash or some other delimiter."

          exit 1
      fi

      # sanity checking for the appropriate kernel on each architecture.
      realarch=`uname -m`
      kernel_ver=`uname -r`

      # convert "armv4l" and similar to just "arm", and "mips64" and similar
      # to just "mips"
      case $realarch in
        arm*) realarch="arm";;
        mips*) realarch="mips";;
      esac

      # The GNU libc requires a >= 2.6.18 kernel (except on m68k)
      if [ "$realarch" != m68k ]
      then
   # Ubuntu buildd limitation: allow just 2.6.15, although 2.6.18 is required
   # for some patches
          #if linux_compare_versions "$kernel_ver" lt 2.6.18
          if linux_compare_versions "$kernel_ver" lt 2.6.15
          then
              echo WARNING: this version of the GNU libc requires kernel version
              echo 2.6.18 or later. Please upgrade your kernel before installing
              echo glibc.
              kernel26_help

              exit 1
          fi
      fi

      # The GNU libc is now built with --with-kernel= >= 2.4.1 on m68k
      if [ "$realarch" = m68k ]
      then
          if linux_compare_versions "$kernel_ver" lt 2.4.1
          then
              echo WARNING: This version of glibc requires that you be running
              echo kernel version 2.4.1 or later. Earlier kernels contained
              echo bugs that may render the system unusable if a modern version
              echo of glibc is installed.
              kernel26_help

              exit 1
          fi
      fi

      # From glibc 2.6-3 SPARC V8 support is dropped.
      if [ "$realarch" = sparc ]
      then
          # The process could be run using linux32, check for /proc.
          if [ -f /proc/cpuinfo ]
          then
             case "$(sed '/^type/!d;s/^type.*: //g' /proc/cpuinfo)" in
                 sun4u)
                    # UltraSPARC CPU
                    ;;
                 sun4v)
                    # Niagara CPU
                    ;;
                 *)
                    echo "WARNING: This machine has a SPARC V8 or earlier class processor."
                    echo "Debian lenny and later does not support such old hardware"
                    echo "any longer."
                    exit 1
                    ;;
             esac
          fi
      fi
  elif [ $system = "GNU/kFreeBSD" ] ; then
      kernel_ver=`uname -r`
      if kfreebsd_compare_versions "$kernel_ver" lt 6.0
      then
          echo WARNING: This version of glibc uses UMTX_OP_WAIT and UMTX_OP_WAKE
     echo syscalls that are not present in the current running kernel. They
     echo have been added in kFreeBSD 6.0. Your system should still work,
     echo but it is recommended to upgrade to a more recent version.

One more thing Firefox is running slightly better now since I upgrade from 9.04 to 10.04 but I'm sure the reason is because I haven't install the 'missing plugins' that the web browers wants me to install...I assume it is the flash player plugins from adobe.

I tried to uninstall libavformat52 gstreamer0.10-ffmpeg in synaptic package manger, but alas it won't let me. I really need to get thunderbird install so I can do my work...but I can't install anything until this thing gets sort out.

Can someone help me?

I need a hero

libavformat52 & gstreamer0.10-ffmpeg....still wondering how I can fix this package?

please post the contents of the file '/var/lib/dpkg/info/libavformat52.postinst' on the affected system.

Also please run 'sudo sh -x /var/lib/dpkg/info/libavformat52.postinst configure' and post the outputs of that script. This commend reruns the postinst that failed during dpkg.

removing the libc6.preinst is both very dangerous and unrelated to the symptoms described here

Thank-you, Reinhard. I will certainly post the contents as soon as possible. At the moment the computer is at the shop...it seems the hard drive has physical errors. I expect it back this week. I'll be in touch, Tim

TBH, the problem description make a damaged filesystem a very plausible explanation for the symptoms. I guess that you libavformat52.postinst script has been damanged somehow

I talked with the computer shop today, and it seems the hard drive is fine, and as you said it seems to be a damaged file system. I thought the hard drive was the case as it's a dual boot set-up, and the Windows side had also crashed...but it seems it just coincidental. I'm wondering what is the first thing I should do when I get the computer back hopefully tomorrow. So I give you the print out of what you already asked or based on the assumption it's a damaged filesystem another read out? The thing is once I boot up and get into the system I don't think I have long to operate until it freeze.

with this information, I strongly suspect that either the hardware is faulty, or that you experience a rather subtle kernel reliability bug.

in either case, the title of this question "I think it is a codec problem" can be answered with a clear "no".

 Do I open a new question and close this one once it's confirmed it isn't hardware?

Question closed...thanks for your help