If multiple pipeline recovery attempts were done in a short amount of time, show a graphical error and offer reloading
@jeff
Submitted by Jeff F.T. Assigned to Jeff F.T. @jeff
Description
Similar in spirit to bug T1878, except that pipeline errors "while rendering" are considered fatal and are thus allowed to fail and abort the render, showing an error dialog to the user.
In the case of live playback/seeking/edition, our pipeline should be bulletproof. If something goes tits up in the backend/stack (gst, ges, gnonlin...), we should recover and rebuild de darn thing live if possible.
We supposedly try to do that now, but I haven't had definite proof that it works as intended (with the lockups and erratic/inconsistent state behavior that we can get):
commit 54dc09f5
Author: Mathieu Duponchelle mathieu.duponchelle@epitech.eu
Date: Sun Aug 11 20:07:40 2013 +0200
pipeline: when not in RENDER, the pipeline can and must recover
... from errors.
This probably depends on bug T3055 (refactoring/rearchitecting the pipeline)
If recovery is impossible, we should raise and show errors in a graphical way, like what was done with bug T2687 for the rendering dialog.
Imported from https://bugzilla.gnome.org/show_bug.cgi?id=708548