Recent changes seem to have broken opt. When marlin tries to load an mp3,
it goes into an infinite loop and doesn't do anything.

the pipeline is 

filesrc ! mad ! one-to-n ! i2f ! marlinsink

The one-to-n is basically a no-op in my test case though, as its a mono mp3

Attached is a debug log.

Here's some comments from IRC
<BBB> LOG   ^[[00m      scheduler^[[00m(^[[334m16935^[[00m)
          ^[[00mgstoptimalscheduler.c(1020):gst_opt_scheduler_loop_wrapper:^[[0
          0m loop wrapper, putting buffer in bufpen
<BBB> this is the issue
<BBB> it's constantly queueing buffers internally (core)
<BBB> it's reffing until higher than 200
<BBB> which is insane
<BBB> ^iain^: I don't want to be an ass, but is marlinsink loopbased?
<BBB> ^iain^: I'm guessing we broke opt a few days ago... it should basically
          switch the two halves off (i.e., it wraps the loop-thing in a
          thread-sorta-way internally, that's the only way to go afaik)...
<BBB> ^iain^: problem is that it only iterates one half
<BBB> ^iain^: the marlinksink-half is never iterated
<^iain^> hmm ok
<^iain^> should I tell someone?
<BBB> ^iain^: I'd suggest to open a bug report and hope for company/wtay to
          look
<^iain^> ok
<BBB> I can see the bug, but I can't solve it :(
<BBB> I'm not good at schedulers yet
<^iain^> I'll copy this conversation into the log :)
<BBB> good :)
<^iain^> thanks
<BBB> it might be that - since it's oneton - it still needs to be threaded,
          but I don't think so
<BBB> I think we just broke opt slightly :)