Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by obo - 2006-06-04
Last edited by petur - 2007-06-24

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

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).

Closed by  petur
2007-06-24 19:21
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

so long, and thanks for all the patch

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?

obo commented on 2006-10-01 18:38

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).

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

obo commented on 2006-11-18 18:14

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?).

Maybe not too nice patch, but it fixes problem

above patch scrobbles only skipped tracks

this patch fixes it, please review

Spug commented on 2007-02-26 00:08

Doesn’t seem to fix the problem here. I’ll test more extensively.

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

I can’t get first-track-not-logged using my patch now, can anyone else confirm ?

petur commented on 2007-02-28 22:57

tried this patch alone but didn’t see difference (played on song, pressed stop before the end and did shutdown→ nothing logged)

Spug commented on 2007-03-01 10:14

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.

Spug commented on 2007-03-01 13:24

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?

obo commented on 2007-03-01 13:56

Stopping/last track is a different issue, see  FS#6213 .

Spug commented on 2007-03-07 23:13

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! :-)

I’ll look into it on friday (no much free time now)

obo commented on 2007-05-13 14:23

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.

Above patch seems to fix it completly

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing