Currently the (video) file state is not saved when one shuts down XBMC. This is unfortunate when you forgot something was eg. paused and you already turned off your TV. This fixes it. With this change we could also consider re-enabling timer shutdown for paused videos (?)
This is certainly wrong: You're calling a job after we've already asked the JobManager to close down.
If you want to do it, do it without the job
@jmarshallnz: Thanks for the comment, I already had a feeling it was wrong. I've changed it, I assume it's ok now?
Don't use new as you've forgotten to delete it again, just use CSaveFileStateJob job(params); job.DoWork();
Next thing to check is what (if anything) the job uses that might be already torn down.
Ah yes, silly c&p error. Fixed it in the last commit. When implementing this I already made sure (as far as possible) that there was eg. nothing that might already be torn down when shutting down.
@jmarshallnz: What do you think about it?
I haven't yet gone through a thorough analysis. Either way, it's post-Eden stuff anyway, right?
Yeah, post-Eden stuff. It's not THAT important ;-)
I think this should be OK (it's done reasonably early in the shutdown phase - in fact, I'd change it so it's the first thing in the shutdown phase), but would like if someone else could look over it.
@arnova: in the meantime, please squash the commits down so it's a little easier for others to review.
Sorry, I completely screwed up the squash (never did it before). I'll try to fix it up.
Squashed & fixed the commit. It's already almost in the beginning of CApp::Stop(). I'm afraid to put it before the CancelJobs() call as it may collide with each other (not sure what will happen if CFileStateJob() is called from 2 threads: CApp & CJobManager).
When is the player stopped?
The player is stopped a few lines below in CApp::Stop(). After looking over the code one more I think we're fine. We would only miss the case we're we stop the player and immediately shutdown as that would abort the FileStateJob(). Although this scenario is rather unlikely, I guess..
I think this should be OK.
@vdrfan you've played with this stuff (db stuff) before - see any potential issues?
Nope, no issues from what i can see but I'd move this to CApplication::StopPlaying() so the file state is saved on all possible shutdown methods (quit/suspend/hibernate). StopPlaying() is called from the PowerManager.
This would require a small re-factor in CApplication::Stop though. It's not yet using the method - just deleting the player.
Good suggestion, I'll have a look
Well, that's not that straightforward since StopPlaying() is also called in other places where saving the file-state would interfere with file-state-save job. I think it would be better to wrap the foreground filestate-saving into a function and call that from both the powermanager & CApp:stop() functions.
What do you think?
Sounds like a plan ;)
Something like this?
Unfortunately I somehow managed to screw GIT in a way this commit can no longer be automatically merged (probably something went wrong with rebase (I'm still "learning" git) :/
I managed to properly rebase & squash the commits into on that can be merged into master.
Any objections against this going to master?
It's fine to go in during the May merge window IMO.
+1 (in case it matters) ;)
changed: Save file state on shutdown/hibernate/sleep (thanks for the …