Rockbox

Tasklist

FS#8601 - Disk spinup after every single song if dircache is disabled

Attached to Project: Rockbox
Opened by Sascha Wolf (Horscht) - Tuesday, 12 February 2008, 16:35 GMT
Last edited by Nicolas Pennequin (nicolas_p) - Wednesday, 02 April 2008, 17:05 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System SW-codec
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

just today I noticed, that my Ipod 5.5G (80GB) spins up the disk after every song from a playist. Songs are MP3 VBR and are aprox 5MB each. Last.FM log is disabled, as is runtime gathering. I tried the latest SVN (16290) as well (the build i noticed this one was 2 days old). I have only my Ipod to test this on, so I do not know wether or not other HD based players suffer the same issue.
This task depends upon

Closed by  Nicolas Pennequin (nicolas_p)
Wednesday, 02 April 2008, 17:05 GMT
Reason for closing:  Fixed
Additional comments about closing:  r16930
Comment by Ryan Sawhill (ryran) - Wednesday, 13 February 2008, 04:29 GMT
A couple days ago I experienced the same thing (a 2-second disk activity at the beginning of every song) with my 60GB 5g .... I actually even made a video of it with Treo--it kept doing it (through buffer refills and everything) until I stopped and restarted playback. Sadly, I haven't been able to reproduce it. Are you saying that yours does this all the time now, with every song?
Comment by Sascha Wolf (Horscht) - Wednesday, 13 February 2008, 04:35 GMT
yes, mine does it all the time, with every song. I compiled a few revisions, and so far have nailed it down to a change between SVN 16010 and 16025. Will do some more bisecting later on.
Comment by Sascha Wolf (Horscht) - Wednesday, 13 February 2008, 16:56 GMT
Ok, did some more testing. Issue was brough up with SVN 16019 "Make the playlist index be incremented after the PCM track change. This fixes  FS#8206 . Special treatment is required to avoid breaking auto dir change."

stoping and restarting playback does not fix this issue for me.
Comment by Steve Bavin (pondlife) - Wednesday, 13 February 2008, 17:48 GMT
Good work Horscht.. that's interesting.
Comment by Nicolas Pennequin (nicolas_p) - Sunday, 17 February 2008, 23:57 GMT
This should be fixed by r16330.
Comment by Sascha Wolf (Horscht) - Monday, 18 February 2008, 12:06 GMT
Unfortunatelly, still persistent as of SVN16342.

it still spins up after every song. Also general Disk Trashing (bug connected with  FS#8568 ) still persistent as well.
Comment by Sascha Wolf (Horscht) - Tuesday, 19 February 2008, 18:55 GMT
here is my config.cfg
Comment by Steve Bavin (pondlife) - Thursday, 28 February 2008, 17:06 GMT
Does enabling dircache stop the extra spinups?
Comment by Sascha Wolf (Horscht) - Thursday, 28 February 2008, 17:26 GMT
enabling dircache stops the disk from spinning up after every song. I tried 2 themes (rayboradio for OB, CabbieV2), with dircache enabled, once with WPS dsiplayed, once in the main menu.

with dircache disabled, i got disk spinups with both skins, on the wps and the menu,

with dircache enabled, no disk spinups on either skin in either the wps and menu.
Comment by Nils Wallménius (nls) - Friday, 07 March 2008, 17:01 GMT
Closed FS8667 as a duplicate of this as it is the same bug, the important things from that task are as follows.

* Only happens when dircache is disabled

* Happens with playlists and NOT with dirplay

* Introduced in r16019

* The cause is the added call to playlist_peek() inside audio_check_new_track().

* playlist_check() wouldn't be a suitable replacement check in its current for as it always returns true in dirplay mode.
Comment by Steve Bavin (pondlife) - Wednesday, 02 April 2008, 10:16 GMT
This one-line mod works for me, but probably needs a bit of testing.
Comment by Nils Wallménius (nls) - Wednesday, 02 April 2008, 11:42 GMT
While I don't understand why the check for an automatic dir skip is needed at all, playlist_check() always
returns true when in dirplay mode with automatic dir advance enabled so with your change AFAIU auto_dir_skip would always be false when an actual automatic dir advance happens...
Comment by Steve Bavin (pondlife) - Wednesday, 02 April 2008, 11:45 GMT
Indeed.... any better (i.e. simpler) ideas?
Comment by Steve Bavin (pondlife) - Wednesday, 02 April 2008, 13:18 GMT
OK, this one works by adding a new playlist API call to get the required info.

However, the PROPER fix is to sort out auto dir change to make it work without playback.c needing to know; maybe look at the MASCODEC code in mpeg.c for inspiration.

Loading...