In my opinion, the greatest limitation of the transcoding feature is its lack of concurrency.  I have over 5000 audio files and most are incompatible with my portable media device.  With modern processors containing upwards of 12 cores, concurrent transcoding could improve performance by an order of magnitude.  Right now, it takes over 24 hours to copy and transcode my music collection with Amarok and only 3 with Gtkpod (which will transcode multiple files concurrently).  I'd much rather use Amarok to manage my media devices.

I'm not familiar with the Amarok source, but here's how I would handle the problem from a generic standpoint:

void copyToDevice(file_list, device) {
  foreach file in file_list {
    if isCompatable(file, device) {
      copyQueue.push(file);
    } else {
      file transcodeQueue.push(file);
    }
  }

  transcodeThreadPool->setMaxThreadCount(getNumberOfCpus());
  foreach file in transcodeQueue {
    transcodeThreadPool->run(new TranscodeThread(file));
  }
}

class TranscodeThread : public Runnable
{
  void run() {
    ffmpeg file output;
    copyQueue.push(output);
  }
}

Sorry for my bad pseudo code.  In the above model, compatible files would begin transferring immediately.  At the same time, incompatible files would begin transcoding and pushed to the back of the queue.  Obviously the queues are thread safe ;)

Reproducible: Always

Steps to Reproduce:
Copy many incompatible files to your media device, watch how many ffmpeg processes are spawned.
Actual Results:  
Media files are transcoded in serial.

Expected Results:  
Media files should be encoded in parallel.

I've posted elsewhere about this, as well as done some testing.  I've determined that it's not possible to use ffmpeg's internal threading capability, that the only good way to do this is to simply launch many ffmpegs.

http://forum.kde.org/viewtopic.php?f=116&t=107234&p=247671&hilit=concurrent#p247671

http://teom.org/blog/kde/a-summer-of-transcoding-for-amarok/
(I'm Dave in the comments section)