Based on my yesterday experimentations, I’ve code today a little script to automate the backup of several websites of mine. This script use lftp to mirror file from a remote host to your local machine. Then it create a bzip2 archive.
You can download the script here. To make it working, you need python on your system. To configure it, edit the ftpsite_list python list in the begining of the file.
Today I’ve found that my websites were not backed up as expected. I was using fmirror (v0.8.4) to get a copy from my host provider to my backup machine. Here is the command line I was using:
fmirror -kRS -u kevin -p pass -s ftp.website.com -r /html -l /mnt/removable/website_backup/current
But fmirror seems to not care about sub-directories starting from a given depth. One source of the problem could be strange file names (spaces, utf8 chars, etc).
Because I don’t had the time to investigate further, I was looking for an alternative. So I tried wget (v1.10) with the following command:
wget -r -nH -N --cut-dirs=1 -l0 -np --cache=off ftp://kevin:pass@ftp.website.com:21/html -o ../backup.log
This work perfectly on small websites. But on my biggest one (hundreds of MB), wget hang up with the following error:
*** glibc detected *** double free or corruption (top): 0x08097750 ***
It seems to be a known limitation of wget: “Wget has got serious problems retrieving huge sites” (source: “Possible Alternatives to WGET”).
So I went back to basics by using the good old lftp, which is efficient and reliable. Here is the command:
lftp -c 'open -e "mirror -e . ./ " ftp://kevin:pass@ftp.website.com:21/html'
I updated the baghira rpm with the 24/02/2006 CVS version. This version correct a very annoying bug I had with the previous RPM. Now Kpdf doesn’t freeze anymore.
I also added newer version of qemu and kqemu v0.7.2 I found on P.Terjan repository and Amarok 1.4beta2 from the gkmweb.com repository.
I’ve build a RPM package of Rugg for Mandriva 2006. I also added a source-rpm repository for Mandriva 2006.0 on this site.
Rugg describe itself as a “Flexible file system and hard drive crash testing”. Take a look on the official project website for details: Rugg Project website.
Hi all !
I’ve created a RPM repository on this site to deposit third-party software I found all around the net. At that time, available packages are Wormux v0.7 and Baghira v0.7.
To add the repository to your urpmi database, in a terminal, do as root:
urpmi.addmedia kev-repository http://kevin.deldycke.com/static/repository/mandriva/2006.0/i586 with hdlist.cz
Today I tried to transcode a bunch of videos using my favorite script. I need to do this because the videos produced with my cheap camera use Mjpeg as video codec and raw-data as audio codec. This result of incredible large files. To share my videos with friends, I transcode them to mpeg4/mp3 files. This is all the dirty work my script is supposed to handle.
Unfortunately I didn’t use it since I upgraded Mandriva from 2005 to the 2006 release. As you can guess, it wasn’t working: mencoder gave me the following “Audio LAVC, couldn’t find encoder for codec mp3″ error message. First, I though it was because of a bad version of ffmpeg. Looking at the source RPM from PLF repository gave me the proof that my version was compiled with the right options.
To bypass this problems, I used the -mp3lame as output audio codec. This introduced horrible A/V sync. 
For 3 hours, I tried to play with mencoder options without success. I was completetly desesperated… until I tried VLC. In less than 10 minutes I was able to get the expected result: perfect A/V sync movie file !
Thanks to the VLC wiki, I also discovered the h264 video codec, which is a good codec for low bitrates. Even if it produce bigger files compared to my older method (the latter can be found in the first version of the script), the quality is very awesome and video artefacts (ringings and blockings) are so reduced that it’s now very hard to distinguish. So I decided to use h264 in the new version of my script.
There is still an inconvenient of using VLC instead of mencoder: VLC is transcoded at real time ! I tried the “hurry-up” parameters without effects. This is sad but acceptable, since my goal is to archive my tiny videos.
To summarize, here is the command line I use to do transcoding via VLC:
vlc --sout-all "input_video.avi" :sout='#transcode{vcodec=h264, acodec=mp3, ab=32,channels=1, audio-sync}:std{access=file, mux=mp4, url="output_video.mp4"}' vlc:quit -I dummy
This command is far from perfect and I plan to dig into VLC help to tune h264 codec.
