Bug 281618

Summary:	dragon no longer remembers its position on restart
Product:	[Applications] dragonplayer	Reporter:	Darin McBride <Tanktalus>
Component:	general	Assignee:	Unassigned bugs mailing-list <unassigned-bugs>
Status:	RESOLVED FIXED
Severity:	normal	CC:	sitter
Priority:	NOR
Version:	2.0
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed In:	4.9.0
Sentry Crash Report:

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.