So at some point something went horribly wrong with my ampache setup. I decided to try the ampache script that renamed files using the tag information. This seemed like a good idea, because my files weren't all named or organized in a consistent way. After a couple attempts, I noticed that all my songs in ampache were by an artist who's name started with the directory path to the file. Great. At the time I was pretty sure I had messed up the mp3 tag data because after rebuilding the catalog in ampache, nothing changed. Artist name was still the directory name (/mnt/usb_mmedia/music/itunes/...). I tried to fix things a couple times but I seemed to make it worse.
Fast forward maybe a year to the past week. I decide it's time to go fix my library. I wanted to start by fixing the MP3 tags, so I downloaded some utils and started to work. But I couldn't find anything wrong with the mp3 tags. The artist was correct here. I also noticed when playing a song through ampache that the artist name seemed to come out correctly there as well. So what the heck is going on?
I start putting print statements in the ampache code to see what it is doing when I verify the catalog. I eventually discover that it is not looking up mp3 tags when building the catalog and instead trying to generate the information from the filename. This is happening because I no longer had an entry in the ampache config file for mp3 tag processing order. I put that back in and everything goes back to normal in Apache.
So why was I missing that config line? It goes back to another problem I had with ampache where catalog verification/creation would hang at some point as the mp3id library would get stuck and chew up memory. This was a known issue with ampache which happened on some files who have corrupted tag information. It was quite hard at the time to identify which files these were and besides, I didn't know how to fix them. The only option was to stop ampache from reading the mp3 tag information by removing the tag order config key. It worked find until I tried to verify the catalog.
This is exactly why I do not like to employ hack work arounds, they always come back to bite you later.
The other stupid thing about all this is that ampache was using a deprecated php method (eregi) and would spit out errors during catalog verification. The response from the ampache devleoper was to downgrade php to an older version or use the alpha version of ampache. Really? What kind of choice is that? Have you ever tried to downgrade something in linux? Remember these systems are a tight-nit web of dependencies. You can't just go around back-revving major packages. I don't know how the stable version of ampache was even going to work on recent distribution releases. I had to replace all the calls in the ampache source code with the proper methods, then everything worked. Thanks open source!
Tuesday, January 31, 2012
Friday, December 30, 2011
Long time, no update again
Well, I am still on Ubuntu 10.10. I plan on using LTS releases only, but even then the support isn't there. Case and point:
https://bugs.launchpad.net/ubuntu/+source/indicator-application/+bug/569273
So, my gnome-power-manager looks like this:
Size: 443168 kB
Rss: 411364 kB
Pss: 411364 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 72 kB
Private_Dirty: 411292 kB
Referenced: 309920 kB
Swap: 31704 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Seems pretty excessive.
This is ridiculous. I would think that the gnome-power-manager is a fairly important piece of the OS here. Why in 18 months hasn't this been fixed in Ubuntu? OSS support sucks. Sure, make the argument that paid software isn't much better, but why would OSS hold itself to that shitty bar? When is Ubuntu going to be a robust complete product? Never. That's how OSS works. Constantly changing and never stable. Even the stable stuff isn't a safe bet because if you find a bug, odds are they've already moved on to a newer, better version with different bugs for you to discover. Nobody fixes bugs on old releases. Not even Ubuntu, even when it's in the support window.
https://bugs.launchpad.net/ubuntu/+source/indicator-application/+bug/569273
So, my gnome-power-manager looks like this:
Size: 443168 kB
Rss: 411364 kB
Pss: 411364 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 72 kB
Private_Dirty: 411292 kB
Referenced: 309920 kB
Swap: 31704 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Seems pretty excessive.
This is ridiculous. I would think that the gnome-power-manager is a fairly important piece of the OS here. Why in 18 months hasn't this been fixed in Ubuntu? OSS support sucks. Sure, make the argument that paid software isn't much better, but why would OSS hold itself to that shitty bar? When is Ubuntu going to be a robust complete product? Never. That's how OSS works. Constantly changing and never stable. Even the stable stuff isn't a safe bet because if you find a bug, odds are they've already moved on to a newer, better version with different bugs for you to discover. Nobody fixes bugs on old releases. Not even Ubuntu, even when it's in the support window.
Friday, March 25, 2011
Ethernet device renaming
At some point during the last five years of upgrades on my laptop, the ethernet port went from being eth0 to being called eth2. I couldn't for the life of me figure out how or why this happened. I also couldn't figure out how to undo it. Well, during my recent pogo issues, I finally ran into some web pages which told me all about it. In a nutshell, it is udev. Here is the file that can be modified to change the device name of your ethernet devices.
/etc/udev/rules.d/70-persistent-net.rules
# PCI device 0x14e4:0x170c (b44)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:15:c5:3c:e6:4d", ATTR{type}=="1", NAME="eth2"
What happened to me was that eth0 and eth1 were assigned to MAC addresses based on my previous laptop. Dell had to replace my laptop and when that happened the new MAC addresses had to be given new names as eth0 and eth1 were already taken from my old laptop.
/etc/udev/rules.d/70-persistent-net.rules
# PCI device 0x14e4:0x170c (b44)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:15:c5:3c:e6:4d", ATTR{type}=="1", NAME="eth2"
What happened to me was that eth0 and eth1 were assigned to MAC addresses based on my previous laptop. Dell had to replace my laptop and when that happened the new MAC addresses had to be given new names as eth0 and eth1 were already taken from my old laptop.
Tuesday, March 15, 2011
Pogo down
Currently battling an issue with my pogoplug. Unfortunately it provides everything like email, home automation, database etc. It seemed two nights ago that it just stopped responding to network traffic. ping worked, but ssh and web were refused. So I power cycled it, but the result was the same. I could hear the disk booting the OS, but this time pings to the machine wouldn't even work. ARP showed that the it hadn't even asked for DHCP (no arp mapping).
Concerned about my HW, I rebooted into the original pogo linux and the network came up fine. I tried an fsck on my root drive and it showed no issues and still no network. I even tried another pogoplug without success. I think either the kernel is corrupt or something is running out of order in the init process such that it hangs before bringing up the network.
This morning I installed a fresh debian onto a usb key and it booted. This evening I will attempt to determine the difference between this fresh install and my broken one.
Update: I have mostly recovered my system. I am still not sure what the issue is. If I kept ping running to that machine while it was booting it would consistently fail, but then come alive for 4-5 pings and then go offline again. The last message I could find in dmesg (when mounting the drive from another machine) was a normal message from the NFS kernel module.
I tried disabling various services in startup to try and narrow it down (including nfs and misterhouse). At one point my system came alive but I went in and restored some of the init and it wouldn't boot to network again. I tried setting my root disk to mount errors=continue instead of errors=remount-ro thinking that it was remounting root ro and making it impossible to write any run time files or update devices. That fix seemed to help, but subsequent boots were hit and miss.
Finally, I commented out all the local usb drives I had in fstab. I just left root and the home dir disk. Magically the system became stable. I have no idea how or why this was causing a problem with the network on boot. None of those disks were network mounted. I guess I'll be reading more on mount and fstab to see if I can explain this. In the meantime my email, home automation, and vbox images are back online.
UPDATE: 3/24/2011
I managed to restore fstab to automount all the usb drives. I had to remove the "auto" fs type to make it work. My pogo now reboots without network issues. I could have sworn that it worked for a while with the auto fs in place, but maybe not.
Concerned about my HW, I rebooted into the original pogo linux and the network came up fine. I tried an fsck on my root drive and it showed no issues and still no network. I even tried another pogoplug without success. I think either the kernel is corrupt or something is running out of order in the init process such that it hangs before bringing up the network.
This morning I installed a fresh debian onto a usb key and it booted. This evening I will attempt to determine the difference between this fresh install and my broken one.
Update: I have mostly recovered my system. I am still not sure what the issue is. If I kept ping running to that machine while it was booting it would consistently fail, but then come alive for 4-5 pings and then go offline again. The last message I could find in dmesg (when mounting the drive from another machine) was a normal message from the NFS kernel module.
I tried disabling various services in startup to try and narrow it down (including nfs and misterhouse). At one point my system came alive but I went in and restored some of the init and it wouldn't boot to network again. I tried setting my root disk to mount errors=continue instead of errors=remount-ro thinking that it was remounting root ro and making it impossible to write any run time files or update devices. That fix seemed to help, but subsequent boots were hit and miss.
Finally, I commented out all the local usb drives I had in fstab. I just left root and the home dir disk. Magically the system became stable. I have no idea how or why this was causing a problem with the network on boot. None of those disks were network mounted. I guess I'll be reading more on mount and fstab to see if I can explain this. In the meantime my email, home automation, and vbox images are back online.
UPDATE: 3/24/2011
I managed to restore fstab to automount all the usb drives. I had to remove the "auto" fs type to make it work. My pogo now reboots without network issues. I could have sworn that it worked for a while with the auto fs in place, but maybe not.
Tuesday, March 8, 2011
No news is good news?
Well, it won't be long lived. Recently I started having memory leak issues in the OS. After about a day, all the memory would be used up leaving an unusable system. It started with a power manager, I can't remember if was the gnome one or not. But after kill -HUP on that process, another process called polkitd would start leaking memory. I have to HUP polkitd once a day now. Some googling showed that there are some instances going back to Lucid (I am on Maverick right now). I can't believe that something as core as polkitd would go this long unfixed. (Apparently polkitd is some sort of policy daemon, security or power I am not sure).
On another thread, I've been having VOIP issues. Whenever Rosalia calls me at work, the line is frequently choppy which usually means UDP packets are getting lost or delayed. I found this great article on how to configure Tomato QOS which finally explained to me how to use Rate and Limit properly.
http://www.linksysinfo.org/forums/showthread.php?t=60304
Rate is actually the min guaranteed bandwidth for a class. So now I make sure my rate percentages all add up to 100%. Calls since this fix appear to be much better, but I still can detect a few dropouts here and there.
On another thread, I've been having VOIP issues. Whenever Rosalia calls me at work, the line is frequently choppy which usually means UDP packets are getting lost or delayed. I found this great article on how to configure Tomato QOS which finally explained to me how to use Rate and Limit properly.
http://www.linksysinfo.org/forums/showthread.php?t=60304
Rate is actually the min guaranteed bandwidth for a class. So now I make sure my rate percentages all add up to 100%. Calls since this fix appear to be much better, but I still can detect a few dropouts here and there.
Monday, December 27, 2010
KDE again
When Ubuntu went to KDE4, I quit. That is I quit being a KDE user. Initially, I found it to be much more interesting than Gnome, but Ubuntu's hasty jump to KDE4 sealed its fate with me. By that time, Gnome was in pretty good shape and I found it to be more stable and more intuitive. I still liked certain KDE apps though, like Amarok (before the screwed it up) so I kept the kde libraries on my system when I converted to Gnome.
Fast forward a couple years. I now use Kmymoney and Digikam. They are great apps and do what I need. At least until I upgraded ubuntu from Lucid to Maverick. Now all my KDE apps suffer from insufferable lag. I first noticed it with Kmymoney. It would take about 3-4 seconds every time I committed a new transaction. Previously it took under a second. Now I am finding that Digikam is pretty much unusable. It takes 5-12 seconds for it to respond to the delete button or clicking on a different photo. Makes it kind of hard to tag and prune any pictures I take. I don't know what's wrong as there isn't much explanation I could find via google. And this comes right at Christmas time when I am taking a ton of pictures.
This is exactly why upgrades scare me. Unfortunately, I am always forced to upgrade to get fixes for other issues. Linux, can't live without can't live with it. I feel more and more that it is not an OS that I can depend on.
Fast forward a couple years. I now use Kmymoney and Digikam. They are great apps and do what I need. At least until I upgraded ubuntu from Lucid to Maverick. Now all my KDE apps suffer from insufferable lag. I first noticed it with Kmymoney. It would take about 3-4 seconds every time I committed a new transaction. Previously it took under a second. Now I am finding that Digikam is pretty much unusable. It takes 5-12 seconds for it to respond to the delete button or clicking on a different photo. Makes it kind of hard to tag and prune any pictures I take. I don't know what's wrong as there isn't much explanation I could find via google. And this comes right at Christmas time when I am taking a ton of pictures.
This is exactly why upgrades scare me. Unfortunately, I am always forced to upgrade to get fixes for other issues. Linux, can't live without can't live with it. I feel more and more that it is not an OS that I can depend on.
Tuesday, November 30, 2010
Ethernet woes
So an old problem has recently revisited me. The b44 kernel module which provides the driver for my broadcom ethernet chip has issues. Mainly it likes to reset under heavy traffic. You wouldn't normally notice except that when using vpnclient it disconnects the VPN connection which is very annoying. I did some searching around previously and found some commentary by the driver maintainer that this resetting behavior was on purpose and they had no plans to change it. So I went to ndiswrapper and after some futzing around I got this to work. So now it doesn't disrupt my vpn session, but apparently it causes the vpn kernel module to sometimes crash and hang parts of my system after I disconnect the vpn :( This is what I call typical linux behavior. I am constantly trading one bug for another. Sometimes it's my choice, sometimes not :)
Now, if I can just figure out how to stop the system from loading b44 at boot. blacklisting it didn't seem to stop it.
Now, if I can just figure out how to stop the system from loading b44 at boot. blacklisting it didn't seem to stop it.
Subscribe to:
Posts (Atom)