Bug 281618 - dragon no longer remembers its position on restart
Summary: dragon no longer remembers its position on restart
Status: RESOLVED FIXED
Alias: None
Product: dragonplayer
Classification: Applications
Component: general (show other bugs)
Version: 2.0
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-08 12:50 UTC by Darin McBride
Modified: 2012-08-02 13:58 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.9.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Darin McBride 2011-09-08 12:50:42 UTC
Version:           2.0 (using KDE 4.7.0) 
OS:                Linux

When I stop a video part-way, dragon used to remember where I was.  While I still see the position saved in dragonplayerrc, it doesn't seem to use that - it always starts the video from the beginning again.

Reproducible: Always

Steps to Reproduce:
Start video. Go part way. Stop. Exit dragon.  Restart dragon on same video.

Actual Results:  
It starts from the beginning

Expected Results:  
Continued play from where it left off (or a few seconds' overlap)

OS: Linux (x86_64) release 2.6.39-gentoo-r3
Compiler: x86_64-pc-linux-gnu-gcc
Comment 1 Darin McBride 2011-09-29 13:10:01 UTC
This is still there in 4.7.1 - has anyone tried reproducing?
Comment 2 Darin McBride 2012-05-29 16:08:39 UTC
Could a dev at least confirm this bug (or say WORKSFORME)?  I still have this with 4.8.3.  Thanks,
Comment 3 Harald Sitter 2012-05-31 22:30:24 UTC
DOESNOTWORKFORME

dragon tries to do a premature seek() (i.e. it tries to seek before the pipeline is actually playing, which we at Phonon are not quite sure if it should be allowed or not)
Comment 4 Harald Sitter 2012-07-13 02:19:19 UTC
ought to work well in 4.9 again, it's now doing state dependent lazy seek
Comment 5 Darin McBride 2012-08-01 23:44:16 UTC
Sorry - a quick attempt with 4.9.0 does not seem to show this as resolved :-(
Comment 6 Harald Sitter 2012-08-02 12:02:30 UTC
I blame the phonon backend on first instance here then. Please report a bug against the phonon backend you use.


Not that it will change much since I am also maintainer of phonon :P
Comment 7 Darin McBride 2012-08-02 13:30:34 UTC
Actually, I blame whoever renamed this project from "dragonplayer" to "dragon".

Basically, in Gentoo, the package was named dragonplayer prior to 4.9.  In 4.9, it got renamed to just dragon.  And so when I updated, it wasn't updating dragonplayer to dragon, so I was still running the old dragon.  Ugh.  I found that out just a few minutes ago, uninstalled dragonplayer, installed dragon, and now I get this working.  Sorry about that.

When dragon closes, however, a new window (with "nothing" in it - just black with standard KDE framing) is popping up and disappearing quickly.  I have no idea where that's coming from - it was there both with the 4.8 dragon and 4.9 dragon (when using 4.9.0 kdelibs).  I guess I'll have to open another defect for that, as I don't expect that to be dragon (though I guess it could be).
Comment 8 Harald Sitter 2012-08-02 13:58:36 UTC
(In reply to comment #7)
> Actually, I blame whoever renamed this project from "dragonplayer" to
> "dragon".

^^

> Basically, in Gentoo, the package was named dragonplayer prior to 4.9.  In
> 4.9, it got renamed to just dragon.  And so when I updated, it wasn't
> updating dragonplayer to dragon, so I was still running the old dragon. 
> Ugh.  I found that out just a few minutes ago, uninstalled dragonplayer,
> installed dragon, and now I get this working.  Sorry about that.

Fun, I think that may have been a gentoo change though. Might be related to our move from SVN to Git though. *shrug*

> When dragon closes, however, a new window (with "nothing" in it - just black
> with standard KDE framing) is popping up and disappearing quickly.  I have
> no idea where that's coming from - it was there both with the 4.8 dragon and
> 4.9 dragon (when using 4.9.0 kdelibs).  I guess I'll have to open another
> defect for that, as I don't expect that to be dragon (though I guess it
> could be).

That is a known bug in Phonon GStreamer, except we have no clue what causes it. Essentially GStreamer looses the widget it draws the video on and then creates its own one only to be killed a couple of milliseconds later anyway (technically that ought not happen, though, very weird). If you want, feel free to file a bug about that, I don't think we have one yet.