Comprehensive USB Bug List

[DaiPlusPlus]

I accepted delivery of my new MX on Saturday - it has the new Intel MCU and is running firmware v8.1 (2018.10.2 74fad9a). I put in a 256GB USB3 .0 stick formatted with FAT32 that contained my ~97GB music collection. I'm getting the same issues where the library ignores the Album Artist and Track Number ID3 fields - but I also have a number of MP3 files that are completely valid MP3 files that play in other software but always cause the "Loading error" message. I'll be happy to provide the affected files (copyrighted music) on-request.

Of note: I ran the files through the MP3 Validation Tool and it reported that the files are valid MP3 files - this suggests a bug in Tesla's MP3 playback code.

Another issue I experienced is that when I play an MP3 file there might be some kind of "noise" or other distortion that goes away by restarting playback of the file. (I was worried it might be a Ground Loop in my speaker wiring). Has anyone else had this issue?

 

[BertL]

@DaiPlusPlus, congrats on your new MX.

I have personally not encountered a static sort of problem... other than a couple of times I’ve not encountered in months, where it seemed the CID was over-taxed CPU-wise and I had incessient studdering... a reboot of the CID resolved that.

I know this thread is long and you likely have not been able to wade through it all, but your problems are sadly not unique to you. It appears MS and MX have the same sort of problems, and we’ve had them for quite awhile to various degrees. I’m not so sure at this stage in firmware and with what I have so far garnered reading posts, that even having a MCU1 vs MCU2 makes a big difference with what are likely clear coding problems common to both.

From my experience, the “GB” of what is on your USB isn’t a real concern. I have tried to explain this above a couple of times. Net is, the number of tracks and the amount of ID3 data your aggregate tracks consume, in addition to what your phone contacts, Nav History, etc are consuming in the fixed amount of available CID memory can cause problems when it becomes constrained. Loading Errors seem to occur for a myriad of reasons, some because of memory constraints, some that can’t always be explained.

If I were you, I’d first do a complete reboot of your CID (foot on brake, hold both scroll wheels, release all 3 only when the Tesla T appears on the CID). That is always the first thing to try when something odd occurs, but in more recent firmware updates, it no longer seems to always delete all ID3 data from a previous scan of a USB device, so won’t always clear out former misgivings as well as it once did. Next, try reducing the aggregate number of tracks on your USB device to well less than 5-7K if you are exceeding that — how many GB they consume is not so much of an issue — the quantity IS. Make sure you are only using standard MP3 or perhaps FLAC filetypes (see posts above from me and others for other formats that appear to be supported — some tend to work better than others in terms of presenting less errors, but from my experience, a file that has encoding or errant tagging MP does not expect, will likely result in Loading Errors or even an unexpected CID freeze or reboot. Error recovery is not a strength of MP. Lastly, try reducing the amount of ID3 tag data you have within each track if you must. I hate to say it, but just because another player will handle your media files, does not mean MP always can... e.g. you’ll find some interaction above between another member and I awhile back in this thread who was coding his own ID3 tagging into his media files, and it worked elsewhere using the latest standards, but caused all sort of havoc in his Tesla until he “sort of regressed” his workback to something MP could handle. Sigh. It is unfortunately a mess, and Tesla just has not prioritized USB support or even MP functionality to a level that makes it a lot more foolproof for new owners like yourself to be able to copy a few existing media files to a USB device, stick it in, and allow them to play a majority of the time.

Good luck, and enjoy that new MX.

 

[DaiPlusPlus]

@DaiPlusPlus, congrats on your new MX.

Thanks - 1 week in and I'm still loving it. Especially the smoothness of the ride - driving it feels like gliding.

I have personally not encountered a static sort of problem... other than a couple of times I’ve not encountered in months, where it seemed the CID was over-taxed CPU-wise and I had incessient studdering... a reboot of the CID resolved that.

Mine has the new MCU so I presume it isn't a case of being over-taxed. It happens on single tracks and just restarting playback of that song is enough to fix it - I wonder if it's a bug in the "Immersive Audio"/DSP feature.

I know this thread is long and you likely have not been able to wade through it all, but your problems are sadly not unique to you. It appears MS and MX have the same sort of problems, and we’ve had them for quite awhile to various degrees. I’m not so sure at this stage in firmware and with what I have so far garnered reading posts, that even having a MCU1 vs MCU2 makes a big difference with what are likely clear coding problems common to both.

I understand the actual software is the same - there's nothing processor architecture-specific about the music library UI or audio file indexer.

From my experience, the “GB” of what is on your USB isn’t a real concern. I have tried to explain this above a couple of times. Net is, the number of tracks and the amount of ID3 data your aggregate tracks consume, in addition to what your phone contacts, Nav History, etc are consuming in the fixed amount of available CID memory can cause problems when it becomes constrained. Loading Errors seem to occur for a myriad of reasons, some because of memory constraints, some that can’t always be explained.

None of the issues I've experienced would be explained by way of memory utilization or related. There's about 13,000 tracks on my USB stick and it indexes them fine and if it's only using a couple of ID3 tags then the music library database file can't be more than a few megabytes saved to the MCU's non-volatile storage volume (case-in-point, my Winamp library database file is 9MB and that contains a lot of metadata).

If I were you, I’d first do a complete reboot of your CID (foot on brake, hold both scroll wheels, release all 3 only when the Tesla T appears on the CID). That is always the first thing to try when something odd occurs, but in more recent firmware updates, it no longer seems to always delete all ID3 data from a previous scan of a USB device, so won’t always clear out former misgivings as well as it once did. Next, try reducing the aggregate number of tracks on your USB device to well less than 5-7K if you are exceeding that — how many GB they consume is not so much of an issue — the quantity IS. Make sure you are only using standard MP3 or perhaps FLAC filetypes (see posts above from me and others for other formats that appear to be supported — some tend to work better than others in terms of presenting less errors, but from my experience, a file that has encoding or errant tagging MP does not expect, will likely result in Loading Errors or even an unexpected CID freeze or reboot. Error recovery is not a strength of MP.

I believe the issues I'm experiencing are "by-design" or limitations/bugs of Tesla's software stack rather than runtime faults.

Lastly, try reducing the amount of ID3 tag data you have within each track if you must. I hate to say it, but just because another player will handle your media files, does not mean MP always can... e.g. you’ll find some interaction above between another member and I awhile back in this thread who was coding his own ID3 tagging into his media files, and it worked elsewhere using the latest standards, but caused all sort of havoc in his Tesla until he “sort of regressed” his workback to something MP could handle. Sigh. It is unfortunately a mess, and Tesla just has not prioritized USB support or even MP functionality to a level that makes it a lot more foolproof for new owners like yourself to be able to copy a few existing media files to a USB device, stick it in, and allow them to play a majority of the time..

I want to find out why it's refusing to play some MP3 files and not others. I saw some people reporting issues playing VBR-encoded MP3s, but I looked at the files that are giving me Loading errors and those are CBR files without any special encoding. I do see that they have APEv2 tags in addition to ID3v1 and ID3v2 tags, so I guess I'll experiment with different container files for the same underlying MP3 stream data and see what works and what doesn't and report my findings.

BTW, I remember seeing people linking to some software that changes the ID3 tags of MP3 files to be more "Tesla-friendly" - e.g. putting the Track Number into the Track Name field so tracks are correctly sorted in Folder view, and setting the Album-Artist value into the Contributing-Artist field so it will correctly group Compilation albums. I think another feature was nesting folders so you can tap through the folder list without scrolling vertically. I couldn't find anything by searching - got a link?

Update:

I found TeslaTunes, but that's only for macOS, and it doesn't organize folders. I could swear someone linked to something for Windows or Linux.

 

[BertL]

@DaiPlusPlus,
We all have our opinions on what may and may not be happening with the crazy world of Tesla's MP. I've gone so far as declare I've become lost within the "Tesla Twilight Zone" more than once over the last couple of years. With all the variables, improving the MP USB situation is almost never exactly the same from owner-to-owner. A few things though on your observations:

• You'll find in this long-standing thread above, considerable discussion where a number of us have effectively proven that CID memory constraints DO cause issues of varying sort. In fact, my and other SvC do things like manually eliminate Nav History items to help resolve reported MP USB issues.
  • We've had specific reports in this and other threads where reducing CID memory usage has improved responsiveness, MP ability to play more tracks, and just overall stability. There are reports of owners successfully running more than 15K tracks on their USB device on a daily basis... I have tried more than 20K, but found it an unacceptable-to-me situation with increased problems and scan/rescan times, so worked my way down 1K-by-1K to my near-7K sweet spot I've been at for more than a year.
  • We figured-out long ago it appears owners without AP have more available memory for things like MP tracks. How AP2 and MCU2 impact that, are just more variables. Some of us that went through the time before-and-after AP1 sending continuous traveled-data back up to the mothership, believe we saw an initial decrease in MP stability, but definitely a reduction in the number of tracks MP could handle before stability decreased. IMHO it appears different features each of us have installed or perhaps even in-use in our vehicles at a particular point-in-time, impacts CID memory usage and what then remains available for MP. Tesla has not set fixed limits on much of anything controllable by the owner as all other mfgrs I have ever owned do, so while that may be good for some owner situations -- it also opens up weird unexplainable problems for others that perhaps press the limits more by having and using most features in our MS/MX.
  • IMHO the encoding types of media files will also make a difference in MP stability. Some work better than others. From my experimentation, FLAC and MP3 VBR seem to be a couple of the best.
  • Don't underestimate how much "tag data" within each of your tracks actually consumes. I did the math by counting and spot-checking several dozen of the tracks in my library -- across different genre where tagging varies the most -- and documented some of that above months ago. It's what drove me to create methods to reduce my overly-robust tag data for use in my Tesla -- (especially (track)ARTIST, and as MP started to evolve with how it initially did not, and now does, use Album Art.) Album Art has no maximum size or even filetype described by most ID3 "standards" since it was first introduced, and there can also be many versions of art associated with each track (front, back, etc...) MP in it's present incarnation seems to only keep a single piece of art for each album despite how many tracks you have with art or how many different varieties may exist for all tracks in a single album, but how big that art is internally (original size?), and if there is one or two copies of it for how the interface currently displays art, is only a point of our speculation -- not something we can determine without seeing MP code itself. My point being, tag data can easily be physically larger than the actual media itself, but how well Tesla deals with that and how it impacts memory usage is only another point of owner conjecture. I do know that I have far less problems, and can keep more tracks on my standard Tesla USB device, now that I've rather dramatically reduced tag (and album art) data associated with every track on my device. YMMV of course.
• I'm the one that reported a few months back having better success with MP3 VBR files. They cause less rescans and MP problems for me, compared to FLAC that I used for more than the first year of my MS ownership.
• I suggest you stick with basic ID3 tags - v1/v2 if you can. Other tags may cause problems as you are encountering -- it's what I was mentioning before with another guy that was trying to use more recent containers and other "standards". MP just does not know how to handle or ignore some of the later generation tagging options. The reality is, the whole music-tagging thing is far from consistent in the world -- beyond Tesla's control -- as it's far from a consistent standard given how it's evolved over the years. Months ago, when I was trying to help a fellow member here, I found his physical media file actually had some container/tagging errors within it, and even though the file itself had not been changed in years on his system and worked fine with other players, it would not work in MP until the errant tags were deleted and recreated (without errors) within the track. Where MP gets us into trouble is -- it's just not designed and coded well enough to ignore tagging it does not understand like more robust players do, so we end up with the situation we're in.
• You can find the workarounds I use by reading through the bullets what my automated dBpoweramp workaround accomplishes just a couple of pages above in this thread: Comprehensive USB Bug List. In that post, I also offer some suggestions for extracting files for Mac iTunes users. Other people also use manual methods with their various tagging tools -- I've just gone so far as to automate most of the process. You'll find the specifics I use to create my MP3 VBR files there as well, in case it's helpful.

Good luck with your exploration. Enjoy your MX!

 

[X Fan]

BertL—

Informative posts as always. One other item that I found:

HiDef flac tracks also occasionally Studder.

 

[DaiPlusPlus]

I did some more experimentation with the MP3 files that were giving me the "Loading error" message and I ran the files through a different MP3 validation tool. I previously used MP3Validator ( MP3val - home page ) which said the files were fine, but MP3Diags ( MP3 Diags ) reported many problems with the files that weren't playing, I note that many of the unplayable files had APE tags in addition to ID3v1 and ID3v2 tags. MP3Diags also reported these issues with the unplayable files (but I don't know which of these issues actually affect playback or not, as I had MP3Diags fix all of them - I also removed the APE tags as they were redundant)

• Unsupported stream found. It may be supported in the future if there's a real need for it. (In all the files I checked, the Unsupported stream was associated with the APE metadata).
• Invalid ID3V1 tag. Invalid characters in Name field. (Other files had this error and play fine)
• Ape item flags not supported.
• Invalid Ape tag. Header expected but footer found.
• Invalid ID3v2 tag. Invalid characters in Name field (This message appeared twice, perhaps the unplayable files had duplicate ID3 data areas and the Tesla MP didn't like that?)

The MP3Diags tool can also repair the files, so I let it do its thing and put them back on the USB stick and my Tesla plays them fine without any issues - problem solved! My money is on the APE tags and metadata being the cause.

I noticed that the "Lame header" (which also contained a "Xing header" inside of it) worked fine with the Tesla MP, even though the Lame header comes before the actual MPEG audio stream. So you do not need to remove that stream in MP3Diags.

I'll type this up again under a big visible heading below so people skimming the thread can see it:

How to fix the "Loading error" message when playing MP3 files from a USB source

1. Plug your USB stick into a computer
2. Download MP3Diags (Download link for Windows: http://sourceforge.net/projects/mp3diags/files/mp3diags-windows-exe/MP3DiagsExe.zip )
3. Run MP3Diags and scan your USB stick
4. You might want to add some common "Notes" to its "Ignore list", such as those below, which I feel are benign issues that the Tesla MP handles fine.
   1. "No normalization undo..."
   2. "The padding in the ID3V3 tag is too large..."
   3. "Low quality MPEG audio stream..."
5. Make sure you have a backup of your original MP3 files stored elsewhere! (The author of MP3Diags says they cannot guarantee files won't be corrupted)
6. Open the MP3Diags tool's Configuration window, go to the "Custom transformations lists" tag and choose the 4th Hammer icon, then add the "Remove all APE streams" transformation), then click OK.
7. Click the 4th Hammer button in the top toolbar to fix the issues it finds.
8. After it finishes, safely eject your USB stick (Windows' "Safely Remove Hardware" icon in the taskbar or Right-click the drive icon and choose "Eject")
9. Put the stick in your Tesla, let it re-scan the drive and the files should now be playable.

 

[iffatall]

I was thinking - may be someone here knows someone who works in Tesla software? Perhaps we can try to push for the basic album categorization fix through them? Don't know if someone has tried this already.

 

[BertL]

I was thinking - may be someone here knows someone who works in Tesla software? Perhaps we can try to push for the basic album categorization fix through them? Don't know if someone has tried this already.

It was tried early on by this thread’s creator at least once, if not twice. The first time around the time this thread began, we went through a prioritization process and the top (IIRC 5-7) items were submitted to what I believe was an undisclosed Tesla “insider” who was thought may be able to help us. I know at least one member contributing to this tread who differs with my POV, but IMO there is no truly correlatable delivered improvements to-date from that work.

That effort, specific to MP USB support, was done after an even larger and more comprehensive effort was made here on TMC in late 2016 with over 200 people contributing to ID the top overall MS firmware improvement requests covering more than just MP USB. It was really comprehensive and well done. Some of those suggestions have since showed-up as deliverables, but my pessimistic self on this subject does not believe what we did really had impact with Tesla — at least in terms of top suggestions by real owner/enthusiasts being delivered in a somewhat reasonable timeframe. It also remains too coincidental to me the potpourri of what has eventually been provided, opposed to what was requested.

I still sadly believe Elon does not care about working on “basics” that won’t garner big headlines or are not as fun to develop and deliver like new Easter eggs seem to be for some, so it does not get done. USB support is important to many of us owners, but not enough that makes a dent in Elon’s POV to move the fixes and improvements up Tesla’s priority list.

 

[X Fan]

I’m afraid to say this too loudly but since my SW was upgraded during a service visit to 16.eac88a7, I’ve had no rescans on my 300+ album, 5,500 song USB for 5 days.

Anyone else having better luck with rescans after latest SW update?

 

[f-stop]

In my case I've not had (many) random rescans of the USB (~7,000 tracks) for the past several software updates now [knocks on wood]. Currently on 2018.14.2

OTOH, I'm seeing more frequent occurences of the "no source selected" problem I mentioned back in Oct 2017 - the one where after playing USB music then leaving the car, upon return there is NO audio source selected and no sound playing, or sometimes the wrong source selected - meanwhile the USB tab on the music player disappears and won't reappear until momentarily playing another source like Slacker (no USB rescan required after the USB tab magically reappears). With the lastest software update, or maybe the 1 or 2 prior, this problem seems to happen now almost every time I get back into the car. I forget exactly when because it's just become muscle memory for me to play a Slacker channel when I get back into the car so I can then select USB again a few moments later when the USB tab reappears.

btw, 2018.14.2 also doesn't fix the frequent USB Loading Errors on .M4A/AAC tracks which I've previously reported. MP3 tracks remain fine in that regard.

Meanwhile, I just noticed something in the USB player that's actually been fixed (I know, hard to believe, right??)
It might have been fixed a long time ago but somehow I only just noticed it - I mentioned about a year ago / 30-or-so pages earlier in this thread that the USB listing annoyingly sorted band names starting with "The" all in the "T" section. i.e. The Beatles, The Beach Boys, The Doors, etc all showed up under "T" instead of under B, D, ... Now they're correctly sorted in the letter where you'd expect them to be. I guess that's progress...

 

[X Fan]

^^^^
agree with car often forgetting where you were upon re-entry. But, at least you can quickly go back to the album as long as there isn’t a re-scan.

Funny, the other day an album I was listening to in the morning dropped out during the day. However, when we went out at night it started again.....Tesla USB play just moves to the tune of its own drummer.

 

[wdolson]

^^^^
agree with car often forgetting where you were upon re-entry. But, at least you can quickly go back to the album as long as there isn’t a re-scan.

Funny, the other day an album I was listening to in the morning dropped out during the day. However, when we went out at night it started again.....Tesla USB play just moves to the tune of its own drummer.

The entire audio system does. I've had constant problems with the radio auto-tuning to another station for no reason and it coming off mute for no reason.

 

[BertL]

FWIW as discussed at least in passing somewhere before in this thread, I strongly believe that the issue with MP forgetting where it is in a track upon exit, and then restarting at that point upon entry, is at least in part dependent upon the encoding format of the track. E.g. I now have more time than not my MS playing the same track as I left it, when using MP3 VBS, whereas my former exclusive use of FLAC was very hit or miss what I may be listening to upon reentry. We still have the issue where MP does not seem to immediately turn off upon exit, and I still think there is some issue when recharging is involved, but I more often than not since converting exclusively to MP3 VBS will have some part of the same track resume upon reentry unless I was already towards the end of a track when I exited.

To me, it’s just another example of Tesla’s sloppy design, coding and testing that allows MP USB to playback differently because of the encoding format. {:-|

 

[DaiPlusPlus]

Weird - mine rescans my USB stick every time I get in the car to commute every morning - it takes about 1 minute to scan all 12,000 tracks on the USB stick so it isn't a huge problem, just surprising.

I'm going to run-through the issues I've identified so far:

• Refuses to play MP3 files with APE tags (APE tags are an alternative to ID3v1 / ID3v2 tags) instead it just says "Loading error" (removing the APE tags fixes this issue)
• Inconsistent album art display (Though I should audit my files to ensure they have consistent album art info before formally reporting this issue)
  • (though its use of a web-image-search to get album art for Bluetooth Audio is almost always incorrect, sometimes with unintentionally hilarious... or NSFW results)
• Played media sometimes has a "noise hiss" - this happens about 3-4 times a week and is corrected just by restarting playback of that particular file. It happens regardless of the "Immersive audio" setting.
• Media library does not respect the Album Artist and Compilation fields. It is impossible to play a multi-artist compilation album (e.g. "Now That's What I Call Music" or movie soundtrack album) correctly because the tracks appear under different artists. If the files are in the same filesystem folder then you can use Folder view to get them but then it orders the tracks alphabetically by Track Title instead of by Track Number.
• The right-hand scrollbar's "stops" do not correspond to their actual location, e.g. if I swipe-down from "A" to "E" the list will actually be at "D". It gets worse the further I scroll down: when I select "Z" it's actually at "V" so I always have to manually scroll down further.
  • (I wonder if it's because I have some folders starting with non-letters like underscores and numbers?)
  • Also, when the Media library view is in the lower half of the screen the "stops" seem calibrated such that they're where they'd be if the Media library view was either full-screen or in the top half of the screen.

The only issue I really care about right now is the lack of Album Artist and Compilation support. I'd also like support for custom playlists too (just *.M3U files would be enough!) I'm assuming it isn't much more work involved to add some new Views to the library.

As the MCU is isolated (and sandboxed, presumably) and what with rumors of an SDK coming out, I'm hoping Tesla will open-source parts of the MCU software so we can submit our own patches.

Has anyone jailbroken their car yet?

 

[f-stop]

• The right-hand scrollbar's "stops" do not correspond to their actual location, e.g. if I swipe-down from "A" to "E" the list will actually be at "D". It gets worse the further I scroll down: when I select "Z" it's actually at "V" so I always have to manually scroll down further.
  • (I wonder if it's because I have some folders starting with non-letters like underscores and numbers?)
  • Also, when the Media library view is in the lower half of the screen the "stops" seem calibrated such that they're where they'd be if the Media library view was either full-screen or in the top half of the screen.

I notice this problem with the right-hand scrollbar/alpha-index too. It seems to be often off by -1 letter (e.g. swipe to E, it displays D entries), sometimes off by -2 letters. Other places it's correct. Although I never bothered to complain about it or look into it too closely because I was just happy they simply brought back the right alpha-index after they completely took it away for a while in one of the earlier major UI updates of the firmware.

In my case I always have the music player in the lower half of the screen, so maybe you have something there with the idea the stops may be incorrectly "calibrated" to where they'd otherwise be for fullscreen or top half? And yeah, the ridiculously incorrect album art over Bluetooth is a longstanding problem that's still there in 2018.14.2. Like most of the media player problems, seems little hope anyone at Tesla cares.

p.s. Don't hold your breath for an SDK - that very old rumor was subsequently squashed by Elon when he said it's more likely they'd add some sort of app mirroring of your smartphone (which in itself is now 2-year old news from Jan 2016 and so I'd guess either is unlikely to ever happen...)

 

[neroden]

This is the bug report I sent to Tesla executive Joe Carter in FEBRUARY. I haven't heard back since.

Tesla is behaving in a truly abominable fashion here. Disgraceful, frankly. They broke basic functionality in 2016, ignored it for 2 years, and are now trying to get out of their warranty obligations.

At this point I would buy from any other electric car company if someone would make a decent car (like the Bolt) with fast charging and a decent charging network.

Dear Joe Carter:

Here is my set of comprehensive and detailed bug reports for the USB music bugs, as I said I would write for you. There are six bugs, and a set of recommended long-term fixes to software engineering practice at Tesla. Please follow up with me.

Tesla Media Player USB Bugs: Detailed Report

I have been trying to report various USB Music bugs for five years without managing to communicate with anyone responsible. Reporting them to service centers, Tesla headquarters, by phone, email, etc. has totally failed previously. New bugs (regressions) have been introduced in software updates, meaning that I must not update my software until they are fixed, and nevertheless I have seen no progress on these bugs. Others I have talked to have reported these bugs also with no success. As a former programmer, I am disgusted with the absence of normal software engineering practices such as taking bug reports from customers, creating testsuites, and doing regression testing. I have recently managed to escalate to Joe Carter in management, and I hope this will have more effect.

I recently was able to drive a brand-new loaner Model S and test the current version of the software extensively so that I can detail the current status of the many critical bugs in USB music playback. Unfortunately it retains all the critical bugs of the older software, and new regressions have been introduced with later versions.

I have identified six important bugs in the current software. Two are critical, of which one is a critical regression.

Bug #1: Lack of Gapless Playback

Use case: Play a continuous album such as Oxygene (by Jean-Michael Jarre), Sgt. Pepper's Lonely Hearts Club Band, Dark Side of the Moon, or radio dramas such as Hitchhiker's Guide to the Galaxy, ripped from a CD or from vinyl. These are typically organized into multiple tracks, but play as one continuous story.

Test case: Rip Oxygene from CD to a folder in a lossless format (FLAC, WAV, or AIFF) with one file per track. Play the file by folder; start near the end of part one. This is a particularly easy-to-hear test; anyone with any hearing can tell if there's a gap.

Expected behavior: The music plays continuously, as the album is supposed to be played.

Actual behavior: There is a pause or gap (stuttering) between tracks. It is extremely irritating, particularly for radio dramas.

Workaround: Rip the entire hour-long album as a single file. This loses any ability to start directly at a specific track (particularly useful for radio dramas when you want to “continue where you left off” after someone else has been using the media player), so this is a very unsatisfactory workaround

Workaround 2: Carry a CD player and portable speakers in the car, powered off the 12V outlet. Not reasonable.

Suggested solution: Copy the algorithm from Audacious, which is a free and open source media player for Linux which gets this right. (I believe it prequeues the next song to guarantee continuous play.)

Versions where bug is present: This has been present since the first version of the software. I reported it in 2013, multiple times, through multiple channels, and again in 2014 multiple times, and again in 2015, 2016, and 2017, but with no response.

Severity: Critical. This makes it extremely difficult to play radio dramas or concept albums. It makes the Media Player worse for this purpose than a tape deck. This is a particularly infuriating bug as I used to listen to radio dramas in the car, and I simply can't do so in Model S.

Bug #2: Incorrect play order in Play By Folder

Use case 1: Rip a CD to a folder on a USB stick as multiple tracks, naming the files “1 – track name”, “2 – track name”, etc.. Attempt to play the album “by folder”. (Note that playing it “by album” does not work due to bug #4.)

Use case 2: Set up a folder on the USB stick with a collection of chosen songs from different sources named, for example, “1 – Please Please Me”, “2 – God Only Knows”, “3 – Achy Breaky Heart”. This is the only way to create playlists for Model S, and it's a perfectly good method. Attempt to play the album “by folder”.

Test case: Both of the above use cases should be used as test cases.

Expected behavior: The songs should play in alphanumeric order by filename, allowing for the USB stick owner to make custom playlists. This behavior was correct for the original Model S software.

Actual behavior: In the current software, the files are sorted in alphabetical order by the track name encoded inside the file. If there is no track name encoded inside the file, the order seems arbitrary. It is not the album order and it is not the playlist order. It is impossible to put a playlist in a specific order without hacking the actual files, a tedious and inappropriate thing to do.

Workaround: No practical workaround.

Severity: Critical regression. This needs to be fixed before anyone can be asked to update their software. I cannot update my software until this is fixed. I have been reporting this bug to service centers for a year.

Versions where bug is present: The bug is present in the most recent version of the software. It is not present in early versions of the software. This bug seems to have been introduced sometime in 2016 when the “new look” interface was introduced. I will not upgrade my software until this regression is fixed, as it breaks a common use case. I have reported this repeatedly over the last year with no response.

Suggested Solution: Restore the previous code for order of playing tracks “by folder”, ordering them by filename. In any case the current implementation is wrong; alphabetical order by internal track name is never correct.

Bug #3: Inappropriate names listed when playing “by folder”

Use case: Play a folder with several variants of the same song, with the same internal track name but different filenames.

Test case: Same.

Expected behavior: The filenames should be listed when playing “by folder”

Actual behavior: Track names encoded into the files are listed, if present; if not, the ordering is random

Severity: Serious. Particularly annoying with multiple variants of the same song.
Suggested Solution: When playing music “by folder”, restore the previous code for the “by folder” method, displaying filenames rather then internal track names.

Bug #4: USB sticks take very long time to load

Use case: Insert a new USB stick with a terabyte of obscure music from my collection, ripped from vinyl or CD-Rs, carefully organized by folder. Many of these tracks do not have internal track/album/artist ids, or they are incorrect.

Test case: Insert a fresh USB stick with a terabyte of music organized in folders.

Expected behavior: Play by Folder should be accessible immediately on inserting stick

Actual behavior: The software wastes a substantial amount of time doing some sort of indexing, which is unnecessary for Play by Folder. On the loaner, it took over ten minutes. No music is accessible until this is finished.

Workaround: No practical workaround.

Severity: Serious regression.

Versions where bug is present: While there has always been a delay doing unnecessary indexing, the delay is relatively short (under 30 seconds) on the older software. It is over 10 minutes on the newest software on the loaner.

Suggested solution: Make Play by Folder available immediately (it requires no indexing). Then index in the background before making Play by Album/Artist/etc. available.

Bug #5: Play by Album fails on large USB sticks

Use case: Insert a USB stick with a terabyte of music including album names from A to Z; attempt to access “By Album”.

Test case: Insert the stick, wait the 10 minutes for the index, then go to “By Album”. Attempt to scroll down to the letter Y.

Expected result: A list of albums starting with the letter Y.

Actual result: Either a blank screen or very long delays followed by a list of some albums beginning with another letter. Apparently the album index fails to index past a certain letter.

Severity: Moderate. This means that it is essential to access all albums “by folder”. Bug #2, unfortunately, breaks playback “by folder”.

Versions where bug is present: This bug appears to have been introduced when the new-look interface was introduced. I have not extensively tested it on the old software, because “by folder” works on the old software.

Suggested solution: Fix bugs #1, 2, 3, and 4 immediately; then work on the album indexing code.

Bug #6: Play by Album contains lots of spurious albums and can't find albums for some tracks

Use case: Insert a stick with obscure tracks ripped from vinyl, recorded at home, or ripped from compilation albums.

Actual result: A cluttered and confused list of albums many of which are not present on the USB stick, and a lot of songs which aren't listed as being in any album. (But only albums beginning with letters early in the alphabet, due to bug #5.)

Severity: Minor. This would not be a problem if Play By Folder worked.

Suggested Solution: Fix bugs #1, 2, 3, and 4. The album indxeing code cannot work well with confusing data, but it doesn't need to if Play By Folder is fixed.

RECOMMENDED LONG TERM FIXES:

Tesla's software engineering practices are disgracefully disorganized and need to be brought up at least to standard practice of 20 years ago: this requires regularly updated testsuites, regression testing. a bug tracking system with customer reporting and supervisor monitoring of the bugs, and prioritizing of programmer resources based on the bug reports.

First, it is evident from the severe longstanding regressions that there is no testsuite for Play by Folder, perhaps no testsuite for the USB music player at all. There needs to be one, immediately. I recommend the following three tests to start:
-- A USB stick containing (in one folder), as multiple tracks, in a lossless format (FLAC is easiest), the album Oxygene by Jean-Michael Jarre, ripped from CD. Each release should be tested by listening to the end of track 1 transitioning into the start of track 2. This is a particularly easy-to-hear test of gapless playback. This should be tested in both By Folder mode and By Album mode.
-- A USB stick containing a folder made up of a playlist of files from different albums, given names to specify a specific order of playback. Each release should be tested to see that correct track ordering works correctly in filename order, and names are displayed in filename order, when accessed through By Folder mode.
-- Any terabyte USB stick with a terabyte of music, sorted into folders and subfolders. This should be used to test the loading time for By Folder mode.

Second, there ought to be a “Bugzilla” for the car's software, and it ought to be possible for car owners to file bug reports in it, file followups to them, and to receive direct feedback from the programmers. There ought to be someone of high authority in the software engineering department who is specifically responsible for paying attention to and responding to such bug reports -- someone who has the power to order programmers to work on fixing 5-year-old critical bugs and year-old critical regressions rather than entertaining themselves writing easter eggs.

Third, bugs #1-4 should be fixed as the current top priority of the software engineering team. They are certainly more important than easter eggs or reskinning, which the team has been wasting its time on. Easter eggs are fine when the software is working right. But when critical bugs go unfixed for years, easter eggs are a slap in the face to your customers.

I will be happy to answer any questions you have about what basic functionality audiophiles with large collections of obscure music, such as myself, need in a car music player. I will be happy to provide further beta-testing and stress testing for the software, especially if you have a release which you believe fixes bug #1 – but I will not upgrade to any release until bug #2, the critical regression, has been fixed.

I very much want Tesla to be the best car company. (I have most of my wealth invested in Tesla!) But it isn't going to be as long as basic functionality bugs remain broken for five years. It seems to me that there are critical communications failures going on here; these bugs are fairly easy to fix, so somehow they have never been reported to the right person despite Tesla receiving many many reports over many years These communications failures really are the thing I hate about Tesla.

Sincerely,

Nathanael Nerode
<address and phone redacted>

 

[DaiPlusPlus]

This is the bug report I sent to Tesla executive Joe Carter in FEBRUARY. I haven't heard back since.

I might suggest looking around on LinkedIn or GitHub for actual software-engineers at Tesla and forwarding them the reports rather than going to the executives. It's worked for me in the past (for other companies).

 

[neroden]

I might suggest looking around on LinkedIn or GitHub for actual software-engineers at Tesla and forwarding them the reports rather than going to the executives. It's worked for me in the past (for other companies).

It's an idea. I don't even know how to search for Tesla software engineers on LinkedIn (update: I think I get it, I work through the list of 23,000 employees looking for the right job titles?), let alone trying to find one responsible for the right field. If you've succeded at that in the past, maybe you could find some names?

But good god, isn't this completely ridiculous? I guess I can email random people who might work for Tesla (or are pretending to), but seriously, what the hell?

I guess I can try it, and I probably will, but this is beyond insane.

 

[neroden]

Has anyone jailbroken their car yet?

Bluntly, at this point I think we need to since Tesla is refusing to fix their own bugs. Time to decompile it and start hacking?

 

[neroden]

It's sad, as a handful of programmers could have resolved most of the problems and lack of functionality long ago ...

I could *personally* fix it in a month. Give me access to the codebase, permission to open-source the music player (so that I can use code from other open-source music players) and I'd do it for free.

(This is, by the way, why software should be open-source. So that irritated people can just fix it themselves. Tesla's policy of pirating open-source software misses the whole point of open-source software.)

but IMO as long as people keep buying new Tesla's with the warts they have, disappointed owners create their own workarounds or just abandon trying to use USB Music accepting the problems, and there is no negative press to sort of force Elon's hand to improve things, MP and Infotainment are not treated as a priority ... but Elon says yet another new Easter Egg will be provided very soon. {:-(

I promise that I will actively go to the press if this problem is not addressed within the next few months.

Actually, I'm so fed up, if any reporters want to talk to me, I'm happy to talk right now.