Seems like a host of open source software has a personal grudge against me lately. Multiple packages fail utterly in my presence, usually because some useful, but moderately obscure feature has a glaring bug in it. Examples....
Maybe I should switch to Debian or Gentoo or something...
I am completely re-writing the streamripper software that I posted the other day, and renaming it do to a meat-namespace conflict with another package with the same name. I have renamed to StreamJacker (not to be confused with Stream Jack).
Some neato Python hints, and a .plan follow.
While StreamRipper is nicely integrated with WinAmp, it is really designed for a different purpose that StreamJacker. I started writing StreamJacker in order to learn wxPython, but the app was so useful to me while debugging it, that I have decided to refactor, continue development, and extend the program.
The Problems:
The Solutions:
It is interesting to note that I had a great deal of trouble with the Twisted Matrix code. This may be because I am still somewhat of a novice python programmer, but I am a VERY experienced C++/C/PHP/Assembly/(everything EXCEPT python) developer. It seems to me that in many cases the Objects that I finally ended up using in Twisted Matrix were far too deeply nested with inheritance, and lacked API hooks that would allow one to do semingly obvious tasks (for example, the ShoutCast client had no default connection closing command, or at least no obvious one). Since shoutcast is a well documented protocol (although not by it's authors), I expect this to be fairly easy to hack together. The only concerns I have are integrating the threading with wxPython, but that is the fun part of coding isn't it!?
Looks like the learning a new language task is going exceedingly well. I have written a Shoutcast stream ripper program which allows you to save the internet radio station of your choice to disk. Song filenames are automagically extracted too. StreamRipper is my FIRST python program, compiled it to a Windows executable (via via wxPython and py2exe, and tested it. It is still a little flaky on closing, and leaves a dos window open with all my debug output, but it DOES WORK.
download here.
I have been pretty lax lately about a policy that I have carried for a long time, but have recently found that I am not the only one.
For this reason, I have decided it is time to get off my ass and learn wxPython. That's right... not just Python but the wxWindow library for it. That way I can code for Windows, Linux, and OSX at the same time. Call me a M$ whore for GUI coding, but I insist on UI standardization.
Now some of the Python geeks (who are third place only after Mac and Perl geeks for rabid fanboyism), are going to come to my house and hang me by the dangly bits for saying this, but Python gives me this wierd vibe. I keep feeling like I am coding in VB (yuck), but with that wierd whitespace as a syntactic element thing (and I am still pretty uncomfortable with THAT too).
Every once in a while I find myself coding with:
if i>7 theninstead of
if i>7:
Otherwise, the exception handling and functional elements make me goo myself, and (unlike java) we have a runtime that JUST WORKS. Java always seems to have problems finding pieces of itself, and isn't always installed on everybody's Linux workstation. Python JUST WORKS.
Ah well. I'll let you know how it goes.
Looks like RedHat has done it again. Way back in the day I got pretty pissed off at RedHat for their release of 7.0 with tons of beta software in it. Upgrades always seemed to go badly for this version, and things didn't get any better until about 7.2 (and 7.3 is still my benchmark version). Because of 7.0 I decided to never install a RedHat X.0 release.
8.0 came and went and then RedHat went to a new numbering scheme, leaving RedHat 9 (no dot) as the obvious 8.1 release.
So I do my upgrade after waiting a few weeks to see if any showstopper bugs appeared, and then changed my sources, and ran apt-get dist-upgrade.....
The upgrade itself went SUPER-SMOOTH, but the subsequent reboot did not. The boot process hanged itself while mounting fstab entries. A reboot on a recovery CD revealed no obvious errors in the boot log, just that everything stopped while mounting.
I removed all unnecessary entries and tried again, and the boot went as normal.
The problem?
RedHat 9 (or more specifically their 2.4.20 kernel) will not correctly mount SMB filesystems because of a race condition in RedHat's version of GLIBC. SMB Mount commands hang indefinitely (although you can manually ctrl-c out of command line called ones and still ahve a successful mount). There is no current fix, although going back to the 2.4.18 kernel is a viable work-around. I have been able to get the 2.4.18 kernel to correctly mount high speed USB2.0 drives as well, which is the only real reason to run 2.4.20 anyways as far as I am concerned. Also, custom kernels don't seem to have the same problem.
Recommendation? Stay away from RedHat 9, or run the 2.4.18 kernel from RedHat 8.0 in the meantime.
One of the things that always bothered me about the shoutcast server was the fact that you had to stuff it in the rc.local in order to get it to start up. In order to fix that, I wrote a script for SYSV daemon startup for shoutcast. This script is optimized for Red Hat Linux (tested on 7.2 - 9.0) and can be made permanent with chkconfig as follows:
cd /etc/rc.d/init.d/;chkconfig --add shoutcast;chkconfig --level 3 shoutcast;chkconfig shoutcast on
Rantradio.com has been running this script since late november, and reliability has been GRRRRRRRRRRRRR8!
Feel free to either download the script here, or continue reading and copy and paste it.
#!/bin/bash
#
# chkconfig: 345 91 35
# description: Starts and stops sc_serv.
# You know, the mp3 streaming thang.
#
# Version 1.3 (nov 4 2001)
# Now with more revisions! System now checks for pid file before cat
# to display so that we receive no error messages. System also displays
# pids as we are killing old processes. Profanity was removed from the
# startup messages. Tests for a pid file before reporting success. Displays
# the relay server name when we start the daemon up, so that we know
# which servers are getting booted. Pushed the success marker over to the
# right and added [] because I am just a slave to fashion.
#
# Version 1.2 (nov 3 2001)
# Same exact shit, but runs as nobody for security reasons. Just
# in case we are worried about buffer overflows or whatnot.
#
# Version 1.1 (nov 3 2001)
# Starts stops and restarts jobs. Also checks for existing daemons
# before calling a start, and exits without starting new ones. This
# prevents you from being a dumbass and starting multiple listeners
# on the same port. I would suggest using the restart command
# in these cases. Also creates a shoutcast.pid file that can be used
# to discover all of the (many) pids used by shoutcast when running.
#
# Version 1.0 (nov 3 2001)
# Starts and stops successfully.
# Kills old jobs on start command. Dirty, but
# does the job well enough. Tested functional on
# mandrake version 8.1 but should work on redhat
# or any other distro that supports a standard
# sysv startup script.
#
# Instructions for use.
# 1: untargzip shoutcast into the directory of your choosing
# 2: copy sc_serv into the /usr/sbin directory
# 3: Create the directory /etc/shoutcast
# 4: copy the shoutcast.conf file into your /etc/shoutcast dir.
# 5: Edit the shoutcast.conf file to match your needs.
# 6: Make as many more conf files as needed to support
# multiple streams. Be sure to edit these files so that
# you are not starting multiple shoutcast servers that
# are either listening or broadcasting on the same port.
# 7: Copy this file into the /etc/rc.d/init.d directory
# 8: chmod this file +x (chmod ug+x /etc/rc.d/init.d/shoutcast)
# 9: run chkconfig --add shoutcast from the /etc/rc.d/init.d dir.
# 10:Run /etc/rc.d/init.d/shoutcast start
# 11:Drink a beer, or light one up, and enjoy the tunes.
#
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is up. This line may cause an error on incompatible
# distributions. Remove it if necessary. Also remove if the startup always
# fails for no apparent reason.
[[ ${NETWORKING} = "no" ]] && exit 0
stop (){
#First we want to kill the original servers, so we don't get errors.
echo "Killing old shoutcast servers."
for oldpid in `ps -A | grep sc_serv | cut -c 0-6`; do
kill -9 $oldpid
if [[ $1 == "-v" ]]
then
echo $oldpid
fi
done
rm -f /var/run/shoutcast.pid
}
start (){
#Now we can start the servers up.
if [[ $1 == "-v" ]]
then
echo "Starting up the new shoutcast servers. Starting..."
fi
servcount=`expr 0`
for cfile in `ls /etc/shoutcast`; do
echo -n $cfile
echo -n " -> "
grep ^RelayServer /etc/shoutcast/$cfile
# This is the line where we actually run the shoutcast program!
#sudo -u nobody /usr/bin/sc_serv /etc/shoutcast/$cfile > /dev/null &
/usr/bin/sc_serv /etc/shoutcast/$cfile > /dev/null &
let servcount=servcount+1
done
#Create the pid file...
ps -A | grep sc_serv | cut -c 0-6 > /var/run/shoutcast.pid
#Done now!
echo "Started $servcount servers."
}
case "$1" in
start)
if [[ ! -e /var/run/shoutcast.pid ]]
then
start $2
if [[ -e /var/run/shoutcast.pid ]]
then
echo "Startup [SUCCESS]"
fi
else
if [[ $2 == "-v" ]]
then
echo "Shoutcast is already running these processes:"
#Toldja! Checks before displaying pid file.
if [[ -e /var/run/shoutcast.pid ]]
then
cat /var/run/shoutcast.pid
fi
echo "Try calling shoutcast restart in order to kill old processes."
else
echo "SC_SERV is already running. Try calling shoutcast restart."
fi
echo "Startup [FAILED]"
fi
;;
restart)
stop $2
if [[ $2 == "-v" ]]
then
echo "Waiting for the old servers to die..."
fi
sleep 4
start $2
if [[ -e /var/run/shoutcast.pid ]]
then
echo "Startup [SUCCESS]"
fi
;;
stop)
if [[ -e /var/run/shoutcast.pid ]];
then
stop $2
echo "Shoutcast shutdown [SUCCESS]"
else
echo "There are no registered shoutcast servers running right now. Attempting to kill anyways."
stop $2
fi
;;
*)
echo "Usage: shoutcast (start|stop|restart) [-v]"
esac
It came to my attention that some steps were missing from the tutorial I wrote up, so I though that I'd finish up here with the next few things to do...
First of all, after you have started with the new kernel, and can see the drive in usbtree, you have to make sure you can reach it as a standard scsi drive. If you have all IDE equipment, it should show up as /dev/sda (check by running /sbin/fdisk -l for a list of partitions and drives). If not, make sure all the appropriate modules are running, by using this command: modprobe scsi_mod ehci-hcd autofs usb-storage usbcore
If you still don't see the drive, try running: /sbin/hotplug usb
If despite all of this the drives don't show, you can actually try to force linux to see it by running fdisk /dev/sda (or whatever the next scsi device would be), and then exiting out.
If all of this fails, then you are on your own. Start here for more technical details.
Just installed the newest version of AVIFile for Linux on my main workstation. Love it. Just tested a bit on the DivX rip of Metropolis using the Xvid codec. Seems to be as quick as on my Windows install. The compile took a while though.
Once upon a time a boy had a tape backup, and it was good.
Then the backup failed, and it was bad. This cycle repeated itself many times, and this was also bad.
Then the boy bought a 200gig USB2.0 Hard Drive, and this was good, after it was bad for a while.
This is the story of his quest...
First of all, only recent versions of the Linux kernel (2.4.19 and newer if I remember correctly) will even support fast transfer rates over USB2.0 for hard drives. If you have an earlier kernel, forget it.
Also forget it if you want to run RedHat 9 with SMB mounts in any reliable fashion. There are also some miscellaneous GLIBC related gotchas in this release. (side note: I think that RedHat 9 is probably the most unreliable release since 7.0, although that is just my opinion).
The first thing you need to do is make sure you are running the newest of the new kernels. Check for 2.4.20-8. FreshRPMs is my favourite place to get the newest stuff. Installing apt-rpm for RedHat is a good idea too.
Once this is done, edit your /etc/modules.conf file and change the line
-> alias usb-controller [something]
to read
-> alias usb-controller ehci-hcd
Now, download usbtree and put it in /sbin or something. Reboot, and run usbtree with your snazzy USB2.0 hard drive attached. You should see something like this:
Congrats. You have a high speed USB drive. If everything is working properly, you should now be able to mount and/or fdisk it just as though it was your next available SCSI device (ie:/dev/sdb (like on my NAS server):
Device Boot Start End Blocks Id System
/dev/sdb1 1 29186 234436513+ 83 Linux
More information in Part 2
References: this site was exceedingly helpful to me.