After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 583203 - show a progress bar when loading projects or large amounts of clips and don't hardcode a timeout
show a progress bar when loading projects or large amounts of clips and don't...
Status: RESOLVED FIXED
Product: pitivi
Classification: Other
Component: Media library
Git
Other Linux
: Normal enhancement
: 0.14
Assigned To: Jean-François Fortin Tam
Pitivi maintainers
Depends on:
Blocks:
 
 
Reported: 2009-05-19 12:43 UTC by Jean-François Fortin Tam
Modified: 2011-03-22 16:42 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jean-François Fortin Tam 2009-05-19 12:43:20 UTC
When adding a large amount of clips to the timeline, or when loading a project, the GUI will become unresponsive without an indication of what is going on.

We need some form of progress indication. Since we have toolbars at the bottom of the main window and, as such, no statusbar, maybe we could use a temporary progress dialog, along the lines of:

---------------------------------------------
<big>Opening project</big>
   Clips are being loaded onto the timeline.

{///////////    13 of 47 clips loaded      }
---------------------------------------------

This would probably need to be different when manually adding clips to the timeline, or when importing media to the clip library.
Comment 1 Brandon Lewis 2009-12-08 22:16:05 UTC
commit fe933cb37e13f0cf14470df1583d916bcf429892
Author: Brandon Lewis <brandon_lewis@alum.berkeley.edu>
Date:   Tue Dec 8 13:49:26 2009 -0800

    ui/timeline.py: add a gtk.HScale to upper left corner of timeline for zooming
    closes bug 586025
Comment 2 Brandon Lewis 2009-12-08 22:16:43 UTC
ignore the previous comment
Comment 3 Edward Hervey 2009-12-18 07:57:50 UTC
Having such a dialog box would be nice indeed.

The whole project loading could be done from a different thread too, so that the dialogbox stays responsive too.

We could have several phases:

{         parsing project file             }
....
{/           1 of 47 clips loaded          }
...
{///////////    13 of 47 clips loaded      }
...
{//////////// Filling Timeline ////////////}
Comment 4 Jean-François Fortin Tam 2010-01-29 04:12:14 UTC
I have thought of something regarding our hardcoded 10 seconds importing timeout in . Let's replace it with a contextual "Skip" button.

The skip button should appear only after 10 seconds of "trying to import a specific clip", so that it doesn't show up all the time or "blink" due to a bunch of clips being imported. The 10 seconds delay before it appears also serves a more important purpose: it would prevent from "accidentally skipping the wrong clip", because it would disappear if the clip actually processes while the user tries to click.

With this approach, the user would be in control and be able to import very long/large clips, or skip broken ones. Best of both worlds.
Comment 5 Jean-François Fortin Tam 2010-01-29 04:12:53 UTC
Oops, I meant "in pitivi/discoverer.py".
Comment 6 Robert Varnam 2010-02-11 10:02:39 UTC
This would be very helpful. Even with a heavyweight machine, 10 seconds isn't enough time, particularly if the source clips are highly compressed (eg MP4)
Comment 7 Brandon Lewis 2010-02-12 02:21:36 UTC
Actually there is an underlying GStreamer bug in the 'decodebin2' element that is slowing down media discovery, and this can be avoided to some extent by setting the USE_DECODEBIN2 environment variable to 0, i.e.

$ USE_DECODEBIN2=0 pitivi

Unfortunately some users (i.e. Jeff) report problems importing .mp3 audio files when using this work-around.

When this bug is fixed, the timeout will no longer be an issue.
Comment 8 Jean-François Fortin Tam 2010-02-12 04:01:25 UTC
The decodebin bug is actually fixed with the PPA updates and pitivi master git. The original intent of this bug still stands (better progress indication) I guess, and I wonder if the skip button idea would still make sense nonetheless (it puts the user in control, after all).
Comment 9 Jean-François Fortin Tam 2010-12-27 04:18:15 UTC
I implemented this in my "discoverer-progressbar" branch:
https://github.com/nekohayo/pitivi/commits/discoverer-progressbar

Some things to note:
- I killed our "infostub" widget, replaced it by a nice gtk infobar widget.
- By doing so, I refactored/cleaned up the code in a couple of modules... We now do more, with less! It was the only way for me to find my way through the mess :)
- The progressbar is "naïve", it simply calculates the clip number, divided by the total amount of clips being imported.
- The progressbar doesn't show "parsing project files" (that's instantaneous anyway...), nor does it show "populating timeline" (though I guess it would be trivial to implement in a pulsating mode, now).
- I improved the error dialog, it doesn't get on my nerves so much anymore.
- I didn't implement the "Skip" button idea, because I'm lazy and per-clip import performance is good these days.

Smoke testing and batteries included.
Comment 10 Jean-François Fortin Tam 2011-03-22 16:42:29 UTC
commit dce4a4591bcce154ca4176d1f14090bfef387d08
Author: Jean-François Fortin Tam <nekohayo@gmail.com>
Date:   Sun Dec 26 19:52:20 2010 -0500

    Replace the sourcelist busy animation by a progressbar.


And related commits up to fd58be714bc12d4bb2d9a67ff5e17f7f204df346