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

Get correct track position on change events #1534

Merged
merged 3 commits into from Jul 25, 2016

Conversation

edran
Copy link
Contributor

@edran edran commented Jul 24, 2016

Playback callbacks now correctly handle the following cases:

  1. the track finishes and switches to the next one in the list;
  2. user presses next / previous

Fixes #1456 (and therefore should also close mopidy/mopidy-scrobbler#20).

In particular, this allows to send the right information when:

1. the track finishes and switches to the next one in the list;
2. user presses next / previous

The cases of EOS and stop event were already handled properly.

Note: we only have GStreamer's `about-to-finish` event to deal with the
end of a track, which usually happens a few seconds before the end of
the track. We set the position to the length of the track, which is not
overridden unless the user generates a relevant callback.
@edran
Copy link
Contributor Author

edran commented Jul 24, 2016

Err... I think the build broke because of #1523.

(Edit: cc @adamcik )

@@ -251,6 +251,10 @@ def _on_about_to_finish(self):
if self._state == PlaybackState.STOPPED:
return

# Unless overridden by other calls (e.g. next / previous / stop) this
# will be the last position recorded until the track gets reassigned.
self._last_position = self._current_tl_track.track.length
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might still fail if track.length isn't populated, but that's well beyond the scope of this PR as it would require changes in audio and various other places.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm putting a TODO to throw some sort of relevant exception whenever we get around fixing this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to check, wouldn't the backend explode if track.length was None after a about-to-finish event?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If memory serves we can set track length to None to signify a an "unlimited" length such as web streams. So thinking over this again a "bad" backend that doesn't set a length for a track will just look like a stream. And streaming has been working just fine so I don't think there is much we can or should do about this after all.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough.

@adamcik
Copy link
Member

adamcik commented Jul 24, 2016

Flake failure is preexisting due to a newer version of flake8 catching more things that the old one :(

Should _seek reset _last_position as well, that would be an other way to leave early. Or would it still work out by _last_position getting overriden again?

(It's been to long since I've looked at this in detail, so I'm missing a bit more state than I should)

@adamcik adamcik added this to the v2.0.1 - Bug fixes milestone Jul 24, 2016
@adamcik adamcik added C-bug Category: This is a bug A-core Area: Core layer labels Jul 24, 2016
@edran
Copy link
Contributor Author

edran commented Jul 24, 2016

I've tried to debug seek, but the problem appears in such a small time frame that I'm not sure whether it's bugging out because the logic of seek / _seek is buggy.

If I keep seeking after the song I get all sort of unrelated traceback (plus buggy behaviour with ncmpcpp).

@edran
Copy link
Contributor Author

edran commented Jul 24, 2016

I can confirm it works fine if you seek till the end of the track (both in EOS and when switching to a new track in the list).

@adamcik
Copy link
Member

adamcik commented Jul 24, 2016

There were still some rough edges in gapless that could triggered with last minute seeks. I had some notes somewhere about which cases I still had outstanding, this is likely one of them.

@adamcik
Copy link
Member

adamcik commented Jul 24, 2016

So I think this looks good as fix for the specific issue you are targeting. If we want this in a 2.0.x release we should probably cherrypick it into the right branch, or replace this PR with one against the release-2.0 branch instead of develop. Either way is fine by me.

@edran
Copy link
Contributor Author

edran commented Jul 24, 2016

Considering it's critical for mopidy-scrobbler, I suggest whichever makes the fix go upstream faster.

@adamcik adamcik merged commit 5b6632e into mopidy:develop Jul 25, 2016
@edran edran deleted the fix-scrobbling branch July 25, 2016 20:10
adamcik added a commit that referenced this pull request Jul 25, 2016
Get correct track position on change events
@adamcik
Copy link
Member

adamcik commented Jul 25, 2016

Thanks for the contribution, this has been backported to 2.0.x so we can hopefully do a point release with this really soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-core Area: Core layer C-bug Category: This is a bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Scrobbled tracks not saving time_position in track_playback_ended is 0 since 2.0
2 participants