utils/pipeline.py has multiple classes that kind of overlap with each other. Among other things, this leads to situations where we're not sure when we must use Seeker or Pipeline or SimplePipeline to do things like async/idle seeks etc. There are quite a lot of errors that don't get handled, we sometimes spam the lower levels with seek requests (ex: when scrubbing with the ruler), etc.

------------
<nekohayo> thiblahute, got a little surprise for you... I coerced luisbg into taking a quick look at how we spam the seeker when scrubbing... two commits were born: https://github.com/nekohayo/pitivi/commits/seeking-fixes
 there is a remaining issue that you could fix though: the Seeker class uses this 80 miliseconds time-based timeout, shouldn't it wait for async_done like what you just did in the pipeline class in commit b5f70a7535e? if our suspicion is correct, you could do that and make it more robust that way

<luisbg> current code works, but waiting based on time isn't ideal, waiting for gstreamer to finish the previous seek is better
<thiblahute> luisbg, We do wait for Gst to finish afterwards
<thiblahute> And seek are already compressed.
<nekohayo> in Seeker?
<thiblahute> In the pipeline
<thiblahute> We should remove the seeker, but I did not want to do it now as it is too invasive

<luisbg> nekohayo, it is what you were saying at the start... why 3 similar classes instead of merging all code to one
<thiblahute> luisbg, https://git.gnome.org/browse/pitivi/commit/?id=b5f70a7535e0a7
<luisbg> thiblahute, yes :) nekohayo showed me
<luisbg> but it is in SimplePipeline, and not in Seeker, which is why we mentioned it would be cool to have it in both... but maybe not worth it if dropping Seeker is a plan
<thiblahute> Right :)