Comprehensive USB Bug List

[f-stop]

Unfortunately, all the things you describe sound familiar to me as a Model 3 owner.

Still, I am very happy to be able to load so much music into the car, have a giant touch screen to select it, and an awesome sound system to play it.

It would be nice to get some of those bugs fixed, but I am still thinking I like this system better than anything else I could get. [...]

Thanks @TEG for an M3 owner's perspective on the USB player. I guess on balance overall I'm also glad there is a USB music player in the Model S - being able to play my own large music collection (when it works) beats a single-disc CD player like my previous car had and is far better than listening to the poor selection of local FM radio stations. Although I do listen at times to AM radio for local live sports broadcasts. BTW for that reason, not sure I like that the M3 has ditched AM radio .

Here's how I routinely use the USB music player in the MS
- select USB / select Songs / scroll down and select some random song in the list, and hit shuffle play
I have this sequence in muscle memory as I have to repeat it so frequently, almost every time I get back in the car.

Every time I park the car and then return to it later, usually one of the following happens, in order of most frequent to least:

a) No music playing. The USB tab doesn't show up on the touchscreen at first, until maybe 10-20 seconds later. However no rescanning of the USB is required, it just reappears. At that point, music still not playing, no particular audio source selected, and I must select something to start the music again.
b) The previously playing song immediately resumes at the point it left off (Hooray!!)
c) The wrong audio source is selected when returning to the car. Usually it's the AM radio is playing the first (left) station on the favourites list
d) No music playing. USB tab doesn't show up on the touchscreen. A minute may pass, then the USB tab appears but a rescan of the USB begins. With ~7000 tracks, it takes several minutes to complete - rescan seems a bit faster after one of the recent firmware updates, but still takes several minutes to reach 100% in my car (MCU1). No audio source is selected (even after USB rescan completes), so I must reselect something to start the audio

Similar behaviour with Slacker streaming audio - upon returning to the car, sometimes a track resumes where it left off, other times no audio source or the wrong audio source selected.

Of course there's a handful of other longstanding bugs in the media player, but this general startup behaviour is the most annoying since it affects almost every entry into the car. Is it too much to ask that the player reliably just resume where it left off every time? Apparently so (hmm, maybe it's rocket science...)

 

[TEG]

All of those random "didn't go back to playing the same song on the flash drive" things seem to happen to me in Model 3.
Usually it seems to switch to Bluetooth (trying to play from phone) most frequently.

I have put all my music in folders, so the usual ritual is push source selector ... change to USB ... Pick folders and look through the list for the genre I feel like playing now (I sorted my music into folders by genre/type/theme). Then scroll through the list and hit something randomly and then let it play (in order) starting from there.

On long road trips is is nice to just let it churn through a folder.

But my usually daily around-town short trip routine has me only getting through a couple of songs before I have to start over when I restart the car for my next drive.

 

[BertL]

All of those random "didn't go back to playing the same song on the flash drive" things seem to happen to me in Model 3.
Usually it seems to switch to Bluetooth (trying to play from phone) most frequently.

I have put all my music in folders, so the usual ritual is push source selector ... change to USB ... Pick folders and look through the list for the genre I feel like playing now (I sorted my music into folders by genre/type/theme). Then scroll through the list and hit something randomly and then let it play (in order) starting from there.

On long road trips is is nice to just let it churn through a folder.

By my usually daily around-town short trip routine has me only getting through a couple of songs before I have to start over when I restart the car for my next drive.

I'm sorry to hear M3 has many of the same failures we have had in MS/MX for a very long time. It does though suggest there is a lot of common MP USB code between the models, despite the different processors and memory (at least 3 variants now across the fleet) so perhaps there is some remaining hope we'll still see improvements as more new owners formerly report the bugs and their displeasure to Tesla -- I just hope they do it formerly, vs only being vocal on forums or just ignoring the issues.

 

[TEG]

For what it is worth, I did get confirmation that Tesla Media Team does have a defect report for failure to resume reliably from USB and it is noted as having received multiple customer reports of requests to escalate.

I also heard something about "major media player update" coming along at some point in the future. So they may be waiting/hoping that some 3rd party library update helps solve this.

This is the one and only time I actually tried to track down someone at Tesla that would listen directly to a plea for help in their software. It is that important to me.

 

[aesculus]

This is the one and only time I actually tried to track down someone at Tesla that would listen directly to a plea for help in their software. It is that important to me.

Can you use that effort to have them fix the Album Artist problem? To me that is the biggest issue. I could stand hearing the same stuff over and over again if it was in the right order and grouped properly.

 

[TEG]

Can you use that effort to have them fix the Album Artist problem? To me that is the biggest issue. I could stand hearing the same stuff over and over again if it was in the right order and grouped properly.

No, I don't have an open channel. I just had bumped into someone connected and had a one time chance to bring up something.

 

[neroden]

Yeah, the failure to provide basic functionality (like playing a compilation album in the right order, or playing an album gapless) is really disgraceful.

I've concluded that Tesla's software is substandard. This is an opening for a competitor, should one choose to take it: provide a media player which actually works right, and they'd steal some of Tesla's business. Sadly none have done so yet.

 

[f-stop]

look what Elon just tweeted: a call for video game developers...

Elon Musk on Twitter

Now, if only they hired someone to fix the Media Player!

 

[aesculus]

Now, if only they hired someone to fix the Media Player!

Somebody needs to respond to that tweet just as you state!

 

[David29]

look what Elon just tweeted: a call for video game developers...

Elon Musk on Twitter

View attachment 322249


Now, if only they hired someone to fix the Media Player!

Agreed. Someone has their priorities upside down.

 

[BertL]

Back in the Tesla Twilight Zone

As mentioned upthread, after months of thinking I had escaped the Zone -- or at least learned to live with relatively infrequent unexpected USB rescans -- 2018.24.1 seemed to start causing the problem for me on a more frequent basis, while nothing on my side changed at all -- not even physically unplugging my USB SSD. Last week, 2018.26 became available, which I installed. Phewwww... Not good. I've had several unexpected rescans since, but this morning:

• My MS had been sitting in my garage for a couple days, plugged into my HPWC
• I entered my MS, and there was no music playing even though that's how I left it a couple days before. Hummm.
• Upon inspection and touching "USB" at the top of MP, my USB SSD showed it had 447GB of space (as it normally does), but ZERO tracks (which is odd, since my SSD contains the same 7K tracks it has had for months)
• So, I backed out, drove in silence to my close-by destination, then performed a 2-wheel CID reboot after I parked so the USB rescan would complete while I was away
• Upon return to my MS a few minutes later, USB music was playing when I opened the door, and IIRC was back on the same song I had left it a few days before when I parked in my garage

Well, that's a new bug variation for me: A failed unexpected rescan where no tracks are identified on my USB device that has tracks that played before, but simply rebooting the CID and forcing a manual rescan works around this latest failure.

In closing: I wonder if other owners will 1) Complain if they find any bugs in Elon's (dumb) new Atari Games, and 2) If Tesla will then fix those bugs faster than long-standing MP problems. Maybe yes; Maybe no. Sorry, I just had to end with a snarky comment about the latest Easter Egg additions while long-standing basic MP bugs and functionality continue to be ignored across the entire Tesla fleet.

 

[f-stop]

• Upon inspection and touching "USB" at the top of MP, my USB SSD showed it had 447GB of space (as it normally does), but ZERO tracks (which is odd, since my SSD contains the same 7K tracks it has had for months)

Interesting. I'm on 2018.26 and just the other day I saw this exact thing for the first time ever in my car.

Got in the car and USB was not playing (predictable and frequent occurence in itself), it took a few moments for the USB tab to reappear and then it showed 60-ish GB of space on the inserted USB but zero tracks. Had to do a reboot to restore things (didn't pay attention to see what if anything was playing when things restored).

In the past week I have seen one other random spontaneous rescan, which I hadn't seen in many months. Otherwise on this firmware version I notice all the same old USB bugs, same predictable misbehavior.

Someone needs to propose a "video game" where the driver inserts a USB drive and the car magically plays music without interruption...

 

[X Fan]

FWIW: big difference between my early 3000 series X vs. new 103,000 one.

First one had pretty constant rescans.....this one, none (unless rebooting & its done at lightening speed) during a month of ownership. I just get in the X and USB music is ready.

I'm guessing that they're seeing rescans as a non issue for new MCU cars and improving the player is just not an A or B priority.

IMO, they do need to re-think their approach re: music. Tunein has become less viable with stations leaving in droves to other platforms (latest was all the former CBS stations to Radio.com), Slacker config is less than desired, XM is sub-optimal & of course USB weaknesses.

 

[BertL]

Back in the Tesla Twilight Zone

As mentioned upthread, after months of thinking I had escaped the Zone -- or at least learned to live with relatively infrequent unexpected USB rescans -- 2018.24.1 seemed to start causing the problem for me on a more frequent basis, while nothing on my side changed at all -- not even physically unplugging my USB SSD. Last week, 2018.26 became available, which I installed. Phewwww... Not good. I've had several unexpected rescans since, but this morning:

• My MS had been sitting in my garage for a couple days, plugged into my HPWC
• I entered my MS, and there was no music playing even though that's how I left it a couple days before. Hummm.
• Upon inspection and touching "USB" at the top of MP, my USB SSD showed it had 447GB of space (as it normally does), but ZERO tracks (which is odd, since my SSD contains the same 7K tracks it has had for months)
• So, I backed out, drove in silence to my close-by destination, then performed a 2-wheel CID reboot after I parked so the USB rescan would complete while I was away
• Upon return to my MS a few minutes later, USB music was playing when I opened the door, and IIRC was back on the same song I had left it a few days before when I parked in my garage

Well, that's a new bug variation for me: A failed unexpected rescan where no tracks are identified on my USB device that has tracks that played before, but simply rebooting the CID and forcing a manual rescan works around this latest failure.

In closing: I wonder if other owners will 1) Complain if they find any bugs in Elon's (dumb) new Atari Games, and 2) If Tesla will then fix those bugs faster than long-standing MP problems. Maybe yes; Maybe no. Sorry, I just had to end with a snarky comment about the latest Easter Egg additions while long-standing basic MP bugs and functionality continue to be ignored across the entire Tesla fleet.

Background: Was thinking about this yesterday, and had somewhat forgotten part of the investigative work I did nearly 2 years ago (some documented upthread closer to the beginning, and the rest in even older threads) which led me to believe how too many tracks (not their actual size, but more the aggregate metadata) would lead to increased MP instability because of CID memory constraints... and the days of work I then went through to systematically figure out what I call my "sweet spot" as to how many tracks I could have in my MS before MP instability became excessive, which in my case was just over the 7K mark.

My Latest Hypothesis: I have been running with about 7K tracks on my USB device in my MS for somewhere around 2 years. After reducing to that number and reducing metadata on all my individual tracks, MP stability increased substantially, and was further improved when I switched to using only MP3 VBS which seemed to fix my stuttering issues that I occassionally had with FLAC, and MP not being able to remember where it was in a track as I got in and out of my MS.

In those same 2 years, Tesla has delivered more than a dozen firmware updates, which I'm sure must have increased it's own memory use within the fixed 2GB of CID memory on my MS, and I surmise takes first priority over what is left over for user-controllable phone contacts, nav history and MP metadata (that seem to have no software-imposed limits like other mfgrs provide). My MP instability began to increase (more than normal) to an unacceptable level again 2-3 firmware releases ago, and seems to be distinctly worse since the last release was installed this past week. It feels like I've gone over some tipping point in terms of MP reliability. Perhaps there were Tesla code changes which have caused the latest round of problems, but I doubt very much Tesla has spent any time on MP given their focus on M3, AP 2+, and Atari Games.

So, yesterday afternoon I began work to further reduce the number of tracks on my USB SSD to see if I can make my MP USB environment a little more stable again. I'm not going to take the time to do this as granular as I did 2 years back, but since it's been months since I last built my Tesla USB SSD, I decided to use the opportunity to pick up some of my newer music and the dBpoweramp encoding improvements which have become available since my last conversion, while keeping everything else the same as I've documented before (minimal meta, only MP3 VBS filetypes). I built a new iTunes playlist that logically extracted just over 6K tracks from my master music library -- which with some quick math, should give me an approx 14% reduction in metadata memory consumption when it's in place. dBpoweramp has been processing on my quad-core 4.0 gHz iMac at 100% CPU for close to 12 hours, and has perhaps another 2 days before the compute intensive process is complete. I'll replace these new tracks onto the same USB SSD that resides in my MS and report back here in a few days after I can develop first impressions. If I'm right, reducing the number of tracks on our USB devices once again, may be something others encountering increased MP failures in recent weeks may also want to try. I'll let you know ...more to come!

 

[thecloud]

To offer up a data point that may corroborate your theory, I have been rolling along with ~3K tracks on a 64GB Kingston USB stick, also for roughly the past 2 years, and have never had the constant rescanning problems that others have reported. Two-thirds of this collection consists of FLAC files (level 3 compression), and the other third is MP3 (320 Kbps, constant bit rate). All files have embedded cover art in JPEG format, around 100 Kb per image, as well as complete metadata (artist/album/year/composer/genre/etc.)

The bug where the media player cannot remember its place in a FLAC file after going to sleep is still present, of course, but since my files are music tracks and not audio books or podcasts, I decided that downsampling those tracks to MP3 was not worth it just to have the car pick up in the middle of a song when I return to the car.

Now, I also had a few FLAC files that would stutter or quit after a few seconds with "Loading Error". In each case, it turned out they had an unusually high bit rate (>1000Kbps). They had no issues after being re-encoded as MP3 320 Kbps.

 

[BertL]

HINT for Apple Music Subscribers who want to extract music for use via Tesla MP USB

Background: As I expected before I more recently subscribed to Apple Music, it works really well in it's own world, integrating with my previously purchased 28K track iTunes music library, while allowing me to play any other track in Apple Music on any of my Apple devices. That's great and has opened-up a new world of music to explore. I also went into this subscription knowing Apple Music (like any other music subscription service) wouldn't work well with my preferred use of Tesla MP USB because tracks I don't really "own", but only have access to because of a subscription, use DRM which prevents those tracks from playing in unsupported players like my Tesla. (I don't want to, but realize I could ignore USB and instead use Bluetooth to stream Apple Music from my iPhone.) Anyway, I thought things would work fine if I simply purchased a very small subset of new tracks I first found and added from Apple Music, allowing me to then extract those non-DRM tracks for use on my Tesla USB SSD almost the same as I have done many times before ...but ahhh, "almost the same" is where the bug-a-boo comes in.

As discussed recently, I've been rebuilding my Tesla USB SSD in the same manner I have many times, using a custom iTunes playlist which extracts a selection of non-Apple Music (the ones without DRM)... then use my previously documented Export for iTunes and dBpoweramp process to convert those files before copying them onto my Tesla USB SSD. After more than 2 days of processing when the process finally completed yesterday, I surprisingly found a handful of tracks had failed with oddly named files. I could only tell what tracks they were from album art and listening to the music itself, as there was almost no ID3 data associated with the tracks for some reason.

The issue appears to be: If you add a new Apple Music track to your iTunes library, it works fine across all Apple devices you're signed into. If you then go to the iTunes Store, purchase and download that same track to your iTunes library, again, all works great within the Apple iTunes world, and all the metadata appears to be there. BUT, upon close inspection of the physical track using non-iTunes tools, you'll find the physical (and now purchased) track contains only the AAC music, and almost no ID3 metadata we as a user wants to use -- more specifically, the basic tag data such as track and album name, track number, etc appear to be maintained somewhere only iTunes and Apple's players can access, not physically part of the track as you really need when you want to extract it for playback on a non-Apple player.

To resolve this: When you want to purchase an Apple Music track to use with your Tesla, which will physically contain all the ID3 data you need for an extract, do this:

• Add a track from Apple Music to your library
• When you later decide you want to use that track in your Tesla (or some other non-Apple media player), after selecting the track in iTunes on your Mac or PC
  • Use "Show in iTunes Store" to purchase the track as you always have
  • Now, very importantly, use "Remove Download" on that same track, which will keep any love/rating, play count, etc. info
  • Then, just click the iCloud download icon to download that track with all it's imbedded metadata, and you're good to go. Extract away.

NOTE: If you subscribe to Apple Music, but have never added a particular track to your library, and first go to the iTunes Store to make the purchase as you always have, all works as normal with ID3 data part of the track... IMHO, mark it up as a weird thing iTunes is doing under-the-covers that most users will never care about, and is a NON-Tesla problem. ​

-----

BTW... I have my new reduced-number-of-tracks SSD in my MS, but not long enough to form an opinion on it's value. As promised, more to come on that in a few days...

 

[BertL]

Background: Was thinking about this yesterday, and had somewhat forgotten part of the investigative work I did nearly 2 years ago (some documented upthread closer to the beginning, and the rest in even older threads) which led me to believe how too many tracks (not their actual size, but more the aggregate metadata) would lead to increased MP instability because of CID memory constraints... and the days of work I then went through to systematically figure out what I call my "sweet spot" as to how many tracks I could have in my MS before MP instability became excessive, which in my case was just over the 7K mark.

My Latest Hypothesis: I have been running with about 7K tracks on my USB device in my MS for somewhere around 2 years. After reducing to that number and reducing metadata on all my individual tracks, MP stability increased substantially, and was further improved when I switched to using only MP3 VBS which seemed to fix my stuttering issues that I occassionally had with FLAC, and MP not being able to remember where it was in a track as I got in and out of my MS.

In those same 2 years, Tesla has delivered more than a dozen firmware updates, which I'm sure must have increased it's own memory use within the fixed 2GB of CID memory on my MS, and I surmise takes first priority over what is left over for user-controllable phone contacts, nav history and MP metadata (that seem to have no software-imposed limits like other mfgrs provide). My MP instability began to increase (more than normal) to an unacceptable level again 2-3 firmware releases ago, and seems to be distinctly worse since the last release was installed this past week. It feels like I've gone over some tipping point in terms of MP reliability. Perhaps there were Tesla code changes which have caused the latest round of problems, but I doubt very much Tesla has spent any time on MP given their focus on M3, AP 2+, and Atari Games.

So, yesterday afternoon I began work to further reduce the number of tracks on my USB SSD to see if I can make my MP USB environment a little more stable again. I'm not going to take the time to do this as granular as I did 2 years back, but since it's been months since I last built my Tesla USB SSD, I decided to use the opportunity to pick up some of my newer music and the dBpoweramp encoding improvements which have become available since my last conversion, while keeping everything else the same as I've documented before (minimal meta, only MP3 VBS filetypes). I built a new iTunes playlist that logically extracted just over 6K tracks from my master music library -- which with some quick math, should give me an approx 14% reduction in metadata memory consumption when it's in place. dBpoweramp has been processing on my quad-core 4.0 gHz iMac at 100% CPU for close to 12 hours, and has perhaps another 2 days before the compute intensive process is complete. I'll replace these new tracks onto the same USB SSD that resides in my MS and report back here in a few days after I can develop first impressions. If I'm right, reducing the number of tracks on our USB devices once again, may be something others encountering increased MP failures in recent weeks may also want to try. I'll let you know ...more to come!

TESTING THE HYPOTHESIS: EARLY RESULT

In two recent posts I discussed my hypothesis about my perceived increase in USB rescans and general instability that began increasing in frequency again after each of the past 2-3 firmware updates.

It’s approaching nearly a week since I reduced the number of tracks on my USB SSD (~13% less tracks: 7103 to 6213) to see if perhaps MCU1/CID memory constraints had come back into play. I am pleased to report I have had ZERO reboots, rescans, or freezes in the past few days — whereas I had gotten to the point having those problems approx every-other-day and sometimes multiple times per day in the past few weeks.

I therefore suggest if anyone else is also seeing increased rescans or general MP USB instability, when you’ve changed nothing else (including keeping phone contacts and nav history to a minimum), you do three things in this order of importance:

1. Further reduce the number of tracks on your USB device
2. If you’ve not done it already, seriously consider reducing the amount of metadata within each of your tracks — accomplishing as much as you can similar to what I have been doing with my dBpoweramp metadata reduction method (see links below). Doing so will allow you to maintain more music tracks in your Tesla.
3. Make sure the file structure on your USB device is as flat as makes sense for the way you use MP. (No matter how Tesla deals with this in it’s code and therefore how big of a deal this is or isn’t, it must effect fixed memory use to some degree. File and directory names have to be kept in memory one way or the other as pointers from each track's metadata back to where it exists on the USB device. I suggest 2-3 max directory depth for all of your tracks, and keep your actual file and directory names as short as possible. I personally maintain a top level directory on my USB SSD with a single character filename I change each time I update my USB device, with each unique album as its own subdirectory containing related tracks under that — aka 2-deep.)

GUESSTIMATING THE IMPACT OF THESE CHANGES IN BERT’S MS

(It’s long-winded and perhaps too detailed for many, so read the bold summary points at the bottom if you want the net.)

The objective with my troubled MS USB MP experience has always been to maintain a maximum number of tracks from my master music library in my MS, in a mostly lossless encoding format, while being able to use Tesla’s MP interface as the primary way to access my music (vs folder view) — balanced with minimizing unexpected CID reboots, MP USB rescans or freezes that MP occasionally does. We’ve debated elsewhere about lack of MP USB functionality, and buggy code that Tesla sadly ignores, but my mission with this has always been to improve what I can as a Tesla owner.

Most of us don’t have access to Tesla’s code, so we can only observe the results we see and try to correlate them to our external view of “what’s changed”. I have done a lot of trial-and-error, combined with some targeted systematic testing, while considering observations I and others here have made (thank you!) to develop process and procedures that appear to make a difference against my MP objectives. That being said, there are still too many variables to speak in absolutes what will and won’t work for each of us, especially as firmware updates may change the game each time they are applied.

I thought the following detail might be helpful to any owner that remains on the fence considering either reducing the number of tracks on their USB device, or the more involved process to decrease metadata against copies of their tracks for use in their Tesla. So, here’s a swag of my situation that hopefully provides at least an order of magnitude how CID memory usage is likely reduced through my suggestions, and therefore contribute to the benefits I see. (We of course wouldn’t be needing to do either of these things if Tesla’s code was simply more robust AND set guaranteed maximums on external devices like other mfgrs do with their media players.) ONE LAST CAVEAT: There are many variables we can only speculate about, so putting math against this is troubled from the start if anyone tries to be overly analytical — IOW, don’t clobber me on the specifics -- try to stick to the concepts.

Reducing Metadata

• I believe my metadata and album art reduction methods (see links below) is substantial in terms of using less memory within the 2GB CID that Tesla uses for so many other things. We don’t know what amount of memory is available to us before all sort of bad things begin to happen, or how well MP USB does consolidating similar tag data and file pointers across tracks to conserve physical memory.
  • In my case, tag data within the 7 ID3 tags used by the MP UI is reduced by roughly 60% compared to the original data in my highly curated master iTunes music library. That number varies greatly from track-to-track especially by genre, e.g. in many of my compilation albums (which is more than 50% of my library), there are almost always multiple artists on every track — sometimes more than 100 bytes worth in a single ARTIST tag, but my Tesla-reduction process replaces that string with a single ALBUMARTIST which is ~10-15% of the original size for MP to then deal with.
    • Besides helping the standard UI work better IMHO, the other side benefit of my replacing ALBUMARTIST as the contents of ARTIST on my USB device, is ARTIST tag data becomes common across more tracks, so hopefully Tesla's "compression" algorithms are able to save even more memory vs. if ARTIST remained as distinct and as detailed as I enjoy with my master iTunes library and copies across all my iOS devices.)
  • Album Art which MP uses is reduced to ~25% of the physical size a majority of tracks in my master library contain (typically 1000x1000 in my master tracks), and if there is multiple album art as the ID3 spec allows, the routine throws all of them away except the first front cover during the one-time conversion, before MP eventually has to read and then ignore them every time the track is accessed in my MS.
  • With several dozen spot-checks, after running my meta reduction process, I estimate each track on my USB device has an average ~260 bytes of unique metadata (which includes an estimated percentage of a single mini-album-art picture the MP interface appears to build and maintain in memory for each unique album for use in it’s UI lists.)
• A side benefit reducing metadata, including album art, on a MP USB device means less processing for the MCU to read, throw-away what isn’t used by the interface, and reduce in-size (album art) what I believe in my case is an already over-burdened original MCU1/CID processor — therefore providing me faster scan/rescan times with the same number of tracks.

Number & Size of Tracks

• NUMBER OF TRACKS: Reducing the number of my reduced-metadata tracks from 7107 to 6213 represented ~13% reduction in terms of volume.
• SIZE OF TRACKS
  • I have never believed the physical file size of a track or the aggregate size of the collection on the USB device is a big deal, as MP appears to read all tracks and only retain select metadata during scan/rescan, then re-reads the individual file encoded music track (and likely the Album Art from one of the tracks in the same album again) each time upon playback.
  • While the number of bytes for metadata for a track is a lot smaller than the encoded music most of the time, metadata is something we can effect and is what ends up consuming limited MCU memory, even if the track is never played. Upon inspection, you’ll likely find a dozen or more tags in each of your master music files, all of varying lengths. The current MP USB interface appears to only use 6 of those ID3 metadata tags, plus the first Front Album Art if one exists in your track (and then it maintains only 1 image for each unique album, even when tracks have different front album art as the ID3 spec allows).
  • As mentioned above, my process reduces the length of data within the ARTIST tag, which helps this memory issue and provides a workaround allowing the standard Tesla UI to work better IMHO, and also throws away nearly all of the other ID3 tags any track may have the current MP UI won’t use, to help reduce processing time MP has to do later on…

Summary

• My meta reduction process alone, that I've been using for some time, allows me to maintain perhaps 8% more tracks in my MS using the same amount of memory, than if I used my original highly curated tracks copied onto a USB device with original metadata.
• Reducing 894 tracks x ~260 bytes of metadata after my reduction process, means I gave back, an uncompressed ~226KB within what I expect MP needs to manage of the remaining 2GB MCU1.
  • REMEMBER:
    • Within the 2GB every MCU1 has, Tesla first stores it’s code, settings & working areas, our phone contacts, Nav history, Nav tiles & traffic info, AP data being brought down and sent up, any in-progress REPORTs with CID+IC shots, any downloaded next firmware version when one exists, etc… and it acts like MP USB then gets what’s left over to house our USB MP metadata and pointers back to the USB file structure — especially since Tesla has no documented upper limits to any of the user-controllable items. As such, IMO the maximum number of USB music tracks we can really have is likely changing all the time, explaining why some of us get spurious failures out-of-the-blue when we have changed nothing ourselves.
    • …and we don’t know how good a job Tesla is doing in their code “compressing” or handling duplicates of the same tag data found across multiple tracks in an effort to conserve memory, and similarly how they deal with the linkage of that metadata for each track back to the USB file structure so the music can eventually be played back. It’s why the total benefit I suggest is only a rough estimate — it’s just a swag at a reality we don’t understand.
• Could I add more tracks? Perhaps. It would take a lot more granular testing I’m not going to do, and then it remains subjective as to our tolerance when too many rescans, freezes, etc are too much for each of us — and with every Tesla firmware release, or change of tracks and their metadata on our USB device, the variables change and testing is required once again.
• Will your “sweet spot” of how many tracks you can maintain be different than mine? Absolutely, even if you did have an identical MS and my same USB SSD in your Tesla — there are just too many other variables and unknowns to be more precise.

...and if you read all that, you get a virtual gold star! Good luck and happy USB listening once again.




RELATED POSTS:

• Bert’s dBpoweramp meta transformation process 9-17-2017, including a list of what those settings do if you want to perhaps pick-and-choose or do something similar via another method to reduce metadata on your Tesla tracks
  • Comprehensive USB Bug List

• ...but please use the later version of my dBpoweramp DSP settings attached to this post, as it is more robust than the version from last September
  • Comprehensive USB Bug List

 

[f-stop]

@BertL interesting and informative analysis, as always. I will look into some of these steps to reduce MP memory usage. Before your latest post I had been thinking of things to try along that line, too.

I therefore suggest if anyone else is also seeing increased rescans or general MP USB instability, when you’ve changed nothing else (including keeping phone contacts and nav history to a minimum), you do three things in this order of importance:

1. Further reduce the number of tracks on your USB device
2. If you’ve not done it already, seriously consider reducing the amount of metadata within each of your tracks — accomplishing as much as you can similar to what I have been doing with my dBpoweramp metadata reduction method (see links below). Doing so will allow you to maintain more music tracks in your Tesla.
3. Make sure the file structure on your USB device is as flat as makes sense for the way you use MP. (No matter how Tesla deals with this in it’s code and therefore how big of a deal this is or isn’t, it must effect fixed memory use to some degree. File and directory names have to be kept in memory one way or the other as pointers from each track's metadata back to where it exists on the USB device. I suggest 2-3 max directory depth for all of your tracks, and keep your actual file and directory names as short as possible. I personally maintain a top level directory on my USB SSD with a single character filename I change each time I update my USB device, with each unique album as its own subdirectory containing related tracks under that — aka 2-deep.)

one observation - last week I decided to try flattening my USB file/folder structure, thinking that might help things. Originally my USB folder structure was 2 folders deep - at the root level of the device were folders for every individual artist, then within each artist separate folders for each album of that artist, and finally the tracks of that album within that. In total my USB contains ~6000+ tracks. So I eliminated one level of the hierarchy, and now my USB simply has folders for every artist, then within each artist's folder ALL the tracks from all that artist. This has the added benefit to allow playing the USB MP by Folder, ie. pick any artist and shuffle play ALL the tracks by that artist - something that the MP doesn't seem to otherwise easily let you do.

anyhow, in the week or so I've been trying this, I've notice no difference so far in the (mis)behaviour of the USB media player.

next step I will look at some of the other ideas, perhaps simply deleting some of the artists/tracks, and then some of your other metadata ideas.

 

[f-stop]

• Upon inspection and touching "USB" at the top of MP, my USB SSD showed it had 447GB of space (as it normally does), but ZERO tracks (which is odd, since my SSD contains the same 7K tracks it has had for months

A new observation... back on Aug4 I reported this same behaviour for the first time, showing the correct number of GBs storage on my USB drive but zero tracks. Well it happened a 2nd time today... but this time an important difference: after rebooting the MCU to force a rescan to clear the "zero" tracks and restore proper USB playback, I noticed that all my saved Favorite tracks on the USB were now gone

note this was after I had recently reduced my USB drive's file/folder hierarchy by one level, and also after I manually rebuilt my USB Favorites list since changing the hierarchy structure wiped out my original favorites from before. An MCU reboot never before cleared all my USB Favorites so I have to think its related to the "zero tracks" issue. Still on 2018.26

 

[BertL]

A new observation... back on Aug4 I reported this same behaviour for the first time, showing the correct number of GBs storage on my USB drive but zero tracks. Well it happened a 2nd time today... but this time an important difference: after rebooting the MCU to force a rescan to clear the "zero" tracks and restore proper USB playback, I noticed that all my saved Favorite tracks on the USB were now gone

note this was after I had recently reduced my USB drive's file/folder hierarchy by one level, and also after I manually rebuilt my USB Favorites list since changing the hierarchy structure wiped out my original favorites from before. An MCU reboot never before cleared all my USB Favorites so I have to think its related to the "zero tracks" issue. Still on 2018.26

I have lost my favorites as well as last-accessed USB icons (e.g. genre or artists I’ve accessed via the MP interface) in MP from time-to-time across numerous firmware releases without changing (or even unplugging) my USB SSD, but have not figured out a pattern to it.

I don’t use Slacker much except briefly at Thanksgiving/Christmas time, so those favorites and last used icons tend to disappear when others do after something happens past the holidays. OTOH I can’t remember when I’ve completely lost my 3 FM station favorites that seem to always stick around in MP across all these strange occurrences, but when the others are lost, they are the only thing to initially remain without accompanying station graphics they once had (ie they show the default headphone gray logo until some days later when two of them are replaced with station logos).

I mark it all up to Tesla’s general MP wierdness, on-going USB instability, and my just being trapped in Tesla’s Twilight Zone that I so desperately keep trying to escape from — where Elon keeps me trapped because he’s on to his view of bigger and better things, from the basics I expected to work in the first place when I purchased my MS nearly 3 years ago.