Comprehensive USB Bug List

[BertL]

Not necessarily true. I have 2.52.22 (like most people here) and I have zero reloads unless I remove and then reinsert the stick. I don't think the cause of reloads is known yet.

...but IIRC from your former posts, your general USB problems have also seem to be reduced the last few weeks/months, compared to before that, right (so it's not a .22 fix, I suspect)? ...and are you still using streaming music sources in addition to USB as much as you were? As @PaulR says, there are many variables.

I have USB music playing almost 100% of the time -- from the moment my door opens, until I get back out and close the door, except sometimes during rescan when I listen to FM until USB is available again. I very very rarely use streaming sources except in my former MP testing days. I'm also on .22, and as documented upthread, continue having a myriad of issues including two rescans over this past weekend. Yes, the problems are a bit different than what I was encountering last Fall, last Spring, or at delivery the year before that, but all are still unacceptable and take away substantially from my Tesla owner experience. It's not like I havn't tried to figure it out, or minimize impact upon myself to the degree I can -- but with the constant changes for good and bad Tesla throws at us (without release notes), it's a continually moving target I am no longer willing to try and keep up with. For me, I would not say Tesla is anywhere close to having delivered a quality MP USB experience as some are experiencing -- perhaps in-part because I use USB as exclusively as I do compared to some -- but then again, I put a lot less miles on my MS than many here (howz about 7.1K miles after 15 months? ), and most days when I do drive my MS, it's for short errands around town vs daily commutes and road trips others do. Yes, there are variables in each of our environments and in how Tesla's code responds to it. As I keep saying, I'm happy for those that are not encountering MP Issues... you're all fortunate and can move on to other things, while some of us remain stuck in our own set of Tesla USB challenges.

 

[f-stop]

Not necessarily true. I have 2.52.22 (like most people here) and I have zero reloads unless I remove and then reinsert the stick. I don't think the cause of reloads is known yet.

just to add a slightly different data point, I have had zero USB rescans (unless I remove and reinsert the stick) since I received the 2.50.114 update on 12/22. I received the 2.52.22 update a couple weeks after that and likewise it's still been stable re: no rescans. Normally I would use Slacker more than listen to USB, but ever since a couple weeks before the 2.50.114 update and through until now I've been listening to USB 100% of the time.

No idea why my luck is different than others, but as BertL mentioned there are many variables and it's unclear why the MP code seems to behave so inconsistently across users. Hopefully things will improve for everyone with 8.1, and not introduce a bunch of other MP bugs...

 

[X Fan]

Not necessarily true. I have 2.52.22 (like most people here) and I have zero reloads unless I remove and then reinsert the stick. I don't think the cause of reloads is known yet.

Well....I also have 2.52.22 and three reloads out of 6 trips today.....one in AM, one afternoon, one in trip to a show downtown.

When we left show (Kenny Rogers, not bad for almost 80), it ran smoothly....

First reload, 6 minutes, second, 5 minutes, third, 3 minutes.

 

[Alkettory]

@Alkettory - So many variables here to consider, but, perhaps, the most important is to know what firmware version you are on? The problem you are seeing was a common complaint here (re-scanning of the USB or SSD). The larger the drive/data base, the longer it takes to re-scan/re-load. The percentage you are seeing is the estimated percentage which the media player has reached as it tries to re-load the data. I and may others have previously experienced this (sometimes the re-loads seem to have forgotten our "favorites also) and when I installed my latest firmware update that problem seems to have stopped.

By the way, I am on 2.52.22. Using a 256 GB SSD.

Data points:

• I have had the MS since September 2016.
• I have been following this thread since shortly after I got the car.
• I have kept Energy Savings turned off since day one.
• I have 38,000 MP3 tracks on a 1TB SSD, all painstakingly tagged with dBpoweramp (Windows), and all with embedded 600x600 JPG artwork from AlbumArtExchange.com.
• I've only seen a single track display incorrect artwork. I did not look for a cause, but it was repeatable for that one track.
  
• I keep the 38,000 tracks on shuffle play (songs) continually.
• As others have pointed out, shuffle play is broken. The algorithm frequently resets its seed value, causing it to play through an identical sequence of songs. From a software standpoint, this should be trivial to fix. You create an index of tracks, shuffle it (like a deck of cards), persist it, then play though it. When you hit the end of the shuffled index, reshuffle.
  
• I have only ever unplugged the SSD twice, to add new tracks.
  
• I am currently on 2.52.22; however, I got an update notification this morning, so my version will change later today.
• I almost always get in the car at 4:46am in the morning.
• For software versions prior to 2.52.22, the Loading message was always at 7% at 4:46am, and at 7% or 8% by the time I made it to work 12 minutes later.
• For software version 2.52.22, the loading message is always at 49% when I get in the car at 4:46am, and at 58% or 59% by the time I get to work 12 minutes later. This tells me scans are indeed quicker with 2.52.22.
  
• For the first 3 or 4 days following a software update, I don't see the Loading message at 4:46am; instead, I have music.
• On those rare days when I go to work later (e.g., 8:00am), I have music.
• I have only seen one random CID reboot. That happened on a day trip to Columbus (100 mile trip each way) after the car had been playing music for about 3 hours.
• I am an experienced Software Engineer.

Based on the above data points, my guess is that, at least in my case, the car is performing time-based housekeeping. If the software would "adapt" and schedule the housekeeping at an earlier time, I believe my problem would be solved.

 

[BertL]

Data points:

• I have had the MS since September 2016.
• I have been following this thread since shortly after I got the car.
• I have kept Energy Savings turned off since day one.
• I have 38,000 MP3 tracks on a 1TB SSD, all painstakingly tagged with dBpoweramp (Windows), and all with embedded 600x600 JPG artwork from AlbumArtExchange.com.
• I've only seen a single track display incorrect artwork. I did not look for a cause, but it was repeatable for that one track.
  
• I keep the 38,000 tracks on shuffle play (songs) continually.
• As others have pointed out, shuffle play is broken. The algorithm frequently resets its seed value, causing it to play through an identical sequence of songs. From a software standpoint, this should be trivial to fix. You create an index of tracks, shuffle it (like a deck of cards), persist it, then play though it. When you hit the end of the shuffled index, reshuffle.
  
• I have only ever unplugged the SSD twice, to add new tracks.
  
• I am currently on 2.52.22; however, I got an update notification this morning, so my version will change later today.
• I almost always get in the car at 4:46am in the morning.
• For software versions prior to 2.52.22, the Loading message was always at 7% at 4:46am, and at 7% or 8% by the time I made it to work 12 minutes later.
• For software version 2.52.22, the loading message is always at 49% when I get in the car at 4:46am, and at 58% or 59% by the time I get to work 12 minutes later. This tells me scans are indeed quicker with 2.52.22.
  
• For the first 3 or 4 days following a software update, I don't see the Loading message at 4:46am; instead, I have music.
• On those rare days when I go to work later (e.g., 8:00am), I have music.
• I have only seen one random CID reboot. That happened on a day trip to Columbus (100 mile trip each way) after the car had been playing music for about 3 hours.
• I am an experienced Software Engineer.

Based on the above data points, my guess is that, at least in my case, the car is performing time-based housekeeping. If the software would "adapt" and schedule the housekeeping at an earlier time, I believe my problem would be solved.

Good PD analysis. Thx. I also was a programmer/systems guy back in the day, hence why I go off into detail minutia quite often.

To add to your thought, and while I can't analytically prove it, I do believe there is something to your "housekeeping" idea... I almost never have rescan issues when I do longer trips, but I go generally encounter rescans (and/or unexpected CID reboots and then a rescan) at some point when I run short errands (meaning 3-15 miles with sometimes 2-3 stops in a 30-60 min period of time). Rescans don't always happen for me as I get into my MS after it's been parked over night or for a day or two on some schedule, or if I've charged or not ...but then more often than not will happen after my first errand stop to the store when I get back into the car not 10 minutes later. Driver "environment", and I agree -- what Tesla is doing under the covers, somehow contribute to when the problems arise. (I bet if Tesla really wanted to fix this, comparing a number of our logs with the surrounding events would help narrow down the conditions. Ah, there I go. Wishful thinking again! )

 

[supratachophobia]

Well....I also have 2.52.22 and three reloads out of 6 trips today.....one in AM, one afternoon, one in trip to a show downtown.

When we left show (Kenny Rogers, not bad for almost 80), it ran smoothly....

First reload, 6 minutes, second, 5 minutes, third, 3 minutes.

I wonder if the power draw of some of these devices is triggering an insert/remove cycle unbeknownst to the driver?

 

[tomas]

I wonder if it has something to do with AP. I have NEVER had a rescan except at initial AM startup for a brief while til they fixed the energy savings, rescan bug. OTOH I have a 2012 with no AP... could I have more available memory? Could feature additions have put squeeze on memory?

 

[X Fan]

I wonder if the power draw of some of these devices is triggering an insert/remove cycle unbeknownst to the driver?

Hard to say; it is so unpredictable. When I went out for coffee this morning, it started right up and no issue on return.

Didn't run AP nor NAV on that trip......Very strange indeed.

 

[msnow]

Data points:

• I have had the MS since September 2016.
• I have been following this thread since shortly after I got the car.
• I have kept Energy Savings turned off since day one.
• I have 38,000 MP3 tracks on a 1TB SSD, all painstakingly tagged with dBpoweramp (Windows), and all with embedded 600x600 JPG artwork from AlbumArtExchange.com.
• I've only seen a single track display incorrect artwork. I did not look for a cause, but it was repeatable for that one track.
  
• I keep the 38,000 tracks on shuffle play (songs) continually.
• As others have pointed out, shuffle play is broken. The algorithm frequently resets its seed value, causing it to play through an identical sequence of songs. From a software standpoint, this should be trivial to fix. You create an index of tracks, shuffle it (like a deck of cards), persist it, then play though it. When you hit the end of the shuffled index, reshuffle.
  
• I have only ever unplugged the SSD twice, to add new tracks.
  
• I am currently on 2.52.22; however, I got an update notification this morning, so my version will change later today.
• I almost always get in the car at 4:46am in the morning.
• For software versions prior to 2.52.22, the Loading message was always at 7% at 4:46am, and at 7% or 8% by the time I made it to work 12 minutes later.
• For software version 2.52.22, the loading message is always at 49% when I get in the car at 4:46am, and at 58% or 59% by the time I get to work 12 minutes later. This tells me scans are indeed quicker with 2.52.22.
  
• For the first 3 or 4 days following a software update, I don't see the Loading message at 4:46am; instead, I have music.
• On those rare days when I go to work later (e.g., 8:00am), I have music.
• I have only seen one random CID reboot. That happened on a day trip to Columbus (100 mile trip each way) after the car had been playing music for about 3 hours.
• I am an experienced Software Engineer.

Based on the above data points, my guess is that, at least in my case, the car is performing time-based housekeeping. If the software would "adapt" and schedule the housekeeping at an earlier time, I believe my problem would be solved.

The question I have is if it was "housekeeping" why does it impact some cars but not others?

 

[BertL]

I wonder if it has something to do with AP. I have NEVER had a rescan except at initial AM startup for a brief while til they fixed the energy savings, rescan bug. OTOH I have a 2012 with no AP... could I have more available memory? Could feature additions have put squeeze on memory?

I truly believe memory mgmt is part (but not all) of the issue. I have for more than a year. IIRC, the CID has a fixed 2GB in pre-HW2 MS of memory for everything it has to do. Tesla seems to let everything vie for position in that fixed amount of memory -- it's operational code and working areas, and things owners can influence: Nav, Phone Contacts, Calendar, MP icons, favs, USB album art and all the track metadata (which can add up), etc. The more of each of those things you have, the more memory it has to consume somewhere. There is no HDD or other aux storage to be used as a swap/paging area for virtual memory mgmt like PC/Mac/Server systems have, so IMHO it all has to be part of that 2GB some way or other. This is another part of the "variability" and "owner environment" that IMHO influences who is and is not having certain issues.

IMHO Tesla exacerbates this by not seeming to place limits on the maximum of certain things that can use memory -- e.g. Tesla does not document maximums in their Owner's Manual like every other mfgr does for Infotainment options (max contacts, max tracks, max directory structure, etc). I've also seen no references in over a year here on TMC that anyone has ever seen a message displayed by Tesla's firmware when there are too many Nav History items, too many contacts being copied in from your phone, too many tracks, etc... instead just odd symptoms in the subsystems driven through the CID when perhaps limits are near their maximum and Tesla's firmware just keeps trying to do everything we request of it as it runs out of resources. Additionally, if one isn't actively using Nav to get to a destination, it's still partially active, with it's display, etc. so it's consuming memory -- how much more when you are actually going to a destination or because you choose to run the map full-screen or with satellite view vs "1/2-screen line-mode only" is any of our guess. Same with AP -- data is always being collected and sent to the mothership even if it's not engaged, right? So, @tomas not having AP may be a good inkling in-part why he sees no rescans, if memory is part of the equation, don't you think?

I know some of you hate my long dissertations, so will let everyone search for and read many of my old posts in threads from well before this one started, rather than repeat more of all that here --but in former releases I think I pretty much proved (at least to myself and some others), that reducing things like extensive Nav History (one guy had more than 1K before he deleted them 1-by-1) or way-too-many contacts, could allow initial USB scan to complete and reduce rescans or studdering for some people. I further proved at least to myself I could cause more issues by having too long and extensive metadata with too many tracks, hence why I've fallen back to some of the workarounds I deploy trying to scale back what my Tesla USB device has. As I've said, Tesla has made changes in the past year that have improved some things, so this summary is pretty broad brush and has evolved with a number of code drops (so don't get picky on me trying to summarize please) ... but I still believe poor memory management and Tesla not enforcing limitations how many of different things an owner can have, is a MAJOR contributor to the issues some of us have. 8.1 with it's new Linux base and perhaps a new/updated MP may change all that again. We'll just have to see.

 

[aesculus]

I almost always get in the car at 4:46am in the morning.

That's your problem. You need to wait until at least 5am before starting your car.

 

[Alkettory]

Ok, according to the Remote S App, 17.4.14 has just been installed on my MS.

That's your problem. You need to wait until at least 5am before starting your car.

Actually, if I went into work an hour later, it would probably be finished and I would never (or rarely) see reloads.

I truly believe memory mgmt is part (but not all) of the issue.

I agree. My guess is that there's a memory garbage collection job running. Base on the 49% completion at 4:46am and working backward, I'd be willing to bet that there's a scheduled task running at 4:00am.

 

[Alkettory]

Update: My "Loading" behavior is unchanged with 17.4.14.

 

[jgs]

I wonder if it has something to do with AP. I have NEVER had a rescan except at initial AM startup for a brief while til they fixed the energy savings, rescan bug. OTOH I have a 2012 with no AP... could I have more available memory? Could feature additions have put squeeze on memory?

It seems unlikely that AP makes much difference to the memory available in the CID. AP runs on its own dedicated hardware (Mobileye or Nvidia), and a good thing, too, since you wouldn't want a CID glitch making AP check out.

(I suppose the CID computer could be storing a bootstrap image for the AP hardware or something, but you wouldn't expect it to have to remain RAM-resident even if that were the case.)

 

[supratachophobia]

It seems unlikely that AP makes much difference to the memory available in the CID. AP runs on its own dedicated hardware (Mobileye or Nvidia), and a good thing, too, since you wouldn't want a CID glitch making AP check out.

(I suppose the CID computer could be storing a bootstrap image for the AP hardware or something, but you wouldn't expect it to have to remain RAM-resident even if that were the case.)

Well something is hogging those resources. There is a dramatic breakdown in frame-rates and responsiveness when you have a bunch of things going at once. I direct you to the turn signal bug a couple months ago where it wouldn't play the audio for the turn signal clicking. I think even displaying the whisker view can be taxing for AP at times.

 

[X Fan]

Well something is hogging those resources. There is a dramatic breakdown in frame-rates and responsiveness when you have a bunch of things going at once. I direct you to the turn signal bug a couple months ago where it wouldn't play the audio for the turn signal clicking. I think even displaying the whisker view can be taxing for AP at times.

Definitely agree with that. Sometimes when I run AP at night and use the USB, hi res music hiccups.

Still seeing rescans each morning...6 minutes today.

 

[jgs]

Well something is hogging those resources.

Sure, it's something.

There is a dramatic breakdown in frame-rates and responsiveness when you have a bunch of things going at once. I direct you to the turn signal bug a couple months ago where it wouldn't play the audio for the turn signal clicking. I think even displaying the whisker view can be taxing for AP at times.

The CID processor clearly has to be the thing that's rendering the sensor data for display on-screen (I don't think there's a different processor for the IC, is there?). So yeah, it makes sense that when the whiskers and other sensors are busy, those would take more cycles for screen updates. AFAICT though, the sensor inputs are getting rendered to the IC regardless of whether AP is engaged or not, and in fact there's no way to take them off the screen.

 

[BertL]

Sure, it's something.

The CID processor clearly has to be the thing that's rendering the sensor data for display on-screen (I don't think there's a different processor for the IC, is there?). So yeah, it makes sense that when the whiskers and other sensors are busy, those would take more cycles for screen updates. AFAICT though, the sensor inputs are getting rendered to the IC regardless of whether AP is engaged or not, and in fact there's no way to take them off the screen.

FWIW: While I have no schematics or architecture knowledge, I suspect the IC does have its own processor, as when you reboot the CID while driving, some functions on the IC continue to be displayed and remain operational (like turn signals, but no sound for them until the CID Comes back on). I've seen the IC reboot itself (sometimes with the CID), but that is normally when I'm parked and my MS decides to do that before it lets me do anything else. As to exactly which parts of what are perhaps calculated in some other processor somewhere and "sent" in some form or another to the IC for additional processing or just rending, I bet most of us don't know. IIRC from long ago, one of the guys that do/did the bench breakdown work on MS components suggested the CID was responsible for receiving and ultimately packaging-up AP data to/from the mothership, even though there were all the specialized processors doing their thing in other places.

I completely agree AP and Nav are always running to some degree if you have them installed, but not even turned on. Some of this latest train of thought in this thread -- at least mine -- started after @tomas suggested back in #1024 that he did not even have AP installed on his MS, hence my comment that a MS without any AP hardware would probably use less memory (and therefore less processor cycles too).

 

[BertL]

FWIW: While I have no schematics or architecture knowledge, I suspect the IC does have its own processor, as when you reboot the CID while driving, some functions on the IC continue to be displayed and remain operational (like turn signals, but no sound for them until the CID Comes back on). I've seen the IC reboot itself (sometimes with the CID), but that is normally when I'm parked and my MS decides to do that before it lets me do anything else. As to exactly which parts of what are perhaps calculated in some other processor somewhere and "sent" in some form or another to the IC for additional processing or just rending, I bet most of us don't know. IIRC from long ago, one of the guys that do/did the bench breakdown work on MS components suggested the CID was responsible for receiving and ultimately packaging-up AP data to/from the mothership, even though there were all the specialized processors doing their thing in other places.

I completely agree AP and Nav are always running to some degree if you have them installed, but not even turned on. Some of this latest train of thought in this thread -- at least mine -- started after @tomas suggested back in #1024 that he did not even have AP installed on his MS, hence my comment that a MS without any AP hardware would probably use less memory (and therefore less processor cycles too).

Oops, my reference should be to post #1027, not 1024. Sorry for my typo.

 

[Pruitt]

Yesterday another USB player issue cropped up.
Everything was fine Saturday when I put the car in the garage. When I began driving Sunday, I noticed that there's no progress bar on the IC for the song being played, and it also doesn't show the artist or album title anymore. It also no longer shows the song title - it shows the file name instead. For example, it used to show "Thriller," and now it shows "8 Thriller.flac."
On the player screen in the main console, the progress bar shows up for a split second, then goes blank. But the times are all screwed up when it does appear, showing things like starting at 1:30 and ending at -2:20. WTH?
Also, I see 0 albums, 0 artists, 0 genre, over 3000 songs (about right, and 295 folders (also about right). I removed the stick, then reinserted it. Player went through the entire load process, with no change to the display. I rebooted the main console twice, with no change. I rebooted the IC AND the main console after parking the car - no change again. I took the stick into the house and deleted a few albums - after reloading, still no change.
I've reformatted the stick and loaded just a few albums, but haven't had a chance to try it out again.

Anyone else seen this? If so, were you able to fix it? Any idea of the cause?

By the way - no software updates since the +5 was added back to autosteer.