© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
Thanks for the clarifications, but 'File > Import' is not a work-around (see below).
The (potential) hardware & real software differences between our respective platforms could be responsible for the 'hard or impossible to reproduce' behaviour that you are seeing; as well as the difficulty of reproducing the exact sequence of 'input commands' (see below).
Is there a way to bring this thread to the attention of other devs who have access to at least a Ubuntu 11.10 environment ?
As mentioned earlier, doing a 'File > Import' of the clip, then re-size, then play will reproduce the bug on my machine 'pretty reliably'.
'Exact sequence of input commands':
- a more precise description of how I resize is:
1. File > Import the mp4 clip (length about 11 seconds).
2. drag/drop thumbnail onto the timeline, starting at 0
3. Expand the timeline scale to maximum (1 second).
4. drag the red 'cursor' to the 8 second position (ie mark desired end point of clip)
5. click 'resize' button.
6. scroll timeline right until end of (original) clip is visible
7. drag end of clip to somewhere 'just to the right' of the red cursor (just to the left also results in this issue).
8. click 'rewind to start' button.
9. click 'Play'; allow to play to new end point
10. drag red cursor back/left by 3 seconds
11. repeat steps 9 & 10
Following these steps, I get a lock-up sometimes after the 2nd click of 'Play' (ie 'immediately'), sometimes I have to iterate several times (max seems about 6 so far). Very occasionally I get the Play or Pause button legend 'stuck' on the display and am able to activate the terminal window as the logged in user (rather than having to use Ctrl-Alt-F2 to activate a 2nd console).
SO there is either some other element not described above eg exact mouse pointer trajectory / timing; timing between clicks; location of hover whilst clip playing; exact position of end of re-sized clip etc that is needed to reproduce this issue reliably.... or this 'randomness' is a reflection of the hazard that may be responsible for this bug..