[gst-devel] media tests

[Ronald S. Bultje]

Hi,

On Mon, 2005-01-03 at 15:56, Thomas Vander Stichele wrote:
> On Mon, 2005-01-03 at 15:43 +0100, Ronald S. Bultje wrote:
> > On Mon, 2005-01-03 at 12:56, Thomas Vander Stichele wrote:
> > > The first is dark.44-16-s.wav, which now stops playing almost
> > > immediately.  It worked fine before.
> > 
> > There is a bugzilla tracker for this, it's a threading bug. I don't know
> > how to fix it (yet). Basically, we EOS as we detect streams, which is
> > not appreciated elsewhere. I'll look for a fix.
> 
> So why did it work before ?

I moved around some code in playbasebin that might be related to this.
Otherwise, I don't think anything was changed. Maybe discont handling in
riff, although it's hard to imagine that being related (it'd be bad if
it was). It's only for very small .wav files, so not a blocker.

> > > The second is multi.ogg, which stops when going from second to third
> > > chain.  It worked fine before as well.
> > 
> > Update core to 0.8.8. This was an opt issue. It's fixed already. If it's
> > not fixed, it's a regression from 0.8.8 to whatever version you're
> > running.
> 
> Good luck - I'm running 0.8.8 :) Any other ideas ?

Tripple check that version 1.104 of gstoptimalscheduler.c was used to
build your currently running version - also make 100% sure that the
installed 0.8.8 RPM of -core is what your plugins are linked against,
and they did not accidently pick up an uninstalled -core or another core
(e.g. because your registry is using uninstalled plugins). If you
already did, tripple check it again. If you're unsure, rebuild your
RPMs, remove your CVS checkouts (or move to a different dir) and re-run
gst-register as root and remove ~/.gst*. I'm absolutely confident that
the 1.104 patch on gstoptimalscheduler.c fixed the exact bug you're
describing. Obviously, I cannot reproduce it. I've checked both 0.8.8
and current CVS (of -core).

Ronald

-- 
Ronald S. Bultje <rbultje at ronald.bitfreak.net>