Shallow Thoughts : : May

Kdenlive part 2: adding transitions, sounds and titles to your movies

I've been so busy with Libre Graphics Meeting -- a whirlwind of GIMP caucuses, open source graphics, free art and sharing of ideas -- that I forgot to notice that part 2 of my kdenlive article was up on Linux Planet.

Making Movies in Linux with Kdenlive, part 2: Spice up Those Kdenlive Videos.

Tags: writing, linux, video
[ 03:45 May 30, 2010    More writing | permalink to this entry | ]

Kdenlive -- the easy way to make movies

A couple of weeks ago, I shot a lot of short video clips with my digital camera at an indoor fun fly (in the intervals when I wasn't crashing around with the other crazy pilots).

But then ... what to do with a bunch of disconnected video clips? I've uploaded short clips to youtube before, but never extracted the good parts and edited them together. And most video editing programs look pretty complex.

The answer turned out to be kdenlive, which was surprisingly easy to use -- once I got past one initial bug. So I wrote up the details. Part I, covering the basics of how to get started and combine clips, is on Linux Planet: Making Movies in Linux with Kdenlive.

Watch for part II in a couple of weeks, where I'll cover transition effects, music and titles.

Tags: writing, linux, video
[ 19:25 May 13, 2010    More writing | permalink to this entry | ]

The new udev in Lucid

Ubuntu's latest release, 10.04 "Lucid Lynx", really seems remarkably solid. It boots much faster than any Ubuntu of the past three years, and has some other nice improvements too.

But like every release, they made some pointless random undocumented changes that broke stuff. The most frustrating has been getting my front-panel flash card reader to work under Lucid's new udev, so I could read SD cards from my camera and PDA.

The SD card slot shows up as /dev/sdb, but unless there's a card plugged in at boot time, there's no /dev/sdb1 that you can actually mount.

hal vs udisks

Prior to Lucid, the "approved" way of creating sdb1 was to let hald-addons-storage poll every USB device every so often, to see if anyone has plugged in a card and if so, check its partition table and create appropriate devices.

That's a lot of polling -- and in any case, hald isn't standard on Lucid, and even when it's installed, it sometimes runs and sometimes doesn't. (I haven't figured out what controls whether it decides to run). Hal isn't even supposed to be needed on Lucid -- it's supposed to use devicekit (renamed to) udisks for that.

Except I guess they couldn't quite figure out how to get udisks working in time, so they patched things together so that on Gnome systems, hald does the same old polling stuff -- and on non Gnome systems, well, maybe it does and maybe it doesn't. And maybe you can't read your camera cards. Oh well!

udev rules

But on systems prior to Lucid there was another way: make a udev rule to create sdb1 through sdb15 every time. I have an older article on setting up udev rules for multicard readers, but none of my old udev rules worked on Lucid.

After many rounds of udevadm info -a -p /block/sdb and udevadm test /block/sdb, service udev restart, and many reboots, I finally found a rule that worked.

Create a /etc/udev/rules.d/71-multicard-reader.rules file containing the following:

# Create all devices for multicard reader:
KERNEL=="sd[b-g]", SUBSYSTEMS=="usb", ATTRS{idVendor}=="1d6b", ATTRS{idProduct}=="0002", OPTIONS+="all_partitions,last_rule"

Replace the 1d6b and 0002 with the vendor and product of your own device, as determined with udevadm info -a -p /block/sdb ... and don't be tempted to use the vendor and device ID you get from lsusb, because those are different.

What didn't work that used to? String matches. Some of them. For example, this worked:

KERNEL=="sd[b-g]", SUBSYSTEMS=="scsi", ATTRS{model}=="*SD*", NAME{all_partitions}="sdcard"

but these didn't:

KERNEL=="sd[b-g]", SUBSYSTEMS=="scsi", ATTRS{model}=="*SD*Reader*", NAME{all_partitions}="sdcard"
KERNEL=="sd[a-g]", SUBSYSTEMS=="scsi", ATTRS{model}=="USB SD Reader   ", NAME{all_partitions}="cardsd"

Update: The first of those two lines does indeed work now, whereas it didn't when I was testing. It's possible that this has something to do with saving hardware states and needing an extra udevadm trigger, as suggested in Alex's Changes in Ubuntu Lucid to udev.

According to udevadm info, the model is "USB SD Reader " (three spaces at the end). But somehow "*SD*" matches this while "*SD*Reader*" and the exact string do not. Go figure.

Numeric order

I'd like to have this rule run earlier, so it runs before /lib/udev/rules.d/60-persistent-storage.rules and could use OPTIONS+="last_rule" to keep the persistent storage rules from firing (they run a lot of unnecessary external programs for each device). But if I rename the rule from 71-multicard-reader.rules to 59-, it doesn't run at all. Why? Shrug. It's not like udevadm test will tell me.

Other things I love (not) about the new udev

• I love how if you give the udevadm info arguments in the wrong order, -p -a, it means something else and gives an error message.
• I love how udevadm test doesn't actually test the same rules udev will use, so it's completely unrelated to anything.
• I love the complete lack of documentation on things like string matching and how the numeric order is handled.
• I love how you can't match both the device name (a string) and the USB IDs in the same rule, because one is SUBSYSTEMS=="scsi" and the other is SUBSYSTEMS=="usb".
• Finally, I love how there's no longer any way to test udev rules on a running system -- if you want it to actually create new devices, you have to reboot for each new test. service udev restart and udevadm control --reload-rules don't touch existing devices. Gives me that warm feeling like maybe I'm not missing out on the full Windows experience by using Linux.

Tags: linux, ubuntu, kernel, udev, install
[ 21:51 May 09, 2010    More linux/kernel | permalink to this entry | ]

The luxury of understanding the problem

On a Linux list, someone was having trouble with wireless networking, and someone else said he'd had a similar problem and solved it by reinstalling Kubuntu from scratch. Another poster then criticised him for that: "if the answer is reinstall, you might as well downgrade to Windows.", and later added, "if "we should understand a problem, and *then* choose a remedy to match."

As someone who spends quite a lot of time trying to track down root causes of problems so that I can come up with a fix that doesn't involve reinstalling, I thought that was unfair. Here is how I replied on the list (or you can go straight to the mailing list version):

I'm a big fan of understanding the root cause of a problem and solving it on that basis. Because I am, I waste many days chasing down problems that ought to "just work", and probably would "just work" if I gave in and installed a bone stock Ubuntu Gnome desktop with no customizations. Modern Linux distros (except maybe Gentoo) are written with the assumption that you aren't going to change anything -- so reverting to the original (reinstalling) will often fix a problem.

Understanding this stuff *shouldn't* take days of wasted time -- but it does, because none of this crap has decent documentation. With a lot of the underlying processes in Linux -- networking, fonts, sound, external storage -- there are plenty of "Click on the System Settings menu, then click on ... here's a screenshot" howtos, but not much "Then the foo daemon runs the /etc/acpi/bar.sh script, which calls ifconfig with these arguments". Mostly you have to reverse-engineer it by running experiments, or read the source code.

Sometimes I wonder why I bother. It may be sort of obsessive-compulsive disorder, but I guess it's better than washing my hands 'til they bleed, or hoarding 100 cats. At least I end up with a nice customized system and more knowledge about how Linux works. And no cat food expenses.

But don't get on someone's case because he doesn't have days to waste chasing down deep understanding of a system problem. If you're going to get on someone's case, go after the people who write these systems and then don't document how they actually work, so people could debug them.

Tags: linux, tech, documentation
[ 19:37 May 05, 2010    More linux | permalink to this entry | ]