Long Delay/Slow When Changing Tracks/Songs

SanDisk MP3 players Sansa® Fuze™
1

I may have a new incarnation to this problem.

I have a 4GB V2 Fuze. Firmware V02.03.33A. Just installed a 16GB Sandisk microSD. My library is all MP3’s, with just title, artist, and genre in the tags; no album art, no comments, etc.  I loaded the microSD card with some songs (3.2 GB used of 14.8 capacity, 1249 songs). The Fuze is in MSC mode. FAT32 file system on both the internal memory and the microSD.  The internal memory is formatted, but empty for testing purposes.

The problem is that changing tracks on the microSD is taking 4 seconds.  I watch the “xxxx/yyyy” display when a song is playing and time how long it takes from the time I hit the “right” arrow until the “xxxx” (song number) changes.  I did a test where I loaded 9 GB/3451 songs onto the card.  Changing track time increased to 10 seconds!   Something is definitely wrong.  

I read and, I believe, tried all the things mentioned in these threads:

http://forums.sandisk.com/t5/Fuze/Fuze-extremely-slow-to-load-skip-songs/td-p/86341/highlight/true/page/2

http://forums.sandisk.com/t5/Fuze/Long-delays-between-songs-located-on-microSD-card/m-p/213777/highlight/true#M46814

The problem still persists!

I have verified with MP3Tag that all I have in the files are ID3V2.3 ISO tags.  Title, artist, & genre.  That’s all I need.  I have told it to read the library’s ID3V1 tags and APE tags and I get blank columns.  They are gone.  When I tell it to read the ID3V2 tags, they appear fine.  Again, just title, artist, & genre.  I did all the MP3Tag work on the PC and then transferred the library to the Fuze, as directed in the above threads.

I have even re-generated the tags with MP3Tag’s Convert->Filename-Tag operation just to make sure they are pristine.  The problem persists.

The 16GB uSD card tests out at 4.2MB/sec write & 16.2 MB/sec read.  It is not the problem.  I also downloaded and re-installed the Sansa firmware. No change.

I re-format the uSD card (with Windows Explorer, Windows XP, SP3) before each transfer of the library to the uSD card.  The memory out there is fresh before each copy.  The database refresh is taking 8 minutes for the 3.2GB/1249 songs.  Seems long, based on times posted by other people.  That may be a clue.  

Note that my library is totally flat – no subdirectories.  That works best for me.  All my file names are “Artist - Title.mp3”, from which I generate the tags.  I manually specify the genre with the tag editor.

Any suggestions would be most appreciated.  I can supply more information if needed.

2

@bigbirdphila wrote:

 

Note that my library is totally flat – no subdirectories.   That works best for me.  All my file names are “Artist - Title.mp3”, from which I generate the tags.  I manually specify the genre with the tag editor.

Any suggestions would be most appreciated.  I can supply more information if needed.

 

I wonder if this could be slowing things down. Having so many tracks to sort through in one ‘folder’ (Music) or even the root directory may be taking more time, especially if using the Shuffle mode.  It may be looking for a more organized hierarchy like the ‘standard’ folder/file configuration (Artist [folder] > Album [folder] > Track [file]).

You might experiment with this and see if it helps.

Another thought . . . do your tracks have excessively long artist or title names? Or any apostrophes ( ’ ) in the title? Seems to me someone posted that their player had problems deciphering these. When they deleted them in the title (ID3 tag) their problems disappeared. Same could be true for any other non-alpha characters.

3

Tapeworm,

I’m not using shuffle mode, so that’s not an issue.

I created 25 “artificial” directories, each with 50 songs to test the “flatness” issue.  No change in track changing times that I could measure.  Since I didn’t see any difference with 25 directories, I didn’t think it was worth creating more.

Anyway, I’m thinking that when the firmware creates its tables (via the tag info), it will point directly to the file in memory regardless the directory structure the file is embedded in.  Based on that logic, I don’t think the directory structure should matter to the database.  Comments welcome.

The file names are not excessively long – just artist name and song title.  No track, album, etc. info.  No apostrophes, either.

Please keep the comments coming.  I’m at the end of my rope!

4

An update:

  1.  I borrowed a 32G uSD card.  Same symptoms.  So, the card is definitely not the issue.

  2.  I loaded the database into internal memory.  The delay is reduced (4 - 5 seconds down to 2 seconds), due to the internal memory’s faster speed, but it’s still there.  If I hit the “right” arrow twice, it takes 4 seconds to skip two songs.  So, that eliminates the issue of the uSD card completely.  I’ll continue doing tests only in internal memory from now on.

  3.  I created a library with *no* tag info at all.  Deleted all the ID3V2 info.  Loaded it into internal memory.  Database refresh time was still the same (6 minutes).  Same problem!  Even when traversing the songs via “Folders”, the delay is there.  It’s almost like the memory is very fragmented and the Fuze is collecting the song before it can play it.  I have no idea how song rendering occurs, though.

It’s interesting to note that the same problem occurs with our without tag information.  That seems to indicate that something else is the problem.  Could the Fuze be defective?

That’s all the extra info I have for now.  Suggestions appreciated.

5

I looked back, but didn’t see where you indicated the format of the files. Are they .mp3? Is there any reason to suspect them for the problem? Did you try running ChkDsk on them? Are they ripped from CD’s? With what software? At what bit-rate? CBR or VBR? Are they downloaded? From where? A legitimate site or ‘file-sharing’ site?

6

Is there any reason to suspect the .mp3 files themselves for the problem? Did you try running ChkDsk on them? Are they ripped from CD’s? With what software? At what bit-rate? CBR or VBR? Are they downloaded? From where? A legitimate music service or ‘file-sharing’ site?

7

Tapeworm,

I haven’t run ChkDsk on them.  What will it tell me?  Can I run it in batch mode?

The whole library is scanned weekly with AVG, Spybot, and MalwareBytes.  No issues reported.  They all play OK in Windows Media Player and in the Fuze itself.  

Most are 128Kbit/sec.  Some a little slower.  A mixture of CBR and VBR, mostly CBR.  I’ve put the library together from ripped CDs, Amazon downloads, and friends’ contributions.  It’s been a “work in progress” for many years.  This is my first Fuze, so it’s the first time it’s going on one of those.

Let me know if you have any other questions.

8

I just did a speed test on the internal memory of the Fuze with H2testw.

To my surprise, it’s reading slower than the uSD chip.  Is that normal?

Actual numbers are 4.3 MB/sec “write” and 5.8 MB/sec “read”.  The uSD numbers were 4.2 and 16.2.

The internal memory is almost 3 times slower than the uSD card.  Is that an issue?  Remember, though, that the same problem occurred when the library was on the uSD card.

9

The speed observations above have me thinking – can someone with a Fuze that we know is working properly run a speed test on its internal memory?  H2testw is a very small (207K) utility if you need one.  

Also, can someone report how long it takes their properly-working Fuze to skip ahead 2 or 3 songs?  Just watch how long it takes the “xxxx” in the “xxxx/yyyy” display to increment by 2 or 3.  That will eliminate timing the silence @ the start of a track.

10

The internal memory on the Sansa players is extremely slow. I think your results are normal.

11

I just ran chkdsk on the Fuze’s internal memory.  No issues reported.  

I did notice that the cluster size on the 4G internal memory is 4K.  The cluster size on the 16G uSD card is 8K.  The problem happens on both memories.

I also ran the disk defragmenter on the internal memory.  It reports that no defragmentating is necessary.  The memory shows up as one big chunk of contiguous files.  I guess that’s not surprising since I formatted the memory immediately before copying the library to it.

12

@bigbirdphila wrote:

I also ran the disk defragmenter on the internal memory.  It reports that no defragmentating is necessary.  The memory shows up as one big chunk of contiguous files.  I guess that’s not surprising since I formatted the memory immediately before copying the library to it.

 

Or the fact that flash memory doesn’t store files willy-nilly all over the place like a conventional physical spinning hard drive does. There no need to de-frag a flash drive; in fact it is detrimental to it and can shorten its life-span.

13

An update …

No solution yet, but I did try a couple more tests.  Here’s a summary of what I know so far about the problem:

  1.  I can navigate the screens (Artists, Albums, Songs, Genres, Folders, etc.) as fast I as I can press the buttons.  No degradation there.

  2.  The delay only occurs when I try to play a song, or jump to the next one or two or previous one or two songs.  The delay to move two songs in either direction is twice the delay to move one song.

  3.  The database builds seem, to me, to take too long.  6 minutes on a 1249 song/3.2G library; 49 minutes for a 3446 song/9.4G library, for examples.  This might be a clue.

  4.  The whole library is MP3 files, nothing else.  The files play fine in WMP and Winamp on the computer.  They also play fine in WMP, Winamp, and the Fuze itself from Fuze memory.  Quick, too (except for the Fuze).  No delay in accessing them with the a program on the PC.

  5.  The delay varies directly with the size of the database and depending upon whether the song is in internal or external memory.  2 seconds delay on the 1249 song library in internal memory, 4 seconds on that library in external memory, 10 seconds on the 3446 song library in external memory.

  6.  My tags are very simple: just Artist, Title, & Genre.  No Albums even.  No other tags beside these 3.  They are ID3V2 ISO, written & confirmed with MP3Tag.  In fact, I did a test where I removed all the tags and the delays did not change.  Bad tags are not the problem.

  7.  I can reduce the delays slightly by formatting with SDFormat.  The 4-second delay decreases to 3 seconds.  It’s like the Fuze is reading the library excessively (sequentially?) to piece together a song before starting to play it and SDFormat is allocating the clusters in a more efficient configuration than Windows format.  I always do a “format” operation before any of my tests.

  8.  Windows explorer can display an alphabetical list of songs in Fuze memory over the USB bus faster than the Fuze can start to play a single song in its memory.  The Windows display appears basically instantaneously.  

  9.  It’s almost like I have stumbled across some kind of database bug in the Fuze due to my limited use of tags or the makeup of my library.  The Fuze abandons use of the filesystem and instead falls back to some kind of sequential search to find the actual song to pay.  A real guess on my part, I admit.

Is there some kind of utility that can dump the contents of the Fuze database to check its integrity?

I’m running out of ideas …

14

BigbirdPhila wrote:

 

I created 25 “artificial” directories, each with 50 songs to test the “flatness” issue.  No change in track changing times that I could measure.  Since I didn’t see any difference with 25 directories, I didn’t think it was worth creating more.

I think it might be related to how your music is organized on your Fuze.  I have always organized my music on my Fuzes by folders and have no or very little delay in changing tracks.  Albums generally do not have fifty songs.

 

Please try the following.  Create twenty-five folders each with ten songs on your Fuze, but make sure there is no other music on your Fuze.  Are you then still getting this delay?

15

Contrapuntal,

That’s a good idea.  One problem may be that, as the database gets smaller, the delays go away (or, more precisely, are harder to measure).  I need a delay at least as long as a second to be able to measure it and be sure it’s happening.

If my “linear” observations are correct, a database of 250 songs in external memory should produce a delay of around a second ( 1/5 of the 4-second delay).  Maybe I’ll make 10 more directories to be sure.  The problem is doing this manually is tedious.

I will try it and let the Forum know.

16

It turns out that the Fuze’s database creation (“refresh”) time and song-to-song access time (the time to move from one song to another after the database is built) are very sensitive to the size of the biggest directory of the library.  If you are having problems with long database rebuild times or multi-second song-to-song transitions, the size of your directories may be the problem.  There are other threads dealing with other causes of these problems and, for completeness, I reference them here:

http://forums.sandisk.com/t5/Sansa-Fuze/Fuze-extremely-slow-to-load-skip-songs/td-p/86341/highlight/true

http://forums.sandisk.com/t5/Sansa-Fuze/Long-delays-between-songs-located-on-microSD-card/m-p/213777/highlight/true#M46814

To test the sensitivity of the Fuze to library directory size, I took a library of 1250 songs (MP3, 3.2 GB) and divided it into different directory configurations.  I then measured the time it took to rebuild the database (what the Fuze calls “Refreshing your media”) and the time it took to move from song to song with the “right” arrow button (the length of time it took the song number to change, to eliminate measuring any silence @ the beginning of a song).  The library ID tags consisted solely of artist, title, & genre in ID3V2.3 ISO format (created by and verified with MP3Tag).  The tests were performed in external memory (32GB microSD card).  The Fuze was in MSC mode.  I didn’t reformat between each test – I just edited the directory structure directly on the Fuze with Windows Explorer.  Here are the raw results:

directories             #songs per directory              Rebuild time             Song-to-song time (sec)

---------------                ------------------------                    ---------------                ----------------------------

       25                                  50                                          1:57                                   1

       12.5                             100                                         2:20                                    1

         6+                              200                                         2:47                                    1

         4+                              300                                         3:11                                    1

         3+                              400                                         3:38                                    1

         2+                              500                                         3:59                                    1.5

         2+                              600                                         4:28                                    2

         2+                              700,500                                 4:50                                    2

         2+                              800,400                                 5:02                                    2

         2+                            1000,200                                 5:58                                   2.5

         1                               1250                                        7:20                                   3

From the above data, it appears that the Fuze’s database build time starts to measurably climb with as little as 100 songs in a directory.  The song access time doesn’t start to measurably increase until there are about 500 songs in a directory.  I can understand how the directory size might affect database build time (not as much as I observed, however), but I do not understand how it affects access time afterwards.  To me, once the database is built, a pointer to the starting cluster for each song should have been extracted from its directory entry and stored in the Fuze database.  From then on, the directory structure should not be needed.  I am missing something, based on my observations.  Regardless, it is what it is, and there will be no Fuze firmware updates in the future; we must live with what we have.

My flat library structure was what was causing my long database rebuild and song access times.  I was not about to change it on my PC since it has served me well for many years.  My only question then was how to segment my library on the Fuze to achieve satisfactory build and access times.  I did one last set of tests with directory sizes of 50 and 100 in external memory, formatted with SDFormat before each test.  The results were:

directories           #songs per directory               Rebuild time            Song-to-song time (sec)

---------------              ------------------------                     ---------------              ----------------------------

        25                                50                                           1:55                                    1

        12.5                           100                                          2:06                                     1

Rebuild time is 9.5% slower with 100 songs in a directory compared to 50 songs in a directory.  Access time difference is not measurable.  I decided to go with 100 songs per directory for my full library (3500 songs, 9.4 GB) and accept the 9.5% penalty.

I created 35 artificial subdirectories on the microSD card and populated each with 100 songs from my library.  Refresh time for the full library was 6:28.  Access time was still 1 second.  Success!  If I had gone with 50 songs per directory, my build time would probably have been around 5:55 (I did not actually test this – I was sick of creating & testing directories by now).  I decided 30 seconds per build was a small price to pay to be able to work in chunks of 100.

Finally, some comments on using MP3Tag which I haven’t seen documented.  Spend the time to learn its options via Tools->Options->Tags.  Then, do the following:

  1. Remove ALL tags from your whole library
  2. Remove all extended tags you don’t need from your library (via View->ExtendedTags or the ExtendedTags target in the right mouse button’s context menu)
  3. Create ID3V2.3 ISO tags for your whole library
  4. Turn on viewing of all possible tag columns via View->CustomizeColumns
  5. Verify that you don’t have any superfluous tags by sorting each column in both ascending and descending order.  See if any weird values show up.  Edit appropriately.
  6. This should insure that you have 100% pure ID3V2.3 tags, and only the ones you want.

I hope this information helps people experiencing the same problem I was.  Without the Forum, I would have returned my Fuze by now.

17

Why use the genre tag but no album tags? Perhaps if you had a reasonable album tag setup the refresh might be  faster? When you mention songs per directory, do mean the number of songs in each genre? Normally there are typically around 8 to 30 tracks per album. It seems like the album tag is important to the player, and without it being utilized you are getting unusual results.

18

Step one, removing all tags, is extreme. Then you have to re-tag everything. Just remove inessential ones, fix anything long or weird,  and make sure they are ID2v2.3 ISO=8859-1.

19

The version of MP3Tag that I was using (V2.50) only allows removal of ID3v1, ID3v2, and APE tags.  It does not allow specific removal  of ID3v2.3 UTF and ID3v2.4 UTF tags, although it will write them.  The MP3Tag display window does not display what kind of ID3v2.3 tags (ISO or UTF) are in a file.  It just says “ID3v2.3”.  I did not want to risk having a mix of ID3v2.3 ISO, ID3v2.3 UTF, and ID3v2.4 UTF tags.  I didn’t know if this would cause a problem with the Fuze, and I didn’t want to take the risk.

By removing all my tags and then explicitly generating ID3v2.3 ISO tags, I could insure that I did not have any ID3v2.3 UTF tags lurking in any of my files.  By telling Windows Explorer to sort my library by genre, I could drag & drop each genre into MP3Tag separately.  I then used MP3Tag to generate the Title and Artist tags and did a “select all” and changed to the appropriate genre.  I repeated this for each genre (5, in my case).  The total time to do this was miniscule compared to the time I spent tracking down my problem.

By doing what I did, I could guarantee that I had only ID3v2.3 ISO tags in my library.  If I hadn’t removed all my tags, I wasn’t sure what I would end up with. 

20

I don’t think mp3tag will save multiple versions of ID3v2.3 tags.

If you set the Write default to ISO-8859-1 and just Save, I believe it will overwrite previous tags with the correct kind.

1 Like