ClipZip is very slow to make even minor changes to content. Even using all MP3 files as content.

After five weeks of use of the ClipZip, I have skirted around the SanDisk AAC file support minefield and have made the transition of all of my files to MP3 to get them to the point of full use on my 32 GB memory card and the 4 GB of player memory.  Despite the success of actually getting all of my iTunes content converted to MP3 format and loaded to the card and the player, I find the player still has a major issue with very slow refresh times for even minor changes to content.  Adding and deleting a couple podcasts to the player memory takes over ten minutes of refresh time before the player is usable again.  If I change a few (10) of the 3100 music files on the 32  GB memory card I face a refresh cycle that can take over an hour or more.  

This is unacceptable refresh performance that detracts significantly from the usability of the player.  Where are the firmware changes to fix this issue? When will they be provided? Usability issues of this magnitude with this player should take priority over most of the firmware improvement suggestions I have seen in that thread.  This player has major usability issues with content refresh times, aac file load support and high bitrate aac file playback usability.  None of these issues have been addressed in the firmware changes made up until now as far as I can tell.

Reading through the forum posts, I see mention that file tag issues may be a reason for these refresh delays.  I see no specifics from SanDisk Gurus and Experts to help the customer figure out how to tweak their file tags to help speed up the atrociously slow refresh routine.  SanDisk should either fix this issue on the code side with new firmware, or give us customers some help to understand what aspects of our tags may be an issue and what we can change in our tags to work around the refresh code inadequacies if they are not going to be fixed.

This player’s best usability is when the file content is kept static.  Make content changes and the player’s inadequacies become quickly evident.  In my world, where I listen to audiobooks or podcasts, and get new music content on occasion, player content will change, but I find the ClipZip is not up to that challenge in it’s present form. It is too slow at handling content changes to be considered usable.  This should be fixable.  Make it so!

GPH

Here’s a couple things…

Sansa friendly tag settings for MP3Tag…

And here’s a sample of my personal tagging practices…

And here is a sample of my refresh times, from my review threadover at ABI…http://www.anythingbutipod.com/forum/showpost.php?p=571366&postcount=149.

I’ve never had a 32GB card, but an 8GB player and 16GB card are at the absolute most around four minutes for me, if both internal and external are filled to the brim.

You may have seen my post here…http://forums.sandisk.com/t5/Clip-Zip/Confirmed-Micro-SD-Load-Problems-due-to-aac-file-load-failures/m-p/248088#M658…so you can see I can empathize with those who swap content on a daily basis. Even with the most optimized tags, someone with a 32GB card could probably expect a somewhat lengthy refresh, but I’m thinking it shouldn’t be anywhere near what you’re experiencing. I’d be willing to bet that my files would refresh in under 20 minutes if I had one of those cards, but I haven’t bought one yet, since I have two other high-capacity players.

But for someone that listens to podcasts or something similar where you’re changing content on a daily basis, you’re best off taking the card out, or having a second player that you keep card-free…no matter if your file tags are optimized like mine or not, the refresh gets tiresome, as I was reminded these last couple of weeks…

Marvin_Martian,

Thanks for the quick reply and the Mp3tag settings.  I’ll try those out and see what happens. Your sample image of your personal tagging practices did not show up on my screen for some reason when I viewed your reply. I would like to see that.

Just last night I decided to refresh my podcasts on my ClipZip.  I deleted about 12 podcasts and added about 14 new ones, which is about a normal weekly refresh for me.  I have already given up on daily changes to this player.  It is just too slow to hassle with the delays on a daily basis, so I have gone to weekly updates for podcasts and any other content changes.  All of these podcast changes were made to the ClipZip memory, as I know changes to the card take a lot longer to process than the player’s own memory.  

It took the ClipZip  49 minutes to complete it’s “Refreshing Your Media” cycle after these 26 podcast file changes were applied.   I do have 3100 or so songs on my 32 GB memory card occupying 27 GB of that space, but I made no changes to that content.

Here is another interesting discovery I just made while writing this.  When the player just finished it’s refresh cycle (after 49 minutes) I reconnected it to my computer to check how much memory space I was using on the card (to give you the 27 GB info detail above).  I then ejected the player from the computer and, even though I made no additional content changes to the player, or the card, the player started another refresh cycle that took another 49 minutes to complete.  This is incredible!   Incredibly bad that is!    No changes to content and you have to wait for the player to refresh for another 49 minutes.  It looks like the player forgot the previous refresh cycle it just completed and started it all over again.  I guess the SanDisk engineers skipped usability training. 

I notice you mentioned that for you these refresh delays are tiresome.  For me they are a sign that SanDisk has a very inefficient content update routine that should be replaced ASAP with a new design that can allow daily updating without these annoying, usability destroying, refresh delays. It is becoming increasingly clear that SanDisk has dropped the ball when it comes to having a content update routine that scales for the memory capacity of the new player.  They need to fix this or lose customers permanently. That is the bottom line.

GPH

OK, here’s another attempt to show the image of my personal tags…

Interesting that you mention that you have 3100 songs on your card. At least on previous players, the number of total files had an effect on the refresh time , which didn’t necessarily seem to correlate with the amount of space used…as in, using the same amount of space no two players, the one with more songs on it would refresh slower.

In my link above of my refresh times, I had 2,685 tracks on the players…and the Zip was under three minutes to refresh. 2,685 isn’t that far away from 3,100, and I think of those 2,685 maybe 900 or so were on the internal memory.

I have always seen the microSD card as a handy swappable medium, with the 4GB being my favorite.   It’s just about the right size to swap between the various Sansas I usually tinker with.

Well, times have changed, and we now have affordable devices running up to 32GB  in a fingernail sized card. Over the last few years, the format has doubled capacity several times.

There are several ways to handle the music database, even possible “tricks” that can be employed, such as using an append method rather than a full rewrite, or recognizing whether there has been a change to the card contents.  Now that these little guys have so much potential capacity, it will be of benefit to all if that database maintenance could be handled differently.

Personally, I’ve found that using MTP mode (where the Sansa is addressed as a portable media device) is considerably faster in terms of database management.  I make daily changes, often several times a day, and refresh times are typically under 30 seconds following disconnect.

Please note that I am in agreement, the database needs a better mousetrap, for lack of a better phrase.  The capacities possible necessitate it.  There are plenty of users out there who must use MSC mode (Linux fans can employ functions like libmtp , an option not open to everyone, like Mac OS).  In MSC mode, the database refreshes every time upon disconnect, unlike MTP.

Bob  :wink:

Thankfully, this is less of an issue now for me personally…my desktop is back \o/

So I can leave what’s on the Zip, on the Zip, unless there’s a new album for the listening rotation…and my daily podcasts will go on my iPod.:wink:

Hopefully my tagging tips were of some help!

I have utilized a number of the suggestions presented here on the forum to try to workaround some of the issues with this player.  My latest experiment was to move my files to Windows to bypass any potential MacOS reasons for slow player refresh times.  I also used the suggested Mp3tag program to read and then rewrite all my tags for all the files moved to the player.  I took my card and deleted all the files moved from the Mac and replaced them with the the files moved to the PC and retagged them all with Mp3tag.  The result was a card that took 110 minutes to refresh about 27 GB of content.  This is still way too slow in my opinion and the only thing I have left to try is the MTP mode instead of MSC.  All this work thus far has produced no noticeable improvement yet in refresh times.  These were very disappointing results to say the least.

In summary it appears that Mac hidden files are not the reason for the slow refresh.  I took that out of the equation by moving the files to the PC.  It appears ITunes tagging is not the reason either.  I retagged all the files with Mp3tag on the PC. While retagging I made sure I only have MP3 files left to transfer to the card , so aac files are a non issue now for my refresh delay. The refresh still takes 110 minutes for the card.  Would you live with that?  Is that reasonable performance for a player that costs $50? 

I still have to test changing some podcasts on the player memory to see how that works out for refresh.  I will see if that still takes 49 minutes for 26 or so changes.  After I finish that test I will try MTP mode and rerun this test just to see if it changes anything.  

Without some actual SanDisk refresh routine software improvements, it appears this player refresh usability with memory cards can’t be improved with the suggested forum workarounds I tried so far.  I thank everyone for the ideas provided thus far.  Does anyone have any other ideas other than doing whatever we have to to get SanDisk to address this refresh issue?  I’m running out of things to try and I am about out of patience with this player.

GPH

Are you using album art? Are the images embedded in the ID3 tags? Are they 500 x 500 (100kb) or less? Large album (or cover) art has been know to significantly slow down refresh times, sometimes even freezing the player up altogether.

110 minutes is wayyyyy too long. It should only take 5 -8 minutes at most. My 8GB model with a full 32GB card only takes this amount of time to refresh. Yours shouldn’t take any longer.

@tapeworm wrote:

Are you using album art? Are the images embedded in the ID3 tags? Are they 500 x 500 (100kb) or less? Large album (or cover) art has been know to significantly slow down refresh times, sometimes even freezing the player up altogether.

 

110 minutes is wayyyyy too long. It should only take 5 -8 minutes at most. My 8GB model with a full 32GB card only takes this amount of time to refresh. Yours shouldn’t take any longer.

Is that with MP3 or FLAC files?

I’ll check that next using Mp3tag.  A lot of my 3100 files don’t have cover art, but I will check that suggested size cutoff for those that do.  Thanks for the reminder, I had forgotten about the cover art size issue.

GPH

@marvin_martian wrote:


@tapeworm wrote:

Are you using album art? Are the images embedded in the ID3 tags? Are they 500 x 500 (100kb) or less? Large album (or cover) art has been know to significantly slow down refresh times, sometimes even freezing the player up altogether.

 

110 minutes is wayyyyy too long. It should only take 5 -8 minutes at most. My 8GB model with a full 32GB card only takes this amount of time to refresh. Yours shouldn’t take any longer.


Is that with MP3 or FLAC files?

All MP3 files at this point.  With 110 minutes to refresh around 3100 files (27 GB) on a SanDisk 32 GB with Level 4 card speed.

GPH

In checking the tags of the 3100 files (now on my PC), I find that in the process of moving these files from the Mac and retagging them with mp3tag I lost all album art cover linkages.  The Cover column in MP3tag is completely empty for all of the files, so that 110 minutes of refesh time is with no cover art at all.

GPH

@gph wrote:


@marvin_martian wrote:


@tapeworm wrote:

Are you using album art? Are the images embedded in the ID3 tags? Are they 500 x 500 (100kb) or less? Large album (or cover) art has been know to significantly slow down refresh times, sometimes even freezing the player up altogether.

 

110 minutes is wayyyyy too long. It should only take 5 -8 minutes at most. My 8GB model with a full 32GB card only takes this amount of time to refresh. Yours shouldn’t take any longer.


Is that with MP3 or FLAC files?

All MP3 files at this point.  With 110 minutes to refresh around 3100 files (27 GB) on a SanDisk 32 GB with Level 4 card speed.

GPH


 

Sorry GPH, that question of MP3 or FLAC was aimed at Tapeworm. Reason I ask him that, is that on past Sansa players, the total number of files was a factor that contributed to refresh time length, and with FLAC there would obviously be a lot fewer files in total.

My latest refresh time with the Zip, 8GB with 16GB card, was three minutes, twenty-one seconds. That’s with all MP3 files, 20MB free internal, 1874MB free external, 2,335 songs, one podcast.

Same problem.

I have 3800 songs (22 gigs) mostly in Ogg Vorbis 192 kbps. Refresh is an about 1 hour.

And most annoying feature is skipping song takes about 7 seconds.

microsd card is Adata 32 gigs, class10

ps - sorry for my english

I don’t know if anybody has posted this yet or not, it would be nice to be able to play all contents in a directory without shuffling them.  I have a directory for an artist with all of their assorted albums and would like to play the whole list through but I have to settle for one album at a time.  That is pretty restrictive.  I consider this to be a serious limitation with this product.  I would even go so far as to say it is a flaw.  Please fix this problem post haste.