Funny how having a dynamic/ever-updating NAV screen forced as a background 100% of the time will suck away resources.....My Tesla Twilight Zone (of unexplainable events) still exists with V9
Was listening to USB music (as usual) when I parked my MS a little more than 24 hours earlier. Opened my door. Strangely, no music was playing as expected. MP USB was up, but with only my top level directory name displayed. Nothing was selectable. Tried FM which worked, then touched USB to see if that would shake the UI loose. After more than 1 min (I timed it), no change on the CID.
So, I did a full CID reboot. Things were very sluggish for several minutes while the systems came back online. I have no discrete before/after timings, but IMO V9 MP USB was much slower to react than 8.1 ever was after a reboot and initial scan. Anyway, after nearly 15 minutes to scan my 6200 tracks, USB music became available, but effectively unusable with delays between interactions. I listened to FM for perhaps 10 mins while USB remained sluggish trying to get through the UI to play a track. I then parked, did my thing for nearly an hour, and when I came back, USB music was back to its new V9 norm working again. I was good on the way home and again this morning when I took my MS out for errands.
It can’t explain the oddity for MP USB going bezerk while I was parked — showing only an unselectable top level directory name — never seen that one before, but it sure seems V9 has some challenges after reboot with larger USB music libraries (6200 tracks in my case). I suspect MCU1 CPU and memory constraints are showing their ugly head more than what we’ve ever seen before, and the new UI is taxing what we have more than it should with larger (is 6200 big?) USB libraries. Tesla is definitely not pushing limits with their testing of MCU1 and USB environments to ensure usability, but hey what’s new with that?
I’m going to think about cutting the number of my USB music tracks down even further. That’s really sad given how many times I’ve already done it, with all the other workaround contortions, trying to make my Tesla MP more stable.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Comprehensive USB Bug List
- Thread starter supratachophobia
- Start date
I'm using 16/44.1 (CD quality) since almost all my masters are on CD or CD-R.
I just wish they'd get tracks playing in the right order.
X Fan
Active Member
^^^^
Same success re: CD quality or better FLAC files (I have a few higher frequency files that seem to work too).
BTW: with latest rev (42.2) it looks like gapless playback has been initilized. I was playing my “Ella in Berlin” this morning and songs just flowed one to another.
No rescan problems yet.....
Same success re: CD quality or better FLAC files (I have a few higher frequency files that seem to work too).
BTW: with latest rev (42.2) it looks like gapless playback has been initilized. I was playing my “Ella in Berlin” this morning and songs just flowed one to another.
No rescan problems yet.....
thecloud
As rhythm raced inside, the ship came alive
One would think that if they had finally implemented gapless playback, it would be a feature worthy of mention in the release notes. I hope you're right, though, since that would mean they are spending some time on fixes for these issues. Anyone else seeing gapless playback where it didn't exist before, e.g. with "Dark Side of the Moon"?
Not me, nor does mine resume playback. Could it be the size of my flash drive that causes this? I'm using a 256GB drive. What size drive is everyone using where the resume playback works? This is my biggest problem with the USB interface. Lack of gapless playback is #2.
I'm using 1 1TB SSD drive with 4500 VBR MP3 tracks. Resume has been flawless for the past few months. I have 2018.32.4 firmware.
BertL
Active Member
As discussed upthread in more detail and with a lot of personal trial-and-error over the past year, IMHO the resume playback issue is nearly flawless with MP3 filetypes. Some users have luck with FLAC or others, but I believe you'll find non-MP3 filetypes are far more problematic for more people as you search this and other threads. It's the main reason I switched from FLAC to MP3 VBS months ago and recommended others do the same if the "resume playback" issue bothered them enough. Similar to @Alkettory, my 480GB USB SSD with only MP3 VBR tracks has been flawless in terms of playback resume.
Despite past theories, I don't believe physical size of the USB device itself is your issue. Again, upthread somewhere is a long post of testing I did with 12 or so different USB devices from various mfgrs with varying sizes. There was no difference to anything I could find in how MP USB worked based on the physical size of the USB device itself -- except that you can still occasionally come across the odd-USB device that has a physical hardware failure -- which isn't a Tesla issue per se, although I don't believe Tesla's USB error handling has ever been up-to-snuff compared to say Windows, macOS and other more robust OS implementations. (In my testing with failing USB devices, the CID rebooted, wouldn't recognize the device, and things like that -- it never got far enough that a track would play and then not resume.) If you think you may have a failing USB hardware device, my suggestion is to take that device to a more robust environment like macOS or Windows and run a full read/write diagnostic against it, or easier, just use another USB device with the exact same tracks and organization to see if the problem persists -- it's not likely you'll have two USB devices with the same hardware failure, although I did find that situation with 2 name-brand USB sticks that I purchased at the same time, and suspect were manufactured in the same run with similar flaws -- after returning them in-turn and getting replacements, I had no further issue with either one.
Gapless playback IMHO is a long-standing requirement, not a "bug" in the traditional sense -- at least that's how we've tried presenting the need to Tesla in past prioritized attempts. ...and for others, again IMHO, gapless playback is something that needs to first be created by Tesla within MP USB and then turned-on/off as a MP USB option by the listener -- it's not something that gets (ID3) tagged and can be expected to be acted upon in a standard way across all media players. Some players allow this specification at the album level, but it's not what I'd consider anything that's been standardly adopted in the evolving and somewhat loose ID3 specification I would ever hold Tesla to. A workaround today for those that really care about gapless playback for one or more albums, would perhaps be to use a music app on your favorite OS to copy each track in a gapless album back-to-back to form a single encoded file for playback in your Tesla -- at least that's what I'd do if it bugged me enough (it doesn't) to not have the 1-3 second gap between tracks for those special classical/concert albums in your collection (and remember, if it's not MP3, you may well need to sit there and listen to the whole album, or be prepared to replay it and manually scrub back to where you were, as MP USB may not resume the long track once you leave and reenter your Tesla
).
aesculus
Still Trying to Figure This All Out
I am using a 128 gb drive and FLAC. Seems more consistent with V9 that it resumes but it always starts the track at the beginning.
As discussed upthread in more detail and with a lot of personal trial-and-error over the past year, IMHO the resume playback issue is nearly flawless with MP3 filetypes. Some users have luck with FLAC or others, but I believe you'll find non-MP3 filetypes are far more problematic for more people as you search this and other threads. It's the main reason I switched from FLAC to MP3 VBS months ago and recommended others do the same if the "resume playback" issue bothered them enough. Similar to @Alkettory, my 480GB USB SSD with only MP3 VBR tracks has been flawless in terms of playback resume.
Despite past theories, I don't believe physical size of the USB device itself is your issue. Again, upthread somewhere is a long post of testing I did with 12 or so different USB devices from various mfgrs with varying sizes. There was no difference to anything I could find in how MP USB worked based on the physical size of the USB device itself -- except that you can still occasionally come across the odd-USB device that has a physical hardware failure -- which isn't a Tesla issue per se, although I don't believe Tesla's USB error handling has ever been up-to-snuff compared to say Windows, macOS and other more robust OS implementations. (In my testing with failing USB devices, the CID rebooted, wouldn't recognize the device, and things like that -- it never got far enough that a track would play and then not resume.) If you think you may have a failing USB hardware device, my suggestion is to take that device to a more robust environment like macOS or Windows and run a full read/write diagnostic against it, or easier, just use another USB device with the exact same tracks and organization to see if the problem persists -- it's not likely you'll have two USB devices with the same hardware failure, although I did find that situation with 2 name-brand USB sticks that I purchased at the same time, and suspect were manufactured in the same run with similar flaws -- after returning them in-turn and getting replacements, I had no further issue with either one.
Gapless playback IMHO is a long-standing requirement, not a "bug" in the traditional sense -- at least that's how we've tried presenting the need to Tesla in past prioritized attempts. ...and for others, again IMHO, gapless playback is something that needs to first be created by Tesla within MP USB and then turned-on/off as a MP USB option by the listener -- it's not something that gets (ID3) tagged and can be expected to be acted upon in a standard way across all media players. Some players allow this specification at the album level, but it's not what I'd consider anything that's been standardly adopted in the evolving and somewhat loose ID3 specification I would ever hold Tesla to. A workaround today for those that really care about gapless playback for one or more albums, would perhaps be to use a music app on your favorite OS to copy each track in a gapless album back-to-back to form a single encoded file for playback in your Tesla -- at least that's what I'd do if it bugged me enough (it doesn't) to not have the 1-3 second gap between tracks for those special classical/concert albums in your collection (and remember, if it's not MP3, you may well need to sit there and listen to the whole album, or be prepared to replay it and manually scrub back to where you were, as MP USB may not resume the long track once you leave and reenter your Tesla
Is VBR a key here or does that not matter? All of my tracks are 320 MP3 files that I'm playing back, but there are some other files on the USB flash drive. Is organization or USB content other than MP3 files a possible issue? All I know is in both my Model 3 and Model S loaner, the resume playback didn't work. It work in the Model S if i opened any door other than the drivers door. It doesn't work at all in my Model 3 and has to reindex each time I get in the car (3 and S). I'm using a SanDisk Cruzer 256GB USB 2.0 Flash Drive
I can tell you there is a bug where I hang up a Bluetooth phone call, I get a massive blast at a volume level much higher than what my USB playback volume is set for when the music comes back on. I do not notice this when listening via Bluetooth. Volume leveling is not immediate when going between Bluetooth and USB.
BertL
Active Member
My theories:
- I believe MP3 filetypes work better in terms of MP USB being able to both resume and be at the same place where it left off when you enter/exit a MS. I further believe, but can't prove that best success with this requires you maintain 100% MP3 files on your USB device -- otherwise it's like going to Vegas and the luck of the draw how MP may get messed-up because of scan or playback of non-MP3 files. I keep only 100% MP3 files on my USB stick for that reason and have no playback remembering issues.
- Use of MP3 VBR I don't think is as big of a deal in terms of MP stability -- it's a personal preference. VBR -0 basically provides the best retention of detail with this lossy format and helps reduce file size compared to a standard MP3. (Yes to others -- I have over-simplified that detail. If someone cares about the specifics, it's readily available elsewhere as I've linked-to in the past. ).
- NOTE: Because I'm a sort of audio snob wanting to maintain the best sound reproduction I can afford wherever I am -- even if I can't always hear the difference -- I originally maintained nothing but FLAC 320kbps tracks in my MS before going to MP3 VBR 240kbps. The reality is I can't tell a difference 99.9% of the time inside my MS with all the road noise -- only perhaps if I'm parked and listen closely to certain passages back-to-back with the same track encoded in both formats. That's just me. Your and other's experience may vary. We each make our own choices.
- Several of us have suspected for a long time that higher bit rate files can sometimes cause issues of various types. I personally can't consistently reproduce the same error in MP when I've tried to in the past -- meaning what is sometimes a problematic high bit rate track may fail, but if I replay it later, it may work fine. I therefore bet the issue lies with the CID/MCU1 just running out of CPU trying to deal with whatever else it's doing (HVAC, Nav, Phone, MP, Primary CID interface, etc) so when we give it a track to play that has too much precision data, MP's logic sometimes fails trying to keep up and we then get studders and other weird things. (That is part of the reason I am OK being back to 240kpbs with my MP3 files as it's one more set of anomalies -- even if they rarely happened to me -- that I don't have to be irritated about any more.)
- There have been situations discussed here, and at least one I helped someone else resolve where an old MP3 file they had caused MP USB to fail... IMO something happened to the file in terms of encoding or tag editing over the years that Tesla's MP logic couldn't handle, but worked fine in iTunes and the VLC player we tried. To say the least, we know Tesla's code isn't always the most robust. (Software programs that do encoding and change meta do sometimes have bugs with what they produce, and their result then lives in that file forever, even if the program is changed later on to prevent issues when encoding or editing future tracks.) The errant track was re-ripped from CD and tagged, and he didn't have the same problem in his MS again.
- Folder organization on the USB device is not likely your issue unless you have done some pretty odd things with too deep of parent/child folder relationships which can introduce memory consumption problems or perhaps other anomalies. Tesla documents nothing in this (or most any other USB) regard, but other mfgrs like Honda, Lexus, BMW and MBZ I've owned or have access to specify a max limit of 5-6 folders deep. I've recommended here in the past that people keep the depth at 1-3 max for use in Tesla.
- I also suspect Tesla ported the original guts of the USB MP code from MS to MX to M3 and besides the odd new V9 change to sorting, only changed the skin and what they had to for the UI variants. That would support why you're seeing the issue in M3 and MS.
- The issue about opening a non-driver's door and not seeing the problem is one that IIRC @supratachophobia suggested a couple years back in this thread and others have confirmed. Like most everything else, it's been reported to Tesla but nothing done about it.
- I've also use SanDisk Cruisers. It's not likely the cause of your problems, but hardware failure is always a possibility.
Reformat your USB stick. Ensure your file structure is a max 1-3 folders deep with minimal filename lengths. Put ONLY 100% MP3 files on your stick -- use the VBR -0 varient if you desire (-0 gives you ~240kbps which is the max the format allows). Assuming you then don't have too many USB tracks or too much metadata, and your Nav History and Phone Contacts are not overly excessive -- all of which can cause memory constraints, you should find better stability with consistent playback and MP USB remembering where it was within a track as you enter/exit your MS. Good luck once again.
Last edited:
BertL
Active Member
Yes. Old bug that happened at least for me upon rare occasion. IIRC, some combinations of Tesla firmware, physical smartphone and OS level seem to have more issues than others. I've not had it happen to me in several months (18.42.2, iPhone X with iOS 12.1).
Thank you for that detailed response. I went through and deleted any NON MP3 MUSIC TRACKS yesterday and there is still no changed. I know some of my folders have album artwork and pdf files for liner notes. Based on what you're saying, I should not have those on the stick. I guess what i need to do is get another stick and then gradually add folders until I find a failure point. All of this is very time consuming and really isn't something a Tesla owner should have to deal with. That being said, like you I'm an audio snob and streaming isn't an option for me with music.My theories:
My suggestion:
- I believe MP3 filetypes work better in terms of MP USB being able to both resume and be at the same place where it left off when you enter/exit a MS. I further believe, but can't prove that best success with this requires you maintain 100% MP3 files on your USB device -- otherwise it's like going to Vegas and the luck of the draw how MP may get messed-up because of scan or playback of non-MP3 files. I keep only 100% MP3 files on my USB stick for that reason and have no playback remembering issues.
- Use of MP3 VBR I don't think is as big of a deal in terms of MP stability -- it's a personal preference. VBR -0 basically provides the best retention of detail with this lossy format and helps reduce file size compared to a standard MP3. (Yes to others -- I have over-simplified that detail. If someone cares about the specifics, it's readily available elsewhere as I've linked-to in the past.
- NOTE: Because I'm a sort of audio snob wanting to maintain the best sound reproduction I can afford wherever I am -- even if I can't always hear the difference -- I originally maintained nothing but FLAC 320kbps tracks in my MS before going to MP3 VBR 240kbps. The reality is I can't tell a difference 99.9% of the time inside my MS with all the road noise -- only perhaps if I'm parked and listen closely to certain passages back-to-back with the same track encoded in both formats. That's just me. Your and other's experience may vary. We each make our own choices.
- Several of us have suspected for a long time that higher bit rate files can sometimes cause issues of various types. I personally can't consistently reproduce the same error in MP when I've tried to in the past -- meaning what is sometimes a problematic high bit rate track may fail, but if I replay it later, it may work fine. I therefore bet the issue lies with the CID/MCU1 just running out of CPU trying to deal with whatever else it's doing (HVAC, Nav, Phone, MP, Primary CID interface, etc) so when we give it a track to play that has too much precision data, MP's logic sometimes fails trying to keep up and we then get studders and other weird things. (That is part of the reason I am OK being back to 240kpbs with my MP3 files as it's one more set of anomalies -- even if they rarely happened to me -- that I don't have to be irritated about any more.)
- There have been situations discussed here, and at least one I helped someone else resolve where an old MP3 file they had caused MP USB to fail... IMO something happened to the file in terms of encoding or tag editing over the years that Tesla's MP logic couldn't handle, but worked fine in iTunes and the VLC player we tried. To say the least, we know Tesla's code isn't always the most robust. (Software programs that do encoding and change meta do sometimes have bugs with what they produce, and their result then lives in that file forever, even if the program is changed later on to prevent issues when encoding or editing future tracks.) The errant track was re-ripped from CD and tagged, and he didn't have the same problem in his MS again.
- Folder organization on the USB device is not likely your issue unless you have done some pretty odd things with too deep of parent/child folder relationships which can introduce memory consumption problems or perhaps other anomalies. Tesla documents nothing in this (or most any other USB) regard, but other mfgrs like Honda, Lexus, BMW and MBZ I've owned or have access to specify a max limit of 5-6 folders deep. I've recommended here in the past that people keep the depth at 1-3 max for use in Tesla.
- I also suspect Tesla ported the original guts of the USB MP code from MS to MX to M3 and besides the odd new V9 change to sorting, only changed the skin and what they had to for the UI variants. That would support why you're seeing the issue in M3 and MS.
- The issue about opening a non-driver's door and not seeing the problem is one that IIRC @supratachophobia suggested a couple years back in this thread and others have confirmed. Like most everything else, it's been reported to Tesla but nothing done about it.
- I've also use SanDisk Cruisers. It's not likely the cause of your problems, but hardware failure is always a possibility.
Reformat your USB stick. Ensure your file structure is a max 1-3 folders deep with minimal filename lengths. Put ONLY 100% MP3 files on your stick -- use the VBR -0 varient if you desire (-0 gives you ~240kbps which is the max the format allows). Assuming you then don't have too many USB tracks or too much metadata, and your Nav History and Phone Contacts are not overly excessive -- all of which can cause memory constraints, you should find better stability with consistent playback and MP USB remembering where it was within a track as you enter/exit your MS. Good luck once again.
I went through every folder, deleted every file not ending in .mp3 and still no change.
Another question? Has there been any testing done on the size of files that might interfere with auto playback and the constant reindexing each time you get in the vehicle? I have some shows and albums that are one big file. If that's not it, I'm at a loss as to why it won't work properly in my M3.
BertL
Active Member
Have not done physical size testing in a very long time -- it wasn't a problem maybe 2 years ago when I played with that in my MS, but I also can't remember the size of the physical file I created and disposed of -- it was a set of podcasts I put together as a single track just to see what happened. My guess is if there is a single file that's large enough, depending on Tesla's coding, it could cause an issue -- but more likely a freeze or some more horrible thing like that -- not just being unable to resume playback. The CID has a fixed amount of memory that only Tesla knows how it's managed and there is no swap space as we know with many other OS, so anything that gets too big may be problematic.
Another old problem also discussed upthread that caused rescans was use of non-latin characters in directory/file names and metadata (e.g. kanji). IIRC, that bug was resolved long ago but IDK if perhaps it's come back in some form.
Be sure you've tried all the things I suggested before including use of another USB device, a certified (not a cheap Chinese knock-off) cable if you're using one from your USB device to the Tesla, keeping directory structure rather flat, reduced number of tracks on the device, clearing your nav history and ensuring your phone contacts are not excessive (hundreds are OK, thousands may not be). The other thing is, you're running a M3 and we have no clue as to what variables that represents from the MS I own and have access to. We are in a MS thread after all.
Continued good luck in your pursuit. I'm out of additional suggestions as I have no ability to try anything in a M3.
dgpcolorado
high altitude member
My impression is that shuffle is now more random in 2018.42.2. I find that when listening to a folder in shuffle play I get a different sorting every time I turn the car back on. Anyone else notice this?
BertL
Active Member
Not my experience. Appears about the same to me across the last several updates.
Difference may be that every time the CID reboots and/or USB scan/rescan takes place, "the seed" Tesla uses for random playback selection appears to change -- IMO seeming to cause a wider or new variety of songs to be played back. This is particularly noticeable to me with 6K+ tracks almost always playing "Songs" or a selected "Genre" on random, where it seems like random tracks being selected and played-back are within certain clusters (the exact same track is not generally repeated, but related artists or track titles are played more often within a shorter timeframe than I'd expect with 6K tracks to select from.) IMO if something happens that causes my USB device to be rescanned, the clustered songs that are then randomly played are across a different part of my collection giving the appearance of better "randomness" than otherwise really exists. If my MS didn't already do unexplainable reboots and rescans on it's own from time-to-time, I'd likely force one every few weeks just to manually improve Tesla's not-as-random-as-it-could-be USB logic.
.FWIW, some of us have programmed random routines, so if this whole "randomness" or "seed" thing doesn't make sense and someone cares about the detail, it was discussed quite a while back upthread somewhere.
It's a bug. Gapless playback is a basic requirement for any media player; lack of it is a bug. It is, however, a bug present since day 1 on all Teslas, so it's not a regression.
The requirement is, in its essence, very simple. Queue up the next track and start it immediately after the previous track is finished -- not after an arbitrary pause. This requires buffering the second track so it's ready to go before the first track ends. Due to the vagaries of mp3 compression, this won't work perfectly for mp3s, but it will for FLAC or similar formats. This is all that is needed for radio plays, "Dark Side of the Moon", etc.
That's what I did for radio plays, where the stuttering is intolerable, but it's also ***ing intolerable to have one 60-minute track with no way of marking where I was in the story.
Which makes it worse for radio plays. And it can't be mp3 for the reason noted above.(and remember, if it's not MP3, you may well need to sit there and listen to the whole album, or be prepared to replay it and manually scrub back to where you were, as MP USB may not resume the long track once you leave and reenter your Tesla
I look forward to seeing whether the upcoming Audi and Jaguar EVs have decent USB media playback. If so, sayonara Tesla. This is just absurd.
Similar threads
