Thanks Everyone, your insight from ownership is invaluable!!
I read through your website as well quite informative, Thanks BertL!
I read through your website as well quite informative, Thanks BertL!
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Have they fixed shuffling songs on usb devices?
- Thread starter Tech_Guy
- Start date
-
- Tags
- Model S User Interface
doctorwho
Active Member
It seems like it would take only a few minutes worth of re-coding for Tesla to fix this problem and many other small annoying niggles that we encounter daily. It's costing Tesla bandwidth as I just stream any compilation album on Spotify now as they are unplayable without frustration via the USB port
BertL
Active Member
Boatguy
Active Member
Tesla should just make CarPlay or Android Auto an option and deflect all these problems to Google and Apple. Tesla engineering should go to unique added value, not re-inventing the wheel (or jukebox as the case may be).
All MS's now come with the center console which has a phone dock so the music / podcast / whatever should come from our phones. Then we can all buy phones with more memory rather than buying big USB sticks and the second USB port can be used for another phone or whatever.
All MS's now come with the center console which has a phone dock so the music / podcast / whatever should come from our phones. Then we can all buy phones with more memory rather than buying big USB sticks and the second USB port can be used for another phone or whatever.
doctorwho
Active Member
Boatguy
Active Member
doctorwho
Active Member
thecloud
As rhythm raced inside, the ship came alive
As you face the back or the front?
Seriously, I wasn't aware that the power output was different between the two ports. Has anyone measured this?
Edit: apparently somebody did, and the difference was negligible; both measured under 1A. Somebody else measured both ports at 0.5A. But another article says that the driver's side port puts out 2.1A while the passenger side port was 1A. Sounds like a rumor...
doctorwho
Active Member
I use the drivers side port (in a RHD car). The passenger side port will activate the drive but it will never read and mount. The driver's side port works fine. You need to use a portable HDD that is powered solely by USB though
Boatguy
Active Member
What is resolution and compression state of most of the content?
E.g., 256Kbs AAC or 44.1 AIFF, FLAC, etc.
doctorwho
Active Member
Mostly flac compression level 0 or 3, 320kbs AAC or mp3. Plays fine, no buffering uses but I had to try a few HDDs as some weren't fast enough or couldn't cope with the movement
Boatguy
Active Member
It's a bit counterintuitive, but uncompressed requires more bandwidth, but less processing. The net being that large files may be more easily accommodated than small.
BertL
Active Member
Two issues I think.
- Can the USB device feed Media Player with data as fast as it expects? If the non-flash USB device were too slow, or not getting enough power to operate correctly, that would be an issue IMHO Tesla does not have control over.
- Then your point that FLAC does not require as much processing as compressed formats within the CID itself. I agree, and it's why I speculate there are some priority issues going on within the Tesla OS not ensuring high enough priority to Media Player and Nav Verbal announcements so they can continuously output the sound, OR Tesla isn't anticipating and loading enough of the track data from the USB device ahead of when it's really needed to continuously process and provide the sound -- be that directly out or through any auxiliary sound processors involved.
Boatguy
Active Member
The storage device will either work or not, insufficient power will cause it not to work, there is no gray zone in digital devices where they work more slowly with less current. The current requirements for a thumb drive are negligible, compared to the requirements of a rotating mechanical external disk that DrWho is using.
Regarding data transfer speed, uncompressed CD quality is just 44,100 samples / sec * 16 bits / sample = 706 kbs / 8 = 88kBs. The cheapest thumb drive you can find will still perform in the MB / sec range, 10 - 100x faster than needed to support the transfer of lossless compressed CD quality (e.g., AIFF, FLAC) audio. Read speed is not an issue. Keep in mind that CDs were invented in the late 70's; they required very little processing power or bandwidth. Decompressing data takes some CPU cycles, but nothing that would tax the processor in the MS, and with FLAC/AIFF there is even less decompression time (lossless compression is very very simple).
I suspect this is more an issue of supporting real time processing. The CID is processing lots of stuff at the same time, most of which does not require "real time" processing; a term of art in processing. Music on the other hand needs real time because our ears can hear when it stutters by 50ms.
My speculation is that it's just bad programming. The code has not been written with sufficient buffering to enable smooth playback while also attending to all the other tasks being performed concurrently in the CID and/or a myriad of other programming architecture failures which could cause it to not be meeting the real time playback requirements of the music. It's quite likely that Tesla licensed a chunk of code from someone to handle the core audio processing and the integration of that code into all the other CID tasks was not done with sufficient skill such that it violates some boundary conditions for the licensed code from time to time.
Net, net: poor programming.
Last edited:
doctorwho
Active Member
Poor programming.... that hasn't been corrected in 3 years. Surely it wouldn't take much time for a competent programmer?
I suspect the code modules for the display aren't isolated enough so there is a whack-a-mole problem--fix one thing, break something else. In general, the only fix that is with a complete rewrite.
BertL
Active Member
Since none of us have access to the code itself, I doubt any of us really know the true cause. We can speculate from symptoms we see, but that's about it.
Don't forget though that Elon himself is a coder. He personally wrote original parts of PayPal not that long ago. According to the book on him, and other articles I've read, he's been known to look at code segments from prospective engineers before he hires them at Tesla. Given Elon engages in detail much of the time with everything that is Tesla, I don't suspect he would allow messy code -- especially code that was there in the early days building his longer-term baby, as he would know -- if anyone would -- how impossible it would become to fix or enhance it later IF he chose to on his way to his future vision. To that point, I believe all these issues not being resolved, are ONLY because Elon does not see them as important and he has not therefore prioritized their being fixed -- even though resolution and enhancement of Infotainment for some of his owners would dramatically improve their Customer Satisfaction and daily driving experience with an otherwise stellar product. Net: Elon does not personally care, so it does not get done.
Don't forget though that Elon himself is a coder. He personally wrote original parts of PayPal not that long ago. According to the book on him, and other articles I've read, he's been known to look at code segments from prospective engineers before he hires them at Tesla. Given Elon engages in detail much of the time with everything that is Tesla, I don't suspect he would allow messy code -- especially code that was there in the early days building his longer-term baby, as he would know -- if anyone would -- how impossible it would become to fix or enhance it later IF he chose to on his way to his future vision. To that point, I believe all these issues not being resolved, are ONLY because Elon does not see them as important and he has not therefore prioritized their being fixed -- even though resolution and enhancement of Infotainment for some of his owners would dramatically improve their Customer Satisfaction and daily driving experience with an otherwise stellar product. Net: Elon does not personally care, so it does not get done.
Boatguy
Active Member
Exactly! The only way they will improve Infotainment is when Elon wants it done, and then only when the current system has become a problem for him.
I don't have first hand experience with CarPlay or Android Auto, but I believe that at least CarPlay is vastly superior to what Tesla has today. If Tesla does nothing, then when the Bolt ships they are going to have to explain why the most advanced car is less advanced than a Chevy. Look at the list of manufacturers and cars on those CarPlay and Android Auto web sites. How much longer is Tesla going to ship an inferior infotainment system?
Guys, there is no non-volatile (flash) memory space problem on the CID. There's always several gig available free for things like calendar, nav destinations, etc. The big problem is CPU horsepower. The CID usually runs at around 2 load average, which is very high. After being "up" for over a week the memory gets somewhat fragmented and it creates even more load and less free RAM. I recommend a reboot at least once a week or when slowdowns are experienced. Deleting stuff like bookmarks and nav history will not change anything.
There is no difference in the USB ports, and during assembly the order is randomized thanks the the 2 ports having the exact same connectors on the wiring harness. There's no way to tell which is which when connecting the MCU. If you are experiencing a problem with one port, then it's probably due to dirt in the connector causing higher than normal resistance. Spray some plastic-safe electrical contact cleaner in there and then work the connection some.
The biggest problem I've witnessed is the huge amount of logging Tesla is doing. This is all constantly hammering the MMC flash and I suspect it's going to lead to the failure of many units. (probably when out of warranty) They are really pushing it's endurance with constant high-rate logging. For example, trying to tail the syslog in real time while reading it all is almost impossible because of the amount it's spewing. And that's just one log file!
Second to this is the CPU workload. Just too much going on all the time that keeps the CPU load average at 2, even when the car is "off". Disabling some of the logging gets this number down a little, but not an option available to owners unfortunately. At time goes on things have been getting better. Let's hope Tesla cleans it up even more in the future. Also, as they get things tighter the need for extensive logging goes down, so this will help too.
As for music files, the higher bit rate MP3's seem to use a little more CPU load. I have not yet compared this to FLAC. I seem to have no trouble with 320kbps MP3's, but YMMV.
There is no difference in the USB ports, and during assembly the order is randomized thanks the the 2 ports having the exact same connectors on the wiring harness. There's no way to tell which is which when connecting the MCU. If you are experiencing a problem with one port, then it's probably due to dirt in the connector causing higher than normal resistance. Spray some plastic-safe electrical contact cleaner in there and then work the connection some.
The biggest problem I've witnessed is the huge amount of logging Tesla is doing. This is all constantly hammering the MMC flash and I suspect it's going to lead to the failure of many units. (probably when out of warranty) They are really pushing it's endurance with constant high-rate logging. For example, trying to tail the syslog in real time while reading it all is almost impossible because of the amount it's spewing. And that's just one log file!
Second to this is the CPU workload. Just too much going on all the time that keeps the CPU load average at 2, even when the car is "off". Disabling some of the logging gets this number down a little, but not an option available to owners unfortunately. At time goes on things have been getting better. Let's hope Tesla cleans it up even more in the future. Also, as they get things tighter the need for extensive logging goes down, so this will help too.
As for music files, the higher bit rate MP3's seem to use a little more CPU load. I have not yet compared this to FLAC. I seem to have no trouble with 320kbps MP3's, but YMMV.
thecloud
As rhythm raced inside, the ship came alive
Ingineer: it's worrisome that you're seeing a constant CPU load average of 2. If that's always the case, I'm surprised audio playback contending for CPU time isn't stuttering more.
Earlier in this thread (2 weeks ago), after having to reboot twice in the span of 2 days, I did these things:
1. Erased my 64GB USB stick for a fresh start.
2. Recopied ~1200 music files to the USB stick. These are a mix of FLAC and MP3 (320 Kbps). I used 3 levels in my directory hierarchy: a top-level directory named Music, under which are multiple artist directories (plus a Compilations directory), and under those are directories for the individual albums.
3. Deleted everything that wasn't a music file. There were handfuls of JPEG cover thumbnails and the ubiquitous invisible .DS_Store files that Mac OS X creates when you open a directory in Finder. I got rid of the latter by running this command in Terminal (replace /Volumes/STICK with the path to the USB drive that you're using):
find /Volumes/STICK -name '.DS_Store' -print0 | xargs -t0 rm
4. Inserted the USB stick in the port closest to the driver's seat, and started playing with Shuffle enabled.
5. About a week later, I wanted to put another album on the drive. After doing so, I renamed the top-level directory to "Music-001", which caused the directory cache to be rebuilt when I reinserted the drive. Thanks to BertL for the suggestion.
So, after 2 weeks (and one intervening software update, 2.18.77), I've had zero stuttering or playback problems.
Well, almost zero: I've definitely seen the ongoing "phantom playback" issue. Just today, I clicked on the Recently Played icon and noticed that the car had been playing music from my USB drive all night long, going back to yesterday when I last drove the car. Will have to remember to switch the source to Bluetooth before exiting next time.
Earlier in this thread (2 weeks ago), after having to reboot twice in the span of 2 days, I did these things:
1. Erased my 64GB USB stick for a fresh start.
2. Recopied ~1200 music files to the USB stick. These are a mix of FLAC and MP3 (320 Kbps). I used 3 levels in my directory hierarchy: a top-level directory named Music, under which are multiple artist directories (plus a Compilations directory), and under those are directories for the individual albums.
3. Deleted everything that wasn't a music file. There were handfuls of JPEG cover thumbnails and the ubiquitous invisible .DS_Store files that Mac OS X creates when you open a directory in Finder. I got rid of the latter by running this command in Terminal (replace /Volumes/STICK with the path to the USB drive that you're using):
find /Volumes/STICK -name '.DS_Store' -print0 | xargs -t0 rm
4. Inserted the USB stick in the port closest to the driver's seat, and started playing with Shuffle enabled.
5. About a week later, I wanted to put another album on the drive. After doing so, I renamed the top-level directory to "Music-001", which caused the directory cache to be rebuilt when I reinserted the drive. Thanks to BertL for the suggestion.
So, after 2 weeks (and one intervening software update, 2.18.77), I've had zero stuttering or playback problems.
Well, almost zero: I've definitely seen the ongoing "phantom playback" issue. Just today, I clicked on the Recently Played icon and noticed that the car had been playing music from my USB drive all night long, going back to yesterday when I last drove the car. Will have to remember to switch the source to Bluetooth before exiting next time.
Similar threads
