Some validate tests such as validate.http.playback.fast_forward.vorbis_theora_1_ogg are racy and sometimes failing (easier to reproduce with no/few logs enabled).

Here is what happens most of the time (test passing):
- gst_ogg_demux_activate_chain: first chain is activated
- GST_EVENT_SEGMENT is received on sinkpad and gst_ogg_demux_reset_streams() reset the chain
- gst_ogg_demux_activate_chain is called again and the first chain is re-activated
- souphttpsrc is done reading the file and send EOS
- validate sends a seek event which is handled just fine by oggdemux; all good.

And here is what's happening when the test is failing. The first 2 steps are the same:
- gst_ogg_demux_activate_chain: first chain is activated
- GST_EVENT_SEGMENT is received on sinkpad and gst_ogg_demux_reset_streams() reset the chain

But then we reach:
- souphttpsrc is done reading the file and send EOS

This happens BEFORE oggdemux had a chance to re-activate the first chain, so this code path is triggered when handling the EOS from souphttpsrc:

      if (ogg->current_chain == NULL) {
        GST_WARNING_OBJECT (ogg,
            "EOS while trying to retrieve chain, seeking disabled");
        ogg->push_disable_seeking = TRUE;

Then when validate sends the seek event it's not handled as ogg->push_disable_seeking is TRUE.


Should gst_ogg_demux_activate_chain() set push_disable_seeking to FALSE?
That should greatly reduce the risk of hitting the race but it could (I think?) still happen if the seek event is send before the chain has been re-activated.