Add to Google Reader or Homepage |
~ pjvenda / blog
$home . blog . photography

08 May 2007

media players, collections and corrupt digital music

Hello everyone,

Sometimes things go wrong and we (me in this case) do not have a clue of where to start looking for the problem to fix it. Sometimes because of lack of time, some other times because of lack of imagination and even some other times because of lack of resources.

About one/two years ago, I had a problem with AmaroK (media player, KDE) which caused it to quickly consume all available resources when rebuilding the music library. Exactly what I mean is that the application ate about all available physical memory within a minute or so and then it kept going until all swap space was also used. At that point, the kernel's OOM (Out Of Memory) procedure kicked in and killed amarok. When amarok would restart, it had the library marked as "unclean" and would itself reinitiate the library rebuild process... over and over again. That happened because of an amarok's bug - a known memory leak when handling .mp4 files. It got fixed and I carried on with my life listening to Iron Maiden over and over again with amarok.

Until recently (maybe four months ago) the issue came back. This time a little different: amarok was not being killed by the OOM but it still ate about 85% of total memory which means the computer became unusable due to continuous swapping. The symptoms were very similar which would indicate a similar cause. I looked at the KDE's buzilla but did not find anything relevant... Eventually, due to practical reasons, I stopped using amarok and stopped listening to music while working and playing, etc until I would find some free time to really dig the problem out.

Today I decided: No more! I will listen to my music!
Strategy: If amarok cannot, surely others can!
After verifying that JuK (another KDE media player) handled .ogg media, I fired it up and started to build my music library, only to see it mimic the amarok problem.
The most trivial test yielded the most important result: *the problem was not on the media player*!

For my next test, I started one of the media players and setup a very small collection. All went well, so either there was something in my collection that consistently crashed the indexing process or it was too big. It could not be too big - I see people with collections of 100GB+ of digital music frequently, so my 20GB could not be problematic!

Then I took my collection and split it into two roughly equal parts and put JuK rebuilding both parts, in turn - one of them crashed JuK and the other did not. *There was some problem somewhere in my digital music library!*
I kept using the bissection algorithm while carefully monitoring the media player's behaviour (to foresee the leak before the computer needed 5 minutes to open a terminal window) and after about six iterations I narrowed the problem in the library to one (well known) band, where I had four albums. By applying the same method again I found the album and the specific music file that was crashing the indexing done by both media players. I re-encoded the whole album again and copied the corrupted (?) file for later analysis.

In conclusion, imagination and creativity are just as important as technical resources and determination to solve even the simplest problems. The crucial test here was probably the simplest I could do - try another media player.

Now go do something else while I listen to "Louder than Hell" once more. After that it is time for "Brave New World". :)

Cheers, PJ.


Rui said...

Even though you found the corrupted file and corrected it, I think that it is still a bug in the media players. Media players should not crash when "incorrect files" are added as "media files". If you still have the file that was causing the crash, you should fill a bug :)

pjvenda said...

I agree!
I kept the broken file: to include my analysis on the bug report (that I still have not filed).

thanks for the comment, though - it is (as always) a good one.

Abra├žos, PJ.

Paula said...

Well written article.