GNOME Bugzilla – Bug 708548
If multiple pipeline recovery attempts were done in a short amount of time, show a graphical error and offer reloading
Last modified: 2015-10-20 12:57:38 UTC
Similar in spirit to bug #433537, 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 54dc09f5563c8274c513e4dd3ce6ec53f900affe 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 #708182 (refactoring/rearchitecting the pipeline) If recovery is impossible, we should raise and show errors in a graphical way, like what was done with bug #635874 for the rendering dialog.
From further verifications (asking various people around, testing), it seems that the "set the pipeline state to null, to play, then do an initial seek" approach is the right one to attempt basic recovery. However, one would need to check if multiple recovery attempts were done in a short amount of time and abandon, present the user with an graphical error dialog. Seems like Mathieu is in favor of this approach. Perhaps when this error dialog occurs, we could offer users the possibility to reload the latest saved version/backup of the project?
(In reply to comment #1) > From further verifications (asking various people around, testing), it seems > that the "set the pipeline state to null, to play, then do an initial seek" > approach is the right one to attempt basic recovery. > > However, one would need to check if multiple recovery attempts were done in a > short amount of time and abandon, present the user with an graphical error > dialog. Seems like Mathieu is in favor of this approach. > > Perhaps when this error dialog occurs, we could offer users the possibility to > reload the latest saved version/backup of the project? Indeed I agree with that, that is the right thing to do.
Can you please either close that bug or rename it jeff ?
Turns out that this has already been implemented, although I'm not satisfied with the wording so I would like to provide another commit to improve it on top of: commit e9245a37a51a3f796bd7b7549b4d910c593d6289 Author: Thibault Saunier <tsaunier@gnome.org> Date: Wed Nov 26 14:42:51 2014 +0100 Let the user know when Pitivi is dead We now notice that Pitivi is in an inconsistent state thanks to our watchdog, and the various recovery retries, and if everything fails, we should let the user know that Pitivi is dead, and let him save his project before quitting.
Hi Thibault, I have finally completed my polishing branch for this: https://github.com/nekohayo/pitivi/commits/bug-708548-playback-pipeline-errors-dialog This implementation works better and is nicer for users and I achieved what I wanted with it so I consider it merge-ready, please review. It applies cleanly to master (or even after the gtktimeline branch merge, no conflicts). ----------------------------------------------------------- Independently from my improvements however, from testing by "faking" pipeline failures by adding code like this somewhere in loadProject or newBlankProject: self._pipelineDied(None) # for testing only ...I discover that it is possible for self.current_project not to have a "pipeline" object when you click the "Close Pitivi" button in the pipelineDied dialog, or when you click Save As in that dialog then cancel the "Save as" operation. I think this is unrelated to my changes, but I'm worried that what I'm seeing there is a real/serious bug and not just triggered by my "artificial" pipeline failures? Anyway I'm not sure (and don't really have the time/focus) how to fix that so I'd leave that to you to check.
This bug has been migrated to https://phabricator.freedesktop.org/T3067. Please use the Phabricator interface to report further bugs by creating a task and associating it with Project: Pitivi. See http://wiki.pitivi.org/wiki/Bug_reporting for details.