[joebrady]

Problem: Go to Videos -> TV Shows -> etc. Then suspend, and resume. Entering videos will take you to where you where prior to suspend

Solution: Consider hibernate and suspend the same as shutting down xbmc, clear history stacks.

[jmarshall]

Do other apps forget about everything you when you suspend/resume?

[Memphiz]

-1 thats not what suspend suggests.

[sho]

If I suspend my PC, I would prefer it to resume in exactly the same state as it was when suspended.
Why would a media center behave differently?

[davilla]

Returning to where you left is one thing but the result would also need to take account of changing device or net shares. ie. someone could suspend, yank a disk, then resume. Or we suspend, then net share goes away, we come back up.

These conditions need handling and I suspect the simple way to handle them is pretend you are shutting down xbmc, clear history stacks.

Also add to that list hdmi devices, they could be removed or added during the suspend.

So it's not a simple thing to just resume where you left, we would need to consider all the possible fault cases and handle them.

[jmarshall]

You get the same faults if you go from Videos -> Home, yank network -> back to Videos. So IMO those cases are broader than just suspend/resume.

[davilla]

yep, we have lots of basic problem areas

[topfs2]

-1 thats not what suspend suggests.

If I suspend my PC, I would prefer it to resume in exactly the same state as it was when suspended.
Why would a media center behave differently?

Technically speaking I agree with you, this is how laptops and such devices behave. But IMO this is somewhat different.

If you close the lid on your laptop, it does make quite a bit of sense to leave the apps opened and as they where. However, with htpc's, atleast I but I suspect many, use it completely via the remote control. And using the red shutdown button on the remote to shutdown/start the device. The technical fact that its suspending, hibernating or shutdown is not really of interest, the intent is the same the only difference is speed (and in some cases the devices can't but turned on from hibernation or completely shutdown).

So I guess we could potentially break this out into the following 3 use cases:
1) User presses power button on remote and turns it back on in a few minutes or hours
2) User presses power button on remote and turns it back on the next day, week or month
3) User turns of TV but forgets to turn of the HTPC, it idles and suspends.

In 1 and 3 I completely agree it should pause, and pick up from where it was last. In 2, it might be valid to actually clear the stacks

One potential solution could be to reinvent it and steal some ideas from gnome 3:
In settings you choose what your power action should be, either "shutdown" or "pause". Then when we press the red button, xbmc will determine the best course of action to achieve this goal. I.e. "suspend" if pause is selected and suspend but clear stacks if "shutdown" is selected. So we decouple the technical aspect and the intent more.
Obviously we really need to have an easy way to choose this temporary and not redo the gnome 3 problem with only suspending unless you press some random button (alt).

Perhaps by having a "default shutdown action" in settings and in shutdown menu there are more options.
So remove all notion of "shutdown", "hibernate", "suspend" and "exit" and simply have "shutdown" and "pause" of some sorts. If --standalone we control the device power state also and without --standalone we don't control the state (behave as just an app).

Ideas?

Cheers,
Tobias

P.S. I agree we need to consider the network, hdmi devices and any other device (headphones or removable drives) which may have been added and removed during the suspend. But these should probably be another thread?

[Memphiz]

Yeah for this we would need a different thread - maybe some sort of plug&play manager which gets notified if any cable or device is removed or added .

[topfs2]

I meant a thread on forum, not in xbmc. Just realized how ambigous my statement was :O

Anywho, I have thought a bit more about this subject and I guess it kindof comes down to that we don't really pick a strategy and is decisive with this in the interaction throughout the app.
For example: In settings we have "Scan library on startup", which we do on both startup and resume. So if we deem the problem in this thread as being ok and the correct behaviour in the suspend/hibernate case we really ought to remove the scanning from suspend resume.

I think in the end having one "pause" and one "turn off" is probably the best interaction, and we simply decouple these from what power state the machine is in.

On pause we store all history, which window we are in and don't do a scan on return. When we "turn off" we scrap the history, scrap the window we are in and do a scan on turn on. We could pause with suspend, hibernate, exit or shutdown and we can turn off with all the same powerstates.

Does this sound like a better interaction?