Finally I found that using a resolution of 640x360 would result in a nice widescreen video on Flickr.
This was captured from a Canon HV20 HD camcorder with a wireless mic and loaded into Linux using dvgrab. Editing was done in Cinelerra and the final resize and conversion for upload to Flickr was done with ffmpeg.
Ever since upgrading to Jaunty I've been hating the fact that I made the switch. Early on I had overall video performance problems but shortly after the initial release of Jaunty an update fixed those.
Yet still I had horrible full-screen video performance from Macromedia Flash - especially on sites like Hulu.
Well today I found the solution. It seems that the power-saving "ondemand" features in Jaunty was never coming out of power save mode to handle the increased CPU usage of full screen Flash video. Simply adding the "CPU Frequency Scaling Monitor" to the taskbar and setting the CPU to "Performance" - or manually setting it at a higher speed - solved the issue.
As you may have guessed from yesterday's post, I've just finished a complete reinstall of our PBX system. The old system was running on Mandrake (yeah, Mandrake NOT Mandriva) and had done a great job. Unfortunately we were having a phone port lock up periodically that would require rebooting the server.
Since another "event" left me with a spare motherboard and rack mounted case I went ahead and ordered a Digium PCI-Express analog card to handle our four phone lines.
I've configured four Asterisk servers before and expected things to go smoothly. My first problem was that my last server was a version 1.2 and the newer version of Asterisk made several config file changes, causing very strange problems in my dialplan.
The next problem was that no matter what, caller-id service almost never reported the incoming number. After banging my head against the wall over and over trying to get the Ubuntu Hardy Asterisk packages to work with various configs, I finally took a stab in the dark and downloaded the latest zaptel sources from Digium and compiled them. A quick reboot and all the incoming caller-id worked beautifully.
I love open source software so much that nearly our entire enterprise is running on it. Our internally developed software is all either written for LAMP, or some recently in Mono.
I fully understand that open source projects will sometimes become inactive, in fact I have a few I've developed myself that have fallen by the wayside yet at one time had great potential.
What I don't understand is when a commercially backed open-source solution like Openfire from Ignite Realtime has a known issue for years that goes unresolved and requires a simple workaround. Then again, who here hasn't heard of Internet Explorer?
Integrating the Openfire instant messaging system with an Asterisk phone server is relatively easy, but when you first attempt to connect it to the Asterisk server, it just does nothing. It turns out the setup script for the Asterisk-IM plugin is wrong... and has been since 2007.
I will say though, I still love Openfire with it's LDAP directory integration and my (now working) Asterisk phone system integration. The ability to know the phone status of any user by glancing at my contact list is such a small thing, but it really does make a difference.
I had a hard time using the following line in my fstab until I finally realized the problem:
//winserver/incoming /home/outgoing cifs uid=me,credentials=/etc/smbpassfile,noauto,user 0 0
The mount would fail, and my DMESG would report:
[2492180.882826] CIFS VFS: No username specified [2492180.882857] CIFS VFS: cifs_mount failed w/return code = -22
Doing a mount passing the username and password directly would work just fine. Turns out I was missing the following package:
sudo apt-get install smbfs
Take a guess what OS this is running in:
If you guess Ubuntu 8.10 64 bit with no emulators, you'd be correct! That's a screenshot from Regnum Online, a free to play MMORPG that just happens to offer a Linux client. I took that screenshot from a cliff overlooking the battle before I stupidly jumped into the fray and swiftly died.
Here I am shooting my wimpy magic missile at the beast just before he killed me in one blow:
Regnum has been around for just over two years. It's not quite as in depth or polished as some of the games out there like Knights Online or Silkroad, but it's certainly an enjoyable game. They also have announced that they will be releasing a new upgraded version with better graphics and dynamic shadows in the very near future and that they do plan to continue to support Linux.
Kudos to them - they just go to show that there's no technical reason you can't develop awesome games for Linux. It's mostly political (and market driven,) but we knew that already.
I've been banging my head against the wall over an error reported in some PHP code I've been writing. For some reason the session would be trashed on the server and on next page load I'd get "Node no longer exists" when I tried to open the session.
It turns out that you can't take a response from a SimpleXML object and store it in a session. You'd think that if you could type "echo $myxml->thisnode" and get a string that it's really a string, but PHP automatically typecasts and converts as needed - except in the case of storing in a session variable.
There's an easy solution. Use explicit typecasting when trying to store an XML result string in a $_SESSION variable:
$_SESSION['myinteger'] = (int)$myxml->myinteger; $_SESSION['mystring'] = (string)$myxml->mystring;
I was just setting up a new install of two Ubuntu servers with a TB mirrored between them in realtime using DRBD. It occurred to me while I was configuring DRBD that the default settings are way too slow for current hardware.
For instance, if you're going to set up a high-availability cluster no doubt you're going to have a minimum of a Gigabit network connection between the servers and at least use SATA 300 hard drives - probably in a RAID array to get even more throughput.
The default sync speed in DRBD is only 10 Megabytes / second. It's in your best interests, especially on the initial sync, to increase this considerably. At initial setup time you can safely configure this to be as high as your hardware will allow. Check out this article that describes how to go about calculating it.
For instance, initially my setup used 22 MB as the sync speed, but for the initial sync of 1 TB across a Gigabit crossover using SATA 300 drives was going to take almost 10 hours to complete. My hardware config actually lets me push this as high as 68 MB / second, reducing my initial sync time to about 3 3/4 hours, and that's on two systems with no RAID - simply a 1 TB hard drive synced over a crossover cable.
An update to my Hardy LTS desktop caused my nVidia drivers to puke again, and for some reason they refused to reinstall. It's all related to having installed this system first as a Gutsy install, and using the nVidia drivers downloaded from their website. Every time there was a kernel upgrade I'd have problems, and it started getting worse with package file conflicts recently.
My hard drive had also gotten a bit small for me, so I decided maybe it was time to go ahead with a fresh install of Jaunty (which I'd downloaded just before the drivers went wacko) and take the opportunity to throw in a new hard drive.
On my first install attempts the Jaunty CD would simply drop to a BusyBox console prompt and never install, without giving any indication of what the problem was. I did a bit of googling and found that this could be caused by a crappy SATA control chipset on the motherboard. I then wasted the next hour attempting to update my BIOS without Windows, a floppy drive or a USB stick. I finally was able to run the BIOS update by placing it on a CF-II camera card and using that. Unfortunately there was no improvement.
I've always been a PHP guy, but recently I had a little Python web scraper utility I wrote that I wanted a nice interface to, and I didn't feel like writing a complete GTK interface for it, or rewriting it in PHP with CURL.
So, I thought, "Hey, there's these people that run Python on their servers instead of PHP, why don't I try that! It shouldn't be any harder than running PHP, right?"
Wrong. It's not hard, but it brings back memories of my first attempt to get Perl scripts to work properly with Apache.
First, you need to install "libapache2-mod-wsgi". This is the module for Apache that lets you run Python scripts from inside your web server. I know, why doesn't it have the word "Python" in the name? Don't worry - just make sure you don't actually try to use the module that DOES have Python in the name. It's the old and outdated way of doing things.
So, use Synaptic to install the module, or at a console enter:
sudo apt-get install libapache2-mod-wsgi