This weekend I learned an unexpected lesson in system admin: what happens when the partition containing my /home/ folder runs out of free space.
While doing a re-installation of my system after hosing my GRUB, I backed up a few GB of documents from a location that was to be wiped out to my home folder. That extra disk consumption, combined with a large file download I initiated after brining my system back online, was enough to fill up the HDD containing the partition where my /home/ folder is located (for ease of re-installation in the event of a problem I mount a second partition to my /home/ folder).
The first thing that happened was I noticed that the file I was downloading suddenly registered a nondescript "error" at about 45% completion. After trying to re-start it a couple of times and having no joy, I decided to restart the system. Bad idea. Upon logging back in, I noticed a lot of screwy behavior: Docky, which I use in place of a bottom panel, would not start and thew a lot of errors when I tried to launch it from the command line, my Compiz settings all reverted to default, Firefox launched upon login despite me not configuring my session as such, and other seemingly unrelated problems.
After a few logouts/restarts did not alleviate any of the problems I had run into, the wheels started turning. I realized quickly what had gone wrong and confirmed in Nautilus that I had in fact run out of space on my /home/ partition. No problem, I thought, I'll free up some space by emptying the Trash. Well, guess what: when the disk is full, it is not possible to do this (I guess GNOME needs some disk space to perform the operation). When I tried to empty the trash I got a progress bar and the message "perparing", but the operation halted without anything actually being removed.
Ultimately, I was able to get out of this pinch by moving a few GB of data from /home/ to / via the command line. Once that space was freed up, I was able to empty the trash, re-arrange a few things, and everything went smoothly from there.
Everything appeared ok until I tried to load up Banshee and play some music. I loaded a playlist and clicked play, and playback halted after the first five items failed to play. I launched from the command line and tried again, at which time Banshee threw the error:
GStreamer resource error: NotFound
A bit of googling suggested that Banshee's DB had become corrupted. This proved to be the case as I was importing some new media at the time I ran out of disk space. This must have happened just as data was being written to banshee.db.
So, as suggested on a few sites, I backed up and deleted the file ~/.config/banshee-1/banshee.db. Sure enough, I was able to re-import my music and successfully play it again.
Unfortunately, playlists did not go so smoothly. Before deleting the original DB I exported each playlist to an M3U file so that I could import them again after re-creating the music DB. I told Banshee to import the playlists and watched as it loaded each one-- with zero songs in each. This was a painful discovery: with about 10,000 songs in my library spread across 15 or so playlists, there was no way in hell I was going to go through re-creating them all. I was determined to find a way to fix this.
Luckily, I found one. When examining the M3U files in gedit, I noticed that for some reason Banshee had not saved the file locations properly. Rather than an absolute path of /home/rick/Music/artist/album/song, the playlist entries were /home/rick/artist/album/song. I have no idea why the /Music folder was completely left out of the file path, but I verified that this is what happened to each and every one of my playlists. A few quick "find and replace" operations later, my playlists were back in order again, and the episode had finally come to an end.
My takeaway from this? Pay attention to disk usage and don't run out of space again!
Now I just need to find out if the Banshee team are aware of the problem I ran into when exporting my playlists...
No comments:
Post a Comment