BertL
Active Member
@dweeks, I can't help with the MP3tag on Windows part of your question. I use only macOS apps to manage my master music library and create/maintain my Tesla-unique USB device, but can perhaps shed light on your last observation:
E.g. original MS like mine had 2GB of CID memory that has to house most Tesla code (which grows with every release and addition of useless Easter eggs as we again received with this last drop), various working areas, nav maps, destinations and history, phone contacts, any data being collected and/or uploaded to the mother ship, new downloaded code updates as they become available, etc etc -- then, it appears Tesla allows what remains to be filled-up with MP USB pointers and metadata for your music. Tesla sadly does not seem to put in any hard tests or notifications when it runs out of memory, so as you find, MP USB scan can resimply slow to a crawl and/or MP may eventually crash and try rescanning again in a sometimes endless loop. IMO those sort of variables are why different owners with different Tesla and builds, even at different times, can seem to load more or less tracks for use with USB and maintain a stable environment while others cannot. The problem is compounded because everyone's metadata is different on every track -- some having more or less than others -- and every character of that, for each tag MP USB uses, has to go into available CID memory somewhere. There is no other place for it to go as more robust computers running something like macOS or Windows with their paging/swap ability that happens under the covers using your built-in SSD or HDD.
Net is, when you have this "USB scan slowing to a crawl" issue, it's an indication you have too many tracks and/or too much metadata on your USB device for available memory on your Tesla. You need to reduce one or the other, or both, to get to a sweet spot that works better in your specific Tesla. Reducing the SIZE of the music itself isn't a significant concern when it comes to scan time -- never has been in my view and it's why I tend to ignore comments from others about they have "xxxGB" of music on a USB device. Flattening the directory structure on your USB device and even reducing the length of actual directory and filenames will give some little relief as that too has to go into memory somewhere and may have smaller or larger implications dependent upon how efficient Tesla is internally with their USB mapping -- so if you're robust in your naming conventions, that's great for other environments, but not in your Tesla if you are memory constrained. My posts upthread using dBpoweramp are how I have elected to automate all that over time reducing directory/file naming and metadata to what is really needed for me to use the MP USB interface the way I do. I then reduced the number of tracks on my USB SSD to around 7K these days. While I could originally get more than 15K scanned in if I were willing to wait more than an hour 3+ years ago, as new firmware releases have been introduced, my understanding has increased, and my tolerance for unexpected CID/MP crashes, freezes and reboots has decreased, I have reduced the number of tracks to maintain what I consider as stable environment as possible, and something that will always scan in 10-12 minutes upon reboot.
Good luck with your choices.
There are many upthread posts on this. From my more detailed testing years ago (documented upthread), I believe the basic issue is as your CID runs out of available memory, it begins to "thrash" (old mainframe term) wasting time trying to move memory around and attempt to open up space, so more things like additional pointers to tunes on your USB device can be scanned in. BTW, a faster USB device isn't going to help much with the time it takes to scan data into your MS -- the basic interface in your (and my) MS is USB 2.0, so if you use a faster USB 3.x device, that benefit is only as you create/manage your music on the device via your Mac or PC.
E.g. original MS like mine had 2GB of CID memory that has to house most Tesla code (which grows with every release and addition of useless Easter eggs as we again received with this last drop), various working areas, nav maps, destinations and history, phone contacts, any data being collected and/or uploaded to the mother ship, new downloaded code updates as they become available, etc etc -- then, it appears Tesla allows what remains to be filled-up with MP USB pointers and metadata for your music. Tesla sadly does not seem to put in any hard tests or notifications when it runs out of memory, so as you find, MP USB scan can resimply slow to a crawl and/or MP may eventually crash and try rescanning again in a sometimes endless loop. IMO those sort of variables are why different owners with different Tesla and builds, even at different times, can seem to load more or less tracks for use with USB and maintain a stable environment while others cannot. The problem is compounded because everyone's metadata is different on every track -- some having more or less than others -- and every character of that, for each tag MP USB uses, has to go into available CID memory somewhere. There is no other place for it to go as more robust computers running something like macOS or Windows with their paging/swap ability that happens under the covers using your built-in SSD or HDD.
Net is, when you have this "USB scan slowing to a crawl" issue, it's an indication you have too many tracks and/or too much metadata on your USB device for available memory on your Tesla. You need to reduce one or the other, or both, to get to a sweet spot that works better in your specific Tesla. Reducing the SIZE of the music itself isn't a significant concern when it comes to scan time -- never has been in my view and it's why I tend to ignore comments from others about they have "xxxGB" of music on a USB device. Flattening the directory structure on your USB device and even reducing the length of actual directory and filenames will give some little relief as that too has to go into memory somewhere and may have smaller or larger implications dependent upon how efficient Tesla is internally with their USB mapping -- so if you're robust in your naming conventions, that's great for other environments, but not in your Tesla if you are memory constrained. My posts upthread using dBpoweramp are how I have elected to automate all that over time reducing directory/file naming and metadata to what is really needed for me to use the MP USB interface the way I do. I then reduced the number of tracks on my USB SSD to around 7K these days. While I could originally get more than 15K scanned in if I were willing to wait more than an hour 3+ years ago, as new firmware releases have been introduced, my understanding has increased, and my tolerance for unexpected CID/MP crashes, freezes and reboots has decreased, I have reduced the number of tracks to maintain what I consider as stable environment as possible, and something that will always scan in 10-12 minutes upon reboot.
Good luck with your choices.
