Rockbox Technical Forums
Rockbox General => Rockbox General Discussion => Topic started by: NaFIann on March 09, 2008, 01:30:56 PM
-
Hi,
I've noticed that when skipping songs during playback, after a few skips or when the new songs have just been loaded, the correct song info will appear (as in, the info of the song that was skipped to),
but the song that was playing when I skipped will keep on playing for a while longer (sometimes as much as 10 seconds).
Sometimes instead of playing on, there will just be nothing for a few seconds.
I was wondering if there was anything I could do about this.
Na-Fiann
-
What build revision number are you using?
-
it's r16431M-080227, compiled myself on ubuntu, with a different bootscreen and an extra application plugin (japanese quizz)
-
Well you know what the rules ask you to do first before asking for help right?
Even if you believe that you didn't make any changes to the source that would affect your problem, you need to check it out with the latest stock SVN build.
-
This happens with official builds too (or at least it did in r16460, which I updated from yesterday). It seems/ seemed to be more likely to happen with songs at high bit rates. (MP3s, encoded at a variable bit rate that spent most of the songs around 320kbps.)
-
I've noticed this behavior in builds after 11/25/07-ish  -- it's as if the hard drive gets "lost" and can't find its way.
However, with the more recent builds (3/07/08) I do note that when:
1. Directory Cache is tuned off
2. Auto-change to the next directory is turned off
the problem becomes virtually non-existent. Â One has skip forward/backward pretty fast to make it happen, regardless. Â Perhaps trying either or both steps will help.
-
I've just installed a standard rockbox version r16592-080309 and the problem still exists.
Most of my files are reasonably high bitrate, but it also happens with 192 kbps mp3's.
I'm not sure where to turn off directory cache and I'm fairly sure I never ise auto-changing to the next directory (its always on shuffle and repeat-all)
-
I think the default for both items is "No" or "Off". However, I don't use shuffle or repeat so maybe that's the difference.
-
I've been having the same problem. It seems to take a long time to load the new song after skipping forward or back. Sometimes up to 30 seconds for me. I've also noticed it seems to get worse the longer the player has been playing. (If I reboot, it works fine for a while)
I'll try turning directory cache off and see how it goes.
NaFIann: You can turn it off in "settings>general>system>disk"
-
I Too have seen this problem And it is at first start up when the buffer is filling the hard disk is accessed contnually. Also orther functions don't work during this period try shutting down!
This seen on an ipod video 5g.
-
I have also seen this issue.
There does seem to be a thread priority issue between the buffering thread and the dircache thread during startup. If 'resume playback on startup' is turned on, the dircache takes up to 30 seconds to get built (in the background). If resume is off, dircache builds in about 5 seconds.
This was not always the case - official builds from a couple of months ago didn't seem to have the problem.
I also see the issue that rapid skipping of tracks confuses the buffer and the current/next track info for the WPS. Sometimes the only fix is to stop playback and then resume it (a pause isn't enough)
It was recommended to me in an earlier thread to get on IRC and discuss with devs - I'm sorry I haven't yet done that. If needed I would be able to do that tonight, Aussie time.
I might try turning off the auto-change directory option as well, since people mentioned it.
-
Still happening with r16626-080311. Â I played around with this issue pretty good. Slow to moderate navigation on the file dirs seem allright, but if one skips around forwards and backwards quickly, "something" loses track and the file data is either incorrect or missing. Â I tried playing around with dir cache, auto-change, dir cache size, playlist size, spindown, anitskip buffer, turning the equalizer on/off and can still make the missing/incorrect info in WPS happen with very fast dir/file navigation.
Navigating slow to moderately in the dirs would seem to be the workaround.
Ipod 5.5g with about 11,700+ .ogg files ranging mostly q7-q8 with just a couple of Q10 for fun.
Edit: Just for fun: I tried changing the dircache to 16000 in the config file and playlist size to 32000. No change.
Maybe another clue: Even with auto-change dir turned off, with quick navigation, I can skip to the next dir anyway.
-
I've had this issue since November of last year as well. Funny thing is the original rhapsody firmware actually averages faster song changes across a playlist than rockbox now; which was one of the reasons I loaded rockbox :-\
JT
-
I wonder if this delay is due to finding album art that doesn't exist (for some).
Without looking at the code does each file skip in file directory browing:
IF SKIP
 GET_ID3_TAG
 FIND_ALBUM_ART
ELSE
 (whatever)
If so, then maybe an album art file seek switch is needed so as to not attempt to find album art if one never intends to use album art. Â One of the big complaints concerning the new iPod classic is sluggishness perhaps due to all the album art seeking.
IF SKIP
 GET_ID3_TAG
 IF ALBUM_ART == YES
   FIND_ALBUM_ART
 ELSE
  NOP
ELSE
 (whatever)
It might a bit longer to get album art but maybe the tags can keep up.
EDIT:
After playing with the config files and numerous builds, I may be leaning towards the r16441 from February 28 as the "nimblest" of the builds for dir navigation yet still have the most prominent of the newest features. Â Version r16441-080228. Â There are other issues of course and a review of the fixes since then should always be performed. Â I think I'll stick to r16441 for awhile and see how it goes.
Still probably best to turn auto-dir change to off.
iPod 5.5G 80GB 11,000+ files 25.2GB free.
It is here:
http://www.rockbox.org/dl.cgi?bin=ipodvideo64mb
-
glad to see it at least isn't something caused by my player alone.
On my version of the firmware, I can't find the disk menu in settings>general>system.
all that is available is:
- Start Screen
- Time & Date
- Idle Poweroff
- Limits
- Car Adapter Mode
- Wheel Light Timeout
- Keyclick
maybe someone changed the menu for sansa's?
-
Most likely (I also use a Sansa). The Sansas use flash memory instead of slower hard drives, so I can see why these settings are omitted.
-
I have also been having this issue, and in addition sometimes when skipping forward or back the song will not play and just hangs on 0.00. The only way to get any song to play then is to go back into the file browser and select that or another song. Very frustrating.
One interesting thing to note, is that my friend is having a similar issue on his ipod which does NOT have rockbox installed, but just using the apple firmware.
This makes me wonder if the problem might be from initializing the ipod with a new version of itunes which may have a bug in it. I recently had my ipod replaced by apple, so I initialized it with the newest version of itunes before loading rockbox on it. Is it possible that the problem some people are having might arise from the initialization and not from the rockbox firmware?
Hopefully someone with more technical knowledge of what actually happens when an ipod is initialized can shed some light on this...
-
maybe someone changed the menu for sansa's?
It was temporarily disabled, the current build should have it under the Settings->System->Disk.
-
Is this still a problem? Things seem fine to me on an iPod 5.5G (80G).
-
I'll check the latest build. Â My notes here:
http://forums.rockbox.org/index.php?topic=15647.msg120136#msg120136
EDIT:
Response time seem quicker but the tags still lose their way. A separate issue, Directory Change still doesn't work with file skipping (r16892).
-
The current build is 17219. Why are you referencing 16892?
-
Er, maybe because you're replying to a post from 23 days ago? That build was current on March 30.
-
Weird, I didn't look at the "Edit" time. This showed up to me as a (New) post for some reason. =/ It was even on the front page for me...
/me makes a note not to trust "New" explicitly any more.