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 132128 - UI problem, no stop button
UI problem, no stop button
Status: RESOLVED NOTABUG
Product: totem
Classification: Core
Component: general
unspecified
Other Linux
: Normal minor
: ---
Assigned To: Bastien Nocera
Bastien Nocera
: 590460 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-01-21 18:02 UTC by John Leach
Modified: 2009-09-24 20:24 UTC
See Also:
GNOME target: ---
GNOME version: 2.3/2.4



Description John Leach 2004-01-21 18:02:13 UTC
I get really edgy using Totem because it doesn't have a stop button.  My
perception is that it's bad to leave it on pause.  I yearn to press stop. 
I panic when I can't find it.  I guess it comes from years of being told
off by my dad for leaving the tape player on pause and wearing out the motor.

Now I know a enough about computer programming to know there isn't a motor
to burn out, but everytime I want to stop a track my mouse flits between
buttons looking for the stop button.  I realise this may well be classified
as a "user education" issue but there *must* be others who have this
problem, even if it's just cultural.

I'm not sure what the solution to this is.  Another button is just going to
clutter the GUI I guess.

Sorry.
Comment 1 Bastien Nocera 2004-01-21 18:29:51 UTC
There won't be a stop button just because "it feels right to have one".
There aren't any technical reasons why it should be so right now.
If you find any, please reopen this bug.
Comment 2 Philip Withnall 2009-08-03 13:17:56 UTC
*** Bug 590460 has been marked as a duplicate of this bug. ***
Comment 3 Matt 2009-09-18 17:56:57 UTC
- pausing a file does sometimes hold on to the audio device
- pausing a video holds on to the video overlay preventing other apps from using it
- pausing a stream holds the buffer, so that when the stream is played again, the few seconds left in the buffer play, then the player re-buffers to a point much further along
- if you are playing a single file and want to stop it and start from the beginning again later (e.g. watch the first 30 seconds of a film then get interrupted):
  - press pause to halt playback
  - on return (playlist not shown): drag the slider to the beginning
    - alternatively (playlist shown): double-click the track to return to the beginning, track remains paused; click play
  - instead of press stop to halt playback, then play to start from the beginning.
- pausing a track keeps the file handle open (double-clicking the file in the playlist when paused doesn't close the file handle
  - after pausing a file from removable media, it can't be unmounted unless the unmounting app supports sending a message to Totem
  - deleting a file doesn't free disk space
Comment 4 Bastien Nocera 2009-09-22 13:43:12 UTC
(In reply to comment #3)
> - pausing a file does sometimes hold on to the audio device

It doesn't if you use a modern audio sub-system, such as PulseAuydio.

> - pausing a video holds on to the video overlay preventing other apps from
> using it

Only happens with crummy drivers that don't have textured Xv overlays.

> - pausing a stream holds the buffer, so that when the stream is played again,
> the few seconds left in the buffer play, then the player re-buffers to a point
> much further along

Internally, we stop network streams, they're not paused.

> - if you are playing a single file and want to stop it and start from the
> beginning again later (e.g. watch the first 30 seconds of a film then get
> interrupted):
>   - press pause to halt playback
>   - on return (playlist not shown): drag the slider to the beginning
>     - alternatively (playlist shown): double-click the track to return to the
> beginning, track remains paused; click play
>   - instead of press stop to halt playback, then play to start from the
> beginning.

Pause when busy, and either resume with play, or restart from the beginning by pressing the "back" button.

> - pausing a track keeps the file handle open (double-clicking the file in the
> playlist when paused doesn't close the file handle

That's expected, I would even call it a feature.

>   - after pausing a file from removable media, it can't be unmounted unless the
> unmounting app supports sending a message to Totem

Which you would get in a decent desktop system (eg. any app that uses gvfs will tell Totem to remove the file from its playlist before unmounting).

>   - deleting a file doesn't free disk space

That's the same bug/feature as the one keeping the file handle open.
Comment 5 Matt 2009-09-24 20:24:10 UTC
> It doesn't if you use a modern audio sub-system, such as PulseAuydio.

so modern, it doesn't support features like digital audio passthough (http://pulseaudio.org/ticket/167), among other missing features, the poing being that PulseAudio is not capable enough for some hardware.

> Only happens with crummy drivers that don't have textured Xv overlays.

Not really the user's fault.

> Pause when busy, and either resume with play, or restart from the beginning by
pressing the "back" button.

Nope, back button is greyed out with only one track.

> That's expected, I would even call it a feature.

Yes, that's expected of a pause button. A stop button, on the other hand, would close the handle.

> Which you would get in a decent desktop system (eg. any app that uses gvfs will
tell Totem to remove the file from its playlist before unmounting).

No, that's any 'desktop system' (by which I guess you mean an app capable of unmounting drives) that uses GVFS. There's plenty of good software that doesn't, or hasn't been ported yet.

> There won't be a stop button just because "it feels right to have one".
There aren't any technical reasons why it should be so right now.
If you find any, please reopen this bug.

I have given several technical reasons, but I get the feeling from your response that regardless of the merit or any others, the issue has no chance of reconsideration. I suspect there are few people who use only completely technologically up-to-date and tightly Gnome integrated apps on an 'ideal' set of hardware and drivers that works perfectly as a system, and I find it strange to think that only these users should have a chance at a good experience with Totem. At the very least, this could be provided as a gconf option, so that those who fear the feature creep of a stop button (!) are not unduly upset.

What do you say Bastien?