Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#5495 - audio_set_track_changed_event() skips first track in playlist

Attached to Project: Rockbox
Opened by Robert Keevil (obo) - Sunday, 04 June 2006, 19:24 GMT+2
Last edited by Peter D'Hoye (petur) - Sunday, 24 June 2007, 21:21 GMT+2
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Player Type All players
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

The audio_set_track_changed_event() skips the first track in a playlist on SWCODEC devices since the playback code was reworked. A CVS checkout from April 1st works fine.

Attached is a cutdown version of patch 5166 that writes a couple of lines per event (diff file was slightly hand crafted, hopefully will patch cleanly to 1st April CVS).
(application/octet-stream)    changed_event.patch (3.6 KiB) 
 apps/SOURCES     |    1 +
 apps/main.c      |    5 +++++
 apps/tree.c      |    4 ++++
 apps/scrobbler.c |   55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 apps/scrobbler.h |    3 +++
 5 files changed, 68 insertions(+)

This task depends upon

Closed by  Peter D'Hoye (petur)
Sunday, 24 June 2007, 21:21 GMT+2
Reason for closing:  Accepted
Additional comments about closing:  so long, and thanks for all the patch
Comment by Dominik Riebeling (bluebrother) - Saturday, 30 September 2006, 01:16 GMT+2
Are you sure this skipping isn't caused by playlists containing a BOM? A fix for that was commited some time ago. Can you still reproduce this issue?
Comment by Robert Keevil (obo) - Sunday, 01 October 2006, 20:38 GMT+2
The playlists are the on-the-fly ones that rb generates. It seems that the problem is now mostly fixed - audio_set_track_changed_event does the callback for the first track. It doesn't for the first track at boot if resume on startup is enabled, but I'm not sure if it should or not - the only code using this function is a patch of mine (5166).
Comment by mrinferno (mrinferno) - Thursday, 05 October 2006, 21:02 GMT+2
doesn't appear to work when you have resume on startup turned on.

i'm still testing it a bit, but i was able to reproduce the missing first track with the audioscrobbler/last.fm patch (5166).

in fact, even if i restart that first song manually from the beginning, it still doesn't show up in the .scrobbler.log
Comment by Robert Keevil (obo) - Saturday, 18 November 2006, 19:14 GMT+2
Okay, a bit more digging...

Start player with auto-resume enabled - first track is NOT logged.
Create a new playlist - first track is NOT logged.
Stop playback, enter folder with music, and play first track - first track is NOT logged.

Enter folder with music, and play first track, WITHOUT stopping playback beforehand - first track IS logged.

I wasn't picking this up due to the way I use my player.
I can't see why a track_changed_event isn't generated - I don't even know if it's a fault in playback.c or playlist.c (or something else?).
Comment by Tomasz Moń (desowin) - Sunday, 28 January 2007, 19:21 GMT+2
Maybe not too nice patch, but it fixes problem
   scrobbler-first-track.patch (1.7 KiB) 
 apps/playback.c  |   13 ++++++++++++-
 apps/scrobbler.c |    2 +-
 2 files changed, 13 insertions(+), 2 deletions(-)

Comment by Tomasz Moń (desowin) - Monday, 29 January 2007, 10:14 GMT+2
above patch scrobbles only skipped tracks
Comment by Tomasz Moń (desowin) - Sunday, 25 February 2007, 23:20 GMT+2
this patch fixes it, please review
   scrobbler-first-track-fixed.patch (0.7 KiB) 
 apps/playback.c |    5 +++++
 1 file changed, 5 insertions(+)

Comment by Tobias Langhoff (Spug) - Monday, 26 February 2007, 01:08 GMT+2
Doesn't seem to fix the problem here. I'll test more extensively.
Comment by Tomasz Moń (desowin) - Monday, 26 February 2007, 09:22 GMT+2
If first track was skipped or you shutted down playback while listening to first track, it gets logged

Attached patch now fixes when first track was fully played it gets logged

Still, first track doesn't get logged when you started playback from last track in playlist
   scrobbler-first-track-fixed2.patch (1.1 KiB) 
 apps/playback.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

Comment by Tomasz Moń (desowin) - Wednesday, 28 February 2007, 17:07 GMT+2
I can't get first-track-not-logged using my patch now, can anyone else confirm ?
Comment by Peter D'Hoye (petur) - Wednesday, 28 February 2007, 23:57 GMT+2
tried this patch alone but didn't see difference (played on song, pressed stop before the end and did shutdown-> nothing logged)
Comment by Tobias Langhoff (Spug) - Thursday, 01 March 2007, 11:14 GMT+2
That patch seems to have fixed it here! :D I'll use the patched build today and see if I encounter any problems. Thanks a lot.
Comment by Tobias Langhoff (Spug) - Thursday, 01 March 2007, 14:24 GMT+2
The issue does seems resolved! The entire OTF playlist is now logged when I play it all in one go. Thanks so much, Tomasz.

However, I also experience the issue Peter mentions: When stopping playback of a song prematurely, it doesn't seem to be logged, although it should be logged with a status of "skipped" ("S") when less than 50 % of the song has been played. Skipping seems to log the song with "S", as it should, but stopping doesn't, at least as far as I can see so far today. That might not be related to this patch at all, though, unless Peter has any reason to believe otherwise since he mentions it here?
Comment by Robert Keevil (obo) - Thursday, 01 March 2007, 14:56 GMT+2
Stopping/last track is a different issue, see  FS#6213 .
Comment by Tobias Langhoff (Spug) - Thursday, 08 March 2007, 00:13 GMT+2
Okay, after some testing, I've found a new bug caused by this patch. The patch logs the first track correctly, and then it logs the second track correctly as well (meaning that both tracks are given the status "L" for "logged" in /.scrobbler.log). When submitting (I use the RockScrobbler Perl script), both songs are submitted. However, when checking my AudioScrobbler profile, the second track is always dropped with the following error message: "Some tracks you submitted have not been added to your profile for the following reason: Spam protection triggered: You submitted a track dated earlier than your last submission."

Here's the log I was trying to submit:

#AUDIOSCROBBLER/1.0
#TZ/UNKNOWN
#CLIENT/Rockbox h300 $Revision: 12267 $
Ambo 1000 Years and 1 Day Slow Motion 1 253 L 1173309430
Ambo 1000 Years and 1 Day Vapor 2 220 L 1173309433
Ambo 1000 Years and 1 Day Cocoon 3 279 L 1173309653

I left the third song in so that you can compare all the timestamps. As you can see, it's obviously giving the first song an incorrect timestamp; it's only three seconds before song number two, which is why Last.FM is rejecting it.

Can this be fixed? Thanks a lot for your work, desowin, you're nearly there! :-)
Comment by Tomasz Moń (desowin) - Thursday, 08 March 2007, 06:42 GMT+2
I'll look into it on friday (no much free time now)
Comment by Robert Keevil (obo) - Sunday, 13 May 2007, 16:23 GMT+2
The attached patch seems to solves this for me - please test!

Combined with the patch on  FS#6213  this should solve all scrobbler issues on SWCODEC targets.
   20070513-scrobbler.patch (0.4 KiB) 
 apps/playback.c |    3 +++
 1 file changed, 3 insertions(+)

Comment by Tomasz Moń (desowin) - Sunday, 13 May 2007, 17:00 GMT+2
Above patch seems to fix it completly

Loading...