Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Comprehensive USB Bug List

This site may earn commission on affiliate links.
Post#341 from BertL:
  • I've never tried two USB devices at once, so do not know what complexities that creates or not, especially since Tesla has never documented their intent.
I loaded two this morning (2,800 songs, 146 albums)....
  1. 512GB Mega-flat structure with albums only with no nesting &
  2. 256 Patriot with nesting of folders, Alpha + key artist, 5 levels down.

Both worked. Flat structure loaded in 2 minutes, nested 3 minutes
Thx. Do the songs integrate into one set in the standard Media Player Views (Songs, Albums, Artists, Genre), or is there some designation they are on one stick or the other?
 
As I have suggested in another post (and as I think others have, too), I like to use the Genre as a means to play a group of tracks as a "playlist," because it allows you to play a mix of artists and songs quite easily. And aside from the Shuffle failures that some have reported, you can (or should) be able to play them with a random mix among the artists and albums.

But there is another advantage to using Genre as well. (And I apologize if this duplicates what anyone else has said -- I have not read every comment on the various posts discussing the audio player issues with version 8.)

I did some testing with version 8 and verified that the audio system will play the tracks in correct order when using the Genre mode, unlike when you use folders or albums. For example, if you have a Classical piece such as a symphony that you would want to play in order, it will do so when played in the Genre. And that even seems to work if the tracks have duplicate names. E.g., “Pictures at an Exhibition” by Mussorgsky has several tracks entitled “Promenade,” but I found that they play in the correct order as I originally burned it (with the track numbers in the “Name” tag/field, not the “Title” tag/field). This is a big advantage of using Genre over using the other modes that apparently all play tracks in alphabetical order. (Don’t ask me why it works in genre but not in the other modes! But I hope it continues to work this way.)

And you can create your own genres; you are not restricted to the "standard" list. So for example, I created one (earlier, before version 8) entitled “Christmas” for Christmas music. So if you want to, you could create a genre for an individual album or symphony, etc.
The practical problem is that you could end up with so many genres that you have the same issue with scrolling through a long list on the screen as we have been complaining about for artists. So you may want to use distinct Genres sparingly to avoid that problem. The good news is that when there are multiple albums in one genre, they are played separately, with the tracks in order within each album.

So for example, you could have 3 or 4 albums by the same composer or artist/orchestra in a genre (e.g., one called “Beethoven” or “Billy Joel”) and the albums would play one after the other, with each played in track order (assuming the tracks are arranged correctly in the first place).

You might also want to be careful not to use overly long Genre names. I have not tested what limitations there might be on length – the longest in the drop-down list in my MP3 editing software is 22 characters.

If you do have multiple albums within an genre, you can scan the list of tracks in the genre before you start playing, and start at the beginning of the 2nd or 3rd or whatever album you want (running the risk of spending time away from the road, though).

And you can, of course, use Shuffle with a genre if you just want to play a mix of music and are not concerned about the order.

My own testing has been somewhat limited so I'll be interested to hear what others' experience is with using genre. But at least I hope that people who want to play tracks in order will give this method a try....
 
As I have suggested in another post (and as I think others have, too), I like to use the Genre as a means to play a group of tracks as a "playlist," because it allows you to play a mix of artists and songs quite easily. And aside from the Shuffle failures that some have reported, you can (or should) be able to play them with a random mix among the artists and albums.

But there is another advantage to using Genre as well. (And I apologize if this duplicates what anyone else has said -- I have not read every comment on the various posts discussing the audio player issues with version 8.)

I did some testing with version 8 and verified that the audio system will play the tracks in correct order when using the Genre mode, unlike when you use folders or albums. For example, if you have a Classical piece such as a symphony that you would want to play in order, it will do so when played in the Genre. And that even seems to work if the tracks have duplicate names. E.g., “Pictures at an Exhibition” by Mussorgsky has several tracks entitled “Promenade,” but I found that they play in the correct order as I originally burned it (with the track numbers in the “Name” tag/field, not the “Title” tag/field). This is a big advantage of using Genre over using the other modes that apparently all play tracks in alphabetical order. (Don’t ask me why it works in genre but not in the other modes! But I hope it continues to work this way.)

And you can create your own genres; you are not restricted to the "standard" list. So for example, I created one (earlier, before version 8) entitled “Christmas” for Christmas music. So if you want to, you could create a genre for an individual album or symphony, etc.
The practical problem is that you could end up with so many genres that you have the same issue with scrolling through a long list on the screen as we have been complaining about for artists. So you may want to use distinct Genres sparingly to avoid that problem. The good news is that when there are multiple albums in one genre, they are played separately, with the tracks in order within each album.

So for example, you could have 3 or 4 albums by the same composer or artist/orchestra in a genre (e.g., one called “Beethoven” or “Billy Joel”) and the albums would play one after the other, with each played in track order (assuming the tracks are arranged correctly in the first place).

You might also want to be careful not to use overly long Genre names. I have not tested what limitations there might be on length – the longest in the drop-down list in my MP3 editing software is 22 characters.

If you do have multiple albums within an genre, you can scan the list of tracks in the genre before you start playing, and start at the beginning of the 2nd or 3rd or whatever album you want (running the risk of spending time away from the road, though).

And you can, of course, use Shuffle with a genre if you just want to play a mix of music and are not concerned about the order.

My own testing has been somewhat limited so I'll be interested to hear what others' experience is with using genre. But at least I hope that people who want to play tracks in order will give this method a try....
Yes, you are right, Genre is a slight work around. It's downfall comes, like you said, if you have too many that you fall into the scrolling while rear ending someone issue.
 
  • Funny
Reactions: X Fan
I am still trying to figure out the initial load being so slow. Using BertL's suggestions I reprocessed my set of 5200 songs, so that the embedded art is never more than 300 X 300. They are in a flat structure - within a single folder.

Obviously it seems others have loaded bigger selections (and I note that on my old S, with 7.1 it loaded quickly and, of course, was cached once loaded). Also as noted earlier - loaded 1000s of songs in 2 minutes

When I insert this it says 'Starting...' for 2 minutes, then it starts processing at roughly 1% every 1.5 seconds, but at around 30% it starts to slow noticeably - it took 30 seconds to progress from 41% to 42%! At that point I left the car, since it is never going to load.

The USB is a PNY 256GB. The 5200 songs are FLACs and take up 167GB. The fact it slows down so noticeably, rather than being more constant implies as @BertL suggested, it is a memory issue. But I only have standard tags present, not especially long artist names or song names and all the art is now trimmed - so what could be the cause of the slow down?

I guess I could try a different brand of stick. Try limiting the number of songs to see if that loads more evenly, or even remove all artwork or all tags?

Any ideas how I might troubleshoot in a reasonable way?

Update: I deleted songs from the stick to leave me with 2839 songs - similar to the numbers previously reported. The stick did load to 100% - it took 16 minutes and showed pretty much the same slow down as before. As soon as I stepped out of the car and back in it started to reload :mad: - I have Energy Saving turned off, so I don't know if the reload is an 8.0 bug or a Model X bug!

So the slow down is based on how many songs have loaded (ie a memory issue), its just that the slowdown takes the time to load beyond anything reasonable. And then it starts to reload next time, so its not just a case of taking the hit one time.
 
Last edited:
I am still trying to figure out the initial load being so slow. Using BertL's suggestions I reprocessed my set of 5200 songs, so that the embedded art is never more than 300 X 300. They are in a flat structure - within a single folder.

Obviously it seems others have loaded bigger selections (and I note that on my old S, with 7.1 it loaded quickly and, of course, was cached once loaded). Also as noted earlier - loaded 1000s of songs in 2 minutes

When I insert this it says 'Starting...' for 2 minutes, then it starts processing at roughly 1% every 1.5 seconds, but at around 30% it starts to slow noticeably - it took 30 seconds to progress from 41% to 42%! At that point I left the car, since it is never going to load.

The USB is a PNY 256GB. The 5200 songs are FLACs and take up 167GB. The fact it slows down so noticeably, rather than being more constant implies as @BertL suggested, it is a memory issue. But I only have standard tags present, not especially long artist names or song names and all the art is now trimmed - so what could be the cause of the slow down?

I guess I could try a different brand of stick. Try limiting the number of songs to see if that loads more evenly, or even remove all artwork or all tags?

Any ideas how I might troubleshoot in a reasonable way?
My experience with my 256GB PNY is it's the slowest thing on earth... it may be so-called USB 3.0 compatible, but even on my Mac, writing to it will always cause a bouncing beach ball for extended periods. GIven all that, once I get data onto the stick, it's fine for basic music playing from what I can tell... speed on playback isn't that important.

The other thing is, IMHO some USB Sticks are more problematic with Tesla than others. As I said in a previous post somewhere here (I'm always mixed up which thread we're talking about USB issues in... anywho...) I've found three different sticks from three different mfgrs that seem to cause issues with slowdown on my Tesla but show no errors on my Mac or when the same stick is used to playback tracks on a boom box I have. So, here's how I have done my own little test -- it may be inconclusive, but I don't know of another way to do this without access to diagnostics that only Tesla has to see what errors are being caused by a USB a device. Try this:
  1. - Remove all USB sticks from your MS
  2. - Find a Watch or something to time with; Start timing.
  3. - Reboot your CID. Foot on brake; Hold both scrollwheels until Tesla T appears; Let up on brake and scrollwheels
  4. - Stop timing when Media Player shows on the CID
  5. - Now, insert the USB stick. No need to wait for it to scan.
  6. - Start Timing; Reboot the CID using same method
  7. - Stop Timing at same place as before
  8. - Compare results.
MY experience has been that USB Sticks that my Tesla may not like seem to cause the boot up process to also take longer -- I suspect because of some sort of error recovery and timeout the reboot process goes through. I can't be 100% sure on this, but two of the three sticks that seem more problematic getting music to scan are also ones that are inserted with longer CID reboot times. (Honestly, I think Tesla's USB error recovery just stinks compared to other autos and devices. Tesla will tell you, like they have documented on a service invoice to me, it is their recommendation to always plug USB devices in after you get into your MS, i.e. Don't keep them pugged in all the time. Sighhh.)
In the end, try another USB Stick or another brand, and maybe that is just 2.0, not 3.0 or 3.1 compatible. All three of my problematic sticks are 3.0 or 3.1 compatible -- IDK if that's coincidence or not.

Since you compressed art down, that leaves tag data in terms of possibly impacting memory some way. IDK if it's easy for you to make batch changes or not, but I'd first try deleting all tag data that's not used by media Player (see my list above), then go after TRACKARTIST next. I have some compilation albums where there is more than 1K characters in just those combined tags on a single album (6 or more artists in the one field). I remain convinced in my case that reducing that data allowed all my tracks to scan once again, just as it did in 7.1.

Remember, Tesla seems to have rewritten a major part of Media Player and tags are being used quite differently in 8.0 than they were in 7.1, so only Tesla Engineers could really investigate where their logic has introduced new problems and consumes more memory. Assuming that's the problem, Tesla still does not seem to have elected to put a hard limit on the number of things supported, throw-up an error and stop as it reaches a threshold -- instead things just seem to still slow to a crawl until maybe eventually something happens or the CID reboots and it tries again. Phewww.

Good luck.
 
Last edited:
My experience with my 256GB PNY is it's the slowest thing on earth... it may be so-called USB 3.0 compatible, but even on my Mac, writing to it will always cause a bouncing beach ball for extended periods. GIven all that, once I get data onto the stick, it's fine for basic music playing from what I can tell... speed on playback isn't that important.

The other thing is, IMHO some USB Sticks are more problematic with Tesla than others. As I said in a previous post somewhere here (I'm always mixed up which thread we're talking about USB issues in... anywho...) I've found three different sticks from three different mfgrs that seem to cause issues with slowdown on my Tesla but show no errors on my Mac or when the same stick is used to playback tracks on a boom box I have. So, here's how I have done my own little test -- it may be inconclusive, but I don't know of another way to do this without access to diagnostics that only Tesla has to see what errors are being caused by a USB a device. Try this:
  1. - Remove all USB sticks from your MS
  2. - Find a Watch or something to time with; Start timing.
  3. - Reboot your CID. Foot on brake; Hold both scrollwheels until Tesla T appears; Let up on brake and scrollwheels
  4. - Stop timing when Media Player shows on the CID
  5. - Now, insert the USB stick. No need to wait for it to scan.
  6. - Start Timing; Reboot the CID using same method
  7. - Stop Timing at same place as before
  8. - Compare results.
MY experience has been that USB Sticks that my Tesla may not like seem to cause the boot up process to also take longer -- I suspect because of some sort of error recovery and timeout the reboot process goes through. I can't be 100% sure on this, but two of the three sticks that seem more problematic getting music to scan are also ones that are inserted with longer CID reboot times. (Honestly, I think Tesla's USB error recovery just stinks compared to other autos and devices. Tesla will tell you, like they have documented on a service invoice to me, it is their recommendation to always plug USB devices in after you get into your MS, i.e. Don't keep them pugged in all the time. Sighhh.)
In the end, try another USB Stick or another brand, and maybe that is just 2.0, not 3.0 or 3.1 compatible. All three of my problematic sticks are 3.0 or 3.1 compatible -- IDK if that's coincidence or not.

Since you compressed art down, that leaves tag data in terms of possibly impacting memory some way. IDK if it's easy for you to make batch changes or not, but I'd first try deleting all tag data that's not used by media Player (see my list above), then go after TRACKARTIST next. I have some compilation albums where there is more than 1K characters in just those combined tags on a single album (6 or more artists in the one field). I remain convinced in my case that reducing that data allowed all my tracks to scan once again, just as it did in 7.1.

Remember, Tesla seems to have rewritten a major part of Media Player and tags are being used quite differently in 8.0 than they were in 7.1, so only Tesla Engineers could really investigate where their logic has introduced new problems and consumes more memory. Assuming that's the problem, Tesla still does not seem to have elected to put a hard limit on the number of things supported, throw-up an error and stop as it reaches a threshold -- instead things just seem to still slow to a crawl until maybe eventually something happens or the CID reboots and it tries again. Phewww.

Good luck.
I use just about the fastest option, Samsung 850 256gb in a 3.0 enclosure. Songs are 3-4 layers deep (Genre, artist, album, track). 8k songs is a initial load time of 46min.
 
My experience with my 256GB PNY is it's the slowest thing on earth... it may be so-called USB 3.0 compatible, but even on my Mac, writing to it will always cause a bouncing beach ball for extended periods. GIven all that, once I get data onto the stick, it's fine for basic music playing from what I can tell... speed on playback isn't that important.

The other thing is, IMHO some USB Sticks are more problematic with Tesla than others. As I said in a previous post somewhere here (I'm always mixed up which thread we're talking about USB issues in... anywho...) I've found three different sticks from three different mfgrs that seem to cause issues with slowdown on my Tesla but show no errors on my Mac or when the same stick is used to playback tracks on a boom box I have. So, here's how I have done my own little test -- it may be inconclusive, but I don't know of another way to do this without access to diagnostics that only Tesla has to see what errors are being caused by a USB a device. Try this:
  1. - Remove all USB sticks from your MS
  2. - Find a Watch or something to time with; Start timing.
  3. - Reboot your CID. Foot on brake; Hold both scrollwheels until Tesla T appears; Let up on brake and scrollwheels
  4. - Stop timing when Media Player shows on the CID
  5. - Now, insert the USB stick. No need to wait for it to scan.
  6. - Start Timing; Reboot the CID using same method
  7. - Stop Timing at same place as before
  8. - Compare results.
MY experience has been that USB Sticks that my Tesla may not like seem to cause the boot up process to also take longer -- I suspect because of some sort of error recovery and timeout the reboot process goes through. I can't be 100% sure on this, but two of the three sticks that seem more problematic getting music to scan are also ones that are inserted with longer CID reboot times. (Honestly, I think Tesla's USB error recovery just stinks compared to other autos and devices. Tesla will tell you, like they have documented on a service invoice to me, it is their recommendation to always plug USB devices in after you get into your MS, i.e. Don't keep them pugged in all the time. Sighhh.)
In the end, try another USB Stick or another brand, and maybe that is just 2.0, not 3.0 or 3.1 compatible. All three of my problematic sticks are 3.0 or 3.1 compatible -- IDK if that's coincidence or not.

Since you compressed art down, that leaves tag data in terms of possibly impacting memory some way. IDK if it's easy for you to make batch changes or not, but I'd first try deleting all tag data that's not used by media Player (see my list above), then go after TRACKARTIST next. I have some compilation albums where there is more than 1K characters in just those combined tags on a single album (6 or more artists in the one field). I remain convinced in my case that reducing that data allowed all my tracks to scan once again, just as it did in 7.1.

Remember, Tesla seems to have rewritten a major part of Media Player and tags are being used quite differently in 8.0 than they were in 7.1, so only Tesla Engineers could really investigate where their logic has introduced new problems and consumes more memory. Assuming that's the problem, Tesla still does not seem to have elected to put a hard limit on the number of things supported, throw-up an error and stop as it reaches a threshold -- instead things just seem to still slow to a crawl until maybe eventually something happens or the CID reboots and it tries again. Phewww.

Good luck.
Just as another data point, I have 3 USB sticks that I can use (1-64G, 1-128G both USB 2.0 Scandisk and 1-256G USB 3.0 PNY). The 256G PNY is by far the fastest to load 246G of FLAC which includes album art in about 2 minutes so it's become the only one I use now. I'm not sure exactly how many songs are on there but I want to say over 8 thousand. Folders are nested as follows: Music/Artist Name/Album Name/(if applicable) Disk #.

I've never had the memory or lag issues that you guys have but I probably just jinxed myself :).
 
As (yet another) data point - previously I reported that 2839 songs took 16 minutes to load, while sitting in the garage, doing nothing. I just went out to run an errand and the exact same load took 30 minutes while driving!

My TRACKARTIST tag is only ever the primary album artist - never any additional performers etc., so rarely, if ever, more than 25 or 30 characters. and ALBUMARTIST is empty about 70% of the time.

Its confusing that @msnow has a really fast load, @supratacophobia has a 46 minute load, and mine is 30 minutes for a lower number of songs. There has to be a 'magic formula' to explain it. It should not matter what the actual songs are, only the tags in the header.

Do you think having multiple folders in the structure is actually faster - I have all mine in a single folder
 
As (yet another) data point - previously I reported that 2839 songs took 16 minutes to load, while sitting in the garage, doing nothing. I just went out to run an errand and the exact same load took 30 minutes while driving!

My TRACKARTIST tag is only ever the primary album artist - never any additional performers etc., so rarely, if ever, more than 25 or 30 characters. and ALBUMARTIST is empty about 70% of the time.

Its confusing that @msnow has a really fast load, @supratacophobia has a 46 minute load, and mine is 30 minutes for a lower number of songs. There has to be a 'magic formula' to explain it. It should not matter what the actual songs are, only the tags in the header.

Do you think having multiple folders in the structure is actually faster - I have all mine in a single folder
My 2 minute load test was in the garage, car off. My memory is it takes longer if I'm driving but I'll have to test that again. I think my 2 minutes is faster than it was on 7.1.
 
I have 4367 songs (mostly MP3) in 706 albums. I have one level of folders, 487 of them - mostly 1 album : 1 folder. A bunch of singles are in a few folders. I am on .21, and initial scan time on my USB when first plugged in is less than 5 mins.

USB stick usage is approx 33 of 59 usable GB.

There are no subsequent scans; at least none that I noticed. I start playing USB music as soon as I get into my car. Also, my car sleeps overnight.
 
Just as another data point, I have 3 USB sticks that I can use (1-64G, 1-128G both USB 2.0 Scandisk and 1-256G USB 3.0 PNY). The 256G PNY is by far the fastest to load 246G of FLAC which includes album art in about 2 minutes so it's become the only one I use now. I'm not sure exactly how many songs are on there but I want to say over 8 thousand. Folders are nested as follows: Music/Artist Name/Album Name/(if applicable) Disk #.

I've never had the memory or lag issues that you guys have but I probably just jinxed myself :).
Do you have any substantial tag data, as well as Album Art? My tests nearly a year ago were lightening fast when I excluded most of the tag data on my tracks, and I was even achieving perhaps 20 min scan times back then with 12K tracks.

The x-programmer part of me unfortunately keeps coming out, in that while there could be huge variation, no matter how Tesla maps tracks on a USB a stick, it has to maintain some of that tag data and linkage back to the owners USB directory and filename structure... meaning, a single track in the root directory on a stick, that had no tag data and that had a filename of "A", even if it was physically many GBs in size, would take the least amount of memory in the CID, opposed to a Stick with many tracks, in a deep and wide folder structure where each directory name is long character-wise, as are the filenames of each track. That then compounds based on the tag data the UI is needing to maintain and how fancy it gets trying to deal with duplicates -- ALBUM, TRACKTITLE, TRACKARTIST and in theory DISCNUMBER and TRACKNUMBER -- and maybe something for some number of tracks with Album Art because at least a handful of icons are displayed in some of the standard views. It's why I keep coming down to the reason some people are still successful with larger number of tracks being scanned quickly is because there is less processing and/or memory being consumed opposed to some of us with highly curated music libraries that have to strip out more data to get it to all fit. Really, Tesla should just set a limit across the UI for things like places history, and for Media Player USB as to number of tracks it will support (6-8K like my former Lexus, MBZ and BMW used to have documented -- I appreciate some of you will gripe and see that as a takeaway, but it's why I personally settled on around 6K because I felt one day Tesla would have to impose a limitation), and perhaps do the switch as I've suggested with ARTIST tags to probably reduce memory consumption. Oh well. The game continues for some. Tomorrow I'm off to playing with some new volume normalization techniques to improve what I've already got working at long last. ;)
 
Guys, IMHO, time for scan/rescan is always going to take longer when driving. Remember, it's the same processor running Media Player as many other things with the CID and who knows what else, e.g. Nav, pulling down those fancy graphic tiles or line mode roads, playing your FM or dealing with Slacker while it's trying to scan... isn't the MCU/CUD alsos the same one that does logging, dealing with firmware updates, etc -- IDK for a fact. I do know there are so many variables that can impact scan time when driving, I only quote and compare scan numbers here based on my MS a sitting in the garage and generally still in Park.
 
FWIW, I have sadly turned Energy Saving OFF since going to 8.0. If I keep it ON as I have since taking delivery a year ago, my USB stick is rescanned almost every time I park and get back into my MS which is a huge annoyance to me especially when running errands around town -- parking, coming back in a few mins, drive a short distance, repeat. My initial scan time of 6100 tracks when parked is about 6 mins; rescan when parked is just over 3 mins. If the rescan is happening while I'm driving it can take 6 mins or more.

This Energy Saving bug with USB devices really gets me though. No good reason to do that except sloppy lack of testing and consideration for owners that want to listen to USB almost of the time.
 
As (yet another) data point - previously I reported that 2839 songs took 16 minutes to load, while sitting in the garage, doing nothing. I just went out to run an errand and the exact same load took 30 minutes while driving!

My TRACKARTIST tag is only ever the primary album artist - never any additional performers etc., so rarely, if ever, more than 25 or 30 characters. and ALBUMARTIST is empty about 70% of the time.

Its confusing that @msnow has a really fast load, @supratacophobia has a 46 minute load, and mine is 30 minutes for a lower number of songs. There has to be a 'magic formula' to explain it. It should not matter what the actual songs are, only the tags in the header.

Do you think having multiple folders in the structure is actually faster - I have all mine in a single folder

Sorry, correction needed. 15k tracks is 46min.
 
As (yet another) data point - previously I reported that 2839 songs took 16 minutes to load, while sitting in the garage, doing nothing. I just went out to run an errand and the exact same load took 30 minutes while driving!

My TRACKARTIST tag is only ever the primary album artist - never any additional performers etc., so rarely, if ever, more than 25 or 30 characters. and ALBUMARTIST is empty about 70% of the time.

Its confusing that @msnow has a really fast load, @supratacophobia has a 46 minute load, and mine is 30 minutes for a lower number of songs. There has to be a 'magic formula' to explain it. It should not matter what the actual songs are, only the tags in the header.

Do you think having multiple folders in the structure is actually faster - I have all mine in a single folder
I hypothesized earlier, but have not tried (and don't plan to) to test it more completely than I already have, that I do think there may be some sort of memory leakage problem, or frankly the way scanning is coded with 8.0, it consumes more and more memory while scanning flatter directory structures with larger number of "things", and then it resets when it gets to another structure some way... IDK. I do think it's just part of this puzzle, but unto itself, not the whole challenge for some of us:

As another data point and comparison of folder structure using the exact same 6125 tracks with same scaled-down contents as I described in my workarounds. IIRC I have about 100 ALBUMARTISTS and 1300 ALBUMS within that.
Test1: /2016-10-xx/Unique-Sequential-Number-DISCNUMBER-TRACKNUMBER TRACKTITLE (2-deep)
Test2: /2016-10-xx/ALBUMARTIST/ALBUM/DISCNUMBER-TRACKNUMBER TRACKTITLE (4-deep)
Test3: /2016-10-xx/ALBUM-ALBUMARTIST/DISCNUMBER-TRACKNUMBER TRACKTITLE (3-deep & my current structure)

Test1 never completed loading when I pulled the plug on it at 2 hours and 80% complete
Test2 & 3 are similar -- I may be off a few seconds but in my MS that was OFF, or at least Parked and not being driven, it took the same 6 mins to scan each, and a subsequent rescan took between 3-4 minutes. Effectively no difference.

So net there from my perspective is a little bit of folder structure allowed me to complete scanning, whereas a very flat structure did not with my 6K tracks and the same well-tagged contents they include.
 
Last edited:
  • Helpful
Reactions: MP3Mike
Sorry, correction needed. 15k tracks is 46min.
That is more like what I had with 7.1 and around that number of tracks when I took delivery and for the first couple weeks of ownership. I backed down 1K-by-1K to around 6K tracks as my compromise and personal sweet spot with how long it was taking to rescan, and the more frequent CID reboots I was having as the number of tracks on my USB device increased.

Even now with 8.0, 3-4 minutes for a rescan is frustrating for me. I just don't want silence when I get into my car, nor do I want to temporarily perform a manual switch to another media source which just reminds me of the Tesla bug I shouldn't be having. You are a much more tolerant guy than I am, my friend! :D
 
Holy moly, 46 minutes? Typo?
Sounds completely legit to me, sadly. I have about 3x that many tracks and it takes I-don't-know-how-long but much longer than 46 minutes. Much. Longer. On a PNY 256 GB stick for those of you keeping score.

After a fair amount of dinking with it, I have 100% given up on using USB for playback, since I realized even if I could solve the load time issues the UI solecisms make it impossible to actually USE. Of course, hope springs eternal that Tesla will pull it together in a future release. In the mean time I am hanging out here to keep abreast of the state of things.