Merge lp://qastaging/~barcc/repeat-one-song/one-second-issue into lp://qastaging/repeat-one-song/trunk

Proposed by B. Clausius
Status: Merged
Approved by: Eduardo Mucelli Rezende Oliveira
Approved revision: 15
Merged at revision: 16
Proposed branch: lp://qastaging/~barcc/repeat-one-song/one-second-issue
Merge into: lp://qastaging/repeat-one-song/trunk
Diff against target: 122 lines (+43/-25)
1 file modified
__init__.py (+43/-25)
To merge this branch: bzr merge lp://qastaging/~barcc/repeat-one-song/one-second-issue
Reviewer Review Type Date Requested Status
Eduardo Mucelli Rezende Oliveira Approve
B. Clausius (community) Needs Fixing
Review via email: mp+39285@code.qastaging.launchpad.net

Description of the change

This change solves this issues:
 * last second from a song is cut off
 * if the song duration is wrong (too long) the song is not repeated at all
 * the play count is not incremented
Unfortunately this introduces another issue: If a song is playing and the user selects an other song, the plugin gets confused. Somehow in the playing-song-changed signal there should be differentiated between user initiated and end of song.

To post a comment you must log in.
Revision history for this message
Eduardo Mucelli Rezende Oliveira (eduardo-mucelli) wrote :

First of all, thanks for you effort to make this plugin better. My first approach when I started it was to call the do_previous with the same kind of "state machine" you did in the callback method on_song_change. Consequently, the erroneous behavior which happens when the user changes a song by himself happened to me, the same one that you pointed out -- and I totally agree with you about that there should be a way to differentiate its sources.

The last second cut off I guess is not a big deal, but I agree it is a problem. The play count can be fixed using rhythmdb, and I'd not realized until the moment, thanks again.

One awesome thing that the do_previous approach (I guess it) has, is the possibility to fix the crossfader problem reported by another user. I was wondering that last night.

Anyway, I'm really restricted about the time, and I will check everything out to answer your merge proposal.

Thanks B Clausius

14. By B. Clausius

Use the end-of-stream signal to initiate repetition.

15. By B. Clausius

Merge from trunk

Revision history for this message
B. Clausius (barcc) wrote :

I found out, how to connect to the end-of-stream signal. I think this fixes all issues mentioned above.

Revision history for this message
Eduardo Mucelli Rezende Oliveira (eduardo-mucelli) wrote :

You're right, B Clausius. Anyway, over here, the on_gst_player_eos callback is not feeding the method with 4 parameters, but with 3. I defined 0 to the "early" parameter in order to it works. Works like a charm, congratulations.

Revision history for this message
Eduardo Mucelli Rezende Oliveira (eduardo-mucelli) wrote :

Thanks for your efforts. I will change the "early" parameter as I commented and pack it as version 0.0.6.

review: Approve
Revision history for this message
B. Clausius (barcc) wrote :

There is a bug in my code, if the song is the last song in the list, it does not work. To do a "do_previous" there must have been a next song of course. I will look at it.

review: Needs Fixing
16. By B. Clausius

Activate repeat when activating repeat-one to ensure that a next song is available even for the last song in a list.

Revision history for this message
Eduardo Mucelli Rezende Oliveira (eduardo-mucelli) wrote :

Nice workaround.

Revision history for this message
Eduardo Mucelli Rezende Oliveira (eduardo-mucelli) wrote :

I will pack it in the 0.0.6 and generate a Stable version with only the basic function.

review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches