Sleep Timer: Stop at end of track

[asdoi]

Closes #2146
Any suggestions how to integrate a stop after the current track setting into the current sleep timer dialog are very welcome.
Screenshot:

[Matth7878]

What about :

In drop down menu you could add "episode(s)"
Only problem I think is that your commits would need to be able to stop after x episodes or it should force 1 into input when choosing episode.

Edit : my bad, didn't see the big button you put for that. :-/
So I don't understand your question about how to integrate it ? Did you mean any other way than with a big button below "Set sleep time" ? If yes then I maintain my proposal minus your button.

[ByteHamster]

I like the idea of doing this with the drop-down list. That way, the dialog still has a single, prominent button. Using two main buttons feels a bit "too strong" to me (visually).

[asdoi]

Did you mean any other way than with a big button below "Set sleep time"

Exactly what I meant. I do not like this big button and I need a nice and clean replacement for it.

In drop down menu you could add "episode(s)"

This is a good idea, I will try to implement this.

[rubo77]

If you use a checkbox instead the button then you could leave the minutes settings untouched

[Matth7878]

I think using drop down menu is better as you could (or it could be adapted) stop after more than 1 episode. It could be nice when you have really short episode. Besides it keeps UI to the minimum.
Only problem with using drop down is that it might not be clear that stop after 1 episodes mean to stop when X episode ends. So maybe in drop drop down it should be "episodes end" instead of just "episodes")

Checkbox is also working but I feel it odds because it could be confusing with what is put in timer. If you let 2 minutes does it means stop after 2 minutes or end of episode?
To avoid that then the line with drop down menu should be greyed out (or any other solution?) to not confuse user.

[rubo77]

Stop after _1 "played episodes"

also the space for the number doesn't need more than 3 digits

[Matth7878]

@asdoi any news about this PR? It would be nice to have it as it would make sleep timer perfect.

I agree with rubo77 : "played episode(s)" would be better than just episode(s) in drop-down list.

Another thought about sleep timer : is there a need to set a number of seconds? I am also wondering about hours. Who use it? For hours you could always replace it using minutes.
Maybe to clean it up drop drown should just have minutes or played episodes. What's your thoughts @ByteHamster and anyone? Anyways let's keep it out of this PR, eventually I would create an issue about removing seconds and hours.

[keunes]

Thanks @asdoi for all your recent work on AntennaPod! :)

Maybe to clean it up drop drown should just have minutes or played episodes.

I like this. In case values are stored (I guess so), if a user has seconds set, this should be updated to 1 minute; if they have a number of hours set, this should be updated to the corresponding number of minutes.

Then for all the labels, what about:
Stop playback after ____ played [▼minutes|episodes]

Is it at all possible to make the number input field placing flexible, i.e. depending on how long the translation of 'stop playback after' is? Edit: And also; could it's location be determined by a variable in the string? In some languages the number might come before the verb.
If that gets all to complex, just adding "Stop playback after having played:" on a separate line, just below the dialog title would already be great. (That way also 'played' doesn't need to be included in the drop-down.)

[ByteHamster]

is there a need to set a number of seconds? I am also wondering about hours. Who use it?

I use it :) Only for testing during development, though, not for actually listening.

Then for all the labels, what about:
Stop playback after ____ played [▼minutes|episodes]

I think it looks a bit strange to have the text box in the middle of the sentence. This reminds me of a cloze test. Isn't it already clear that the sleep timer stops after the condition is met? I mean, sleep timers are a pretty well known thing. I don't think we need a lot of explanatory text.

[asdoi]

any news about this PR? It would be nice to have it as it would make sleep timer perfect.

Sorry, I was a bit busy.

Anyway while working on this, the following issue came to my mind, which needs to be discussed:

The current sleep timer runs independently from play/pause or any other "user interruption" and simply stops even if no media is playing, but an episode-sleep-timer I think has to handle this differently.
E.g. if the sleep timer has been set to stop after 2 episodes and the user pauses the playback and continues it on the next day, should the sleep timer stop the playback anyway after the second episode has finished or should it just do nothing?
I think if the user forgot that a sleep timer has been set and continues listening after a while, it could be annoying that the playback stops unexpectedly.

[Matth7878]

is there a need to set a number of seconds? I am also wondering about hours. Who use it?
I use it :) Only for testing during development, though, not for actually listening.

With minutes you could enter something like 0.25 and it would mean 15 seconds. Then you could still test it without waiting for a whole minute.
To manage seconds / minutes / hours internally count down is maybe already translated in seconds ?

The current sleep timer runs independently from play/pause or any other "user interruption" and simply stops even if no media is playing, but an episode-sleep-timer I think has to handle this differently.
E.g. if the sleep timer has been set to stop after 2 episodes and the user pauses the playback and continues it on the next day, should the sleep timer stop the playback anyway after the second episode has finished or should it just do nothing?
I think if the user forgot that a sleep timer has been set and continues listening after a while, it could be annoying that the playback stops unexpectedly.

I think that when pausing there should be a timer canceling sleep timer :

• when sleep timer is set with minutes : no problem, count down continue even when paused
• when sleep timer is set with episodes we could :
  -- Option 1 : start a count down, for instance 15 minutes, and if user do not unpause before it ends then cancel sleep timer
  -- Option 2 : no count down, pausing an episode cancel sleep timer

I think option 1 is obviously better but required more implementation. Maybe for this PR option 2 would be better and we could open an issue to implement option 2 later ?

[keunes]

I don't think we need a lot of explanatory text.

Fair enough. Just then we should not add 'played' to episodes, because the same is true for minutes.

if the sleep timer has been set to stop after 2 episodes and the user pauses the playback and continues it on the next day, should the sleep timer stop the playback anyway after the second episode has finished or should it just do nothing?

when sleep timer is set with episodes we could :
-- Option 1 : start a count down, for instance 15 minutes, and if user do not unpause before it ends then cancel sleep timer

I was thinking also of the countdown option - if you are in bed and you pause because your partner is talking and you need to reply, you don't want to loose the sleep timer :P But yeah, if it's too complex for this PR that could be implemented later indeed.

[ByteHamster]

With minutes you could enter something like 0.25 and it would mean 15 seconds.

That's something I don't like. If the "seconds" option is removed, we should be sure that users don't want to enter seconds - and therefore only allow integer numbers. Otherwise, we force users to convert between units, which is usually pretty confusing (base 60 vs base 10)

start a count down, for instance 15 minutes, and if user do not unpause before it ends then cancel sleep timer
[...]
count down continue even when paused

That goes too far for this PR. The playback service that also handles the sleep timer is stopped when pausing the episode (to allow users to swipe away the notification). We would therefore need to rebuild the way that the sleep timer works.

Just then we should not add 'played' to episodes, because the same is true for minutes.

👍

[Matth7878]

With minutes you could enter something like 0.25 and it would mean 15 seconds.

That's something I don't like. If the "seconds" option is removed, we should be sure that users don't want to enter seconds

I think it should be removed : why would you need to set a sleep timer for less than 60 seconds? By the time you dismissed sleep timer dialog and turned off your screen how many seconds will remind? If seconds is either used it is probably to match an episode end and user was already doing something like converting 1 min 30 to 90 seconds. (this PR is going to manage this)

My suggestion was only for you as you had an edge case.
If you allow to enter 0.5 nobody (or only advanced users) would notice it. 🙂

[keunes]

The playback service that also handles the sleep timer is stopped when pausing the episode (to allow users to swipe away the notification). We would therefore need to rebuild the way that the sleep timer works.

Then what happens if we pause?

Option 2: no count down, pausing an episode cancel sleep timer

Or, I think, option 3: pausing pauses the sleep timer, continues after unpause (downside being that if you pause & go to sleep, the next day continues playback won't work if you have enabled this)

[ByteHamster]

Then what happens if we pause?

When pausing, we currently notify the Android system that it may kill the playback service. The sleep timer continues to run until Android actually kills the service. So if you press play again before the service is killed, it just continues normally. If you press play afterwards, the timer is stopped.

I think it depends on the device vendor how much time passes between allowing to kill the service and actually stopping it. On my device, it's 60 seconds. If you have AntennaPod open while paused, the service is not stopped.

[asdoi]

I created a new pull request for this: #4754