Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Odyssey loses state when closed #113

Open
ildar opened this issue Jan 7, 2018 · 6 comments
Open

Odyssey loses state when closed #113

ildar opened this issue Jan 7, 2018 · 6 comments
Labels

Comments

@ildar
Copy link

ildar commented Jan 7, 2018

That's seen evidently as the tracks in queue are those I listened some time before, not the latest.
This happens at OOM situation which is the part of Android world, sorry.
I think that Odyssey should take extra care of it:

  1. Save state on Pause
  2. and if played for more then 5 or 10 minutes
@djselbeck djselbeck added the bug label Jan 8, 2018
@djselbeck
Copy link
Member

Yes you are right. Actually Odyssey saves it state if you swipe the notification away (in pause state) or after 5 Minutes. The problem is that with the migration to android 8 api we are not running for this long.

We'll fix this

@gnome17
Copy link
Member

gnome17 commented Feb 3, 2018

Hi,
we released a new version that should address your problem. Could you please give us feedback if this release solved your problem?

@dennisguse
Copy link
Contributor

Seems to work (LineageOS 7.1, Odyssey 1.1.11 via Fdroid).

  1. Play
  2. Pause
  3. Go to home screen
  4. Swipe away notification
  5. Open Odyssey
    -> exact position and repeat state is restored

However, on killing the app (force stop via task manager - similar to OOM) does not restore the latest state, but the previous one is restored.

@djselbeck
Copy link
Member

OOM kills are SIGKILL terminations. There is nothing Odyssey can do, thats the definition of kill.

Android usually does not use SIGKILL for termination operations but gracefully terminates services.

also 1.1.11 is not the newest version

@dennisguse
Copy link
Contributor

@djselbeck Sorry, I was expecting Fdroid to be up to date and did not verify it.
My mistake.

@djselbeck
Copy link
Member

They automatically follow the tagged releases on github and then build it from source. Which is nice, because this way applications are guaranteed to match the provided source code.

Today version 1.1.12 landed it f-droid ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants