I do no power saving whatsoever. So whatever is the least efficient, I do. That includes range mode.
-
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
BertL
Active Member
Thx. Nothing immediately comes to mind, but it sounds you're as fanatical with tagging as I have been over the years, so our 4800 vs 7000 tracks may not end up being that different however Tesla is utilizing memory to store track and USB device access info.
BertL
Active Member
Ahhh. Sorta as I thought. Perhaps the implications of Energy Savings ON are back. I just went out and changed my MS ago Energy Savings OFF. While it won't be very analytical given its random nature, I'll see over the next few days if my rescans tend to decrease or not. More to come...
BertL
Active Member
FYI: Received 17.26.17 overnight (no specifics what it contains). Just applied and manually performed a "full reboot" of my CID after it completed. To reduce variables during Rescan PD, I have also put my Energy Savings back to ON as I normally have it. Will live with this to see how the new firmware goes before trying Energy Savings the other way. I'm sure there is more to come.
Happy 4th of July to all!
aesculus
Still Trying to Figure This All Out
Got 17.14.23 this AM. While I did not think it was possible to make the USB media worse, Tesla up and fooled me. Now every album plays the tracks in track number alpha order in the Album view. It used to do a good job of playing them in track order. I had seen alpha track order in folder view.
So now it does not play in the correct order, nor does it play in track name alpha order, but track number alpha order. So 1, 10, 11, 12, ... 2, 3 ...
So now it does not play in the correct order, nor does it play in track name alpha order, but track number alpha order. So 1, 10, 11, 12, ... 2, 3 ...
So apparently the plan is for us to wander in the wilderness for 40 years, looking for the promised USB player?
Yeah, I have an audio book right now that is causing me fits with this issue. Almost ruined a couple key plot points before I caught it.Got 17.14.23 this AM. While I did not think it was possible to make the USB media worse, Tesla up and fooled me. Now every album plays the tracks in track number alpha order in the Album view. It used to do a good job of playing them in track order. I had seen alpha track order in folder view.
So now it does not play in the correct order, nor does it play in track name alpha order, but track number alpha order. So 1, 10, 11, 12, ... 2, 3 ...
Why Tesla? How can you have no resources to fix anything, yet just enough resources to mess something up? I cannot think of any bug fix or feature addition this could be a side effect of.
Linux file system, standard directory call? Just like folders are no longer listed at the top, instead, they are interspersed with the files alphabetically....
Unless you do some extra code to deal with the situation, in all operating system if you are trying to sort numbers in text and they are in the format 1,2,3,4,5,6,7,8,9,10,11,12,etc., you will get 1.10.11.12.2.3.4.5.6.7.8.9.
I haven't tried the USB since I got the upgrade a couple of days ago. The radio had been muted when I got the upgrade and afterwards it was on high volume. I didn't think that bode well.
I haven't tried the USB since I got the upgrade a couple of days ago. The radio had been muted when I got the upgrade and afterwards it was on high volume. I didn't think that bode well.
dgpcolorado
high altitude member
I ran into the track number problem years ago with MP3 players. I learned to annotate my tracks when ripping by putting 01, 02, 03, etc. in front of each track name if I care about playback order (it was especially important when ripping CD audio books). I always use folder view, so I haven't had any issues with track play order in recent Tesla firmware versions; never have used album view.
Did an update yesterday — 17.26.76 — and my car continued with the same track it was on when I shut it down prior to the update. No issues.
Did an update yesterday — 17.26.76 — and my car continued with the same track it was on when I shut it down prior to the update. No issues.
X Fan
Active Member
+1.
To your point, I spent a lot of time changing t all 1-9 tracks were replaced by 01,02, etc and then used a tag editor to ensure that all tracks on album had proper tags and image.
I also made it easier to find albums by artist by adding a two letter tag plus underscore before album name so that I could easily see the artist album grouping when looking at album view.
Did this a while back and every subsequent update has not impacted the playability of my 5k USB song set.
It take some time but well worth the investment in getting your USB to a point where you'll be happy with your music in your Tesla.
f-stop
Active Member
I updated to 17.26.76 yesterday, release notes claimed the usual "... software fixes and enhancements" but no further specifics.
haven't done any detailed testing but after first couple drives it seems those fixes didn't include anything obvious in the area of USB playback. As far as I can tell, so far no noticeable change from recent previous versions (re: shufffle randomness, frequent loading errors, etc)
haven't done any detailed testing but after first couple drives it seems those fixes didn't include anything obvious in the area of USB playback. As far as I can tell, so far no noticeable change from recent previous versions (re: shufffle randomness, frequent loading errors, etc)
amosnomor
Member
I am repeatedly seeing, with several different USB devices, the car lose album/artist (but not song) tag information after a day or two. My current in-car collection has 124 artists, 239 albums, and 2,737 songs. The first time a renamed or reorganized usb device is inserted, everything is scanned correctly within a couple of minutes. But then a day or two later, the car has lost tag information for more than half of the artists and albums, but still has all of the songs. The folder view also remains consistent. Replugging the USB device does not force a full rescan. Rebooting the console and replugging the USB device, also does not cause a full rescan. The only thing that seems to force it to refind everything is to rewrite the device with some combination of relabeling the device and/or reorganizing the layout (typically renaming the top level folder).
Setup:
Filesystem: seen with both fat32 and ext4.
FS organization: top_level_folder/{artist}/{album}/{mp3s}
Tag generation, done with Linux. Note, in an effort to establish a working baseline, I am not even attempting to handle compilation albums:
Create copy of the original mp3 files.
Sanitize all artist folder names (replace diacriticals, spaces, punctuation)
Sanitize all album folder names (replace diacriticals, spaces, punctuation)
Sanitize track names (replace diacriticals, spaces, punctuation, add/normalize leading track numbers 01-track_name.mp3, etc...)
Extract artwork from each track and convert to 300x300 jpeg.
Clear all tags on all tracks.
Set the following tags:
Artist (TPE1) - to the name of the artist folder
Album Artist (TPE2) - to the name of the artist folder
Album (TALB) - the name of the album folder
Title (TIT2) - the name of the track
Track (TRCK) - the leading two digits of the track name (01, 02, ... 17, etc)
Image (APIC) - the 300x300 jpeg
Set full access permissions on all folders and files (0777).
BTW, here is a handy site showing the tag name mappings for different tools/platforms:
http://help.mp3tag.de/main_tags.html
I suppose that my next step will be to binary search downward in collection size to see if this misbehavior is size based.
Any suggestions? Thank you.
Setup:
Filesystem: seen with both fat32 and ext4.
FS organization: top_level_folder/{artist}/{album}/{mp3s}
Tag generation, done with Linux. Note, in an effort to establish a working baseline, I am not even attempting to handle compilation albums:
Create copy of the original mp3 files.
Sanitize all artist folder names (replace diacriticals, spaces, punctuation)
Sanitize all album folder names (replace diacriticals, spaces, punctuation)
Sanitize track names (replace diacriticals, spaces, punctuation, add/normalize leading track numbers 01-track_name.mp3, etc...)
Extract artwork from each track and convert to 300x300 jpeg.
Clear all tags on all tracks.
Set the following tags:
Artist (TPE1) - to the name of the artist folder
Album Artist (TPE2) - to the name of the artist folder
Album (TALB) - the name of the album folder
Title (TIT2) - the name of the track
Track (TRCK) - the leading two digits of the track name (01, 02, ... 17, etc)
Image (APIC) - the 300x300 jpeg
Set full access permissions on all folders and files (0777).
BTW, here is a handy site showing the tag name mappings for different tools/platforms:
http://help.mp3tag.de/main_tags.html
I suppose that my next step will be to binary search downward in collection size to see if this misbehavior is size based.
Any suggestions? Thank you.
amosnomor
Member
Forgot to mention. Late 2016 Model S. Current firmware is 17.26.76, but I've been seeing this on previous versions as well.
BertL
Active Member
@amosnomor: Thanks for the detailed post. Sorry to say, but some of your current problem is reminiscent of older issues some of us have encountered. I'm mystified about MP seeming to loose just some of the tag info as time progresses -- have not seen that one before. A couple random thoughts:
- Ever since Album Art started working, or just thereafter with another firmware drop (I forget which one), the way scan/rescan and the ability to clear all that data with a full reboot changed. I remember I documented somewhere here about album art and at least some other tag data becoming pervasive across scan/rescan and the only way to get rid of it was actually changing file structure and/or filenames. At one point, unless I changed physical album names, some of the album art stuck around. I've not explored how that may or may not be an issue again for a long time.
- Tesla of course has not documented what tags are supported. We're each making a lot of assumptions. I'm not aware that many owners are using the 4-char tag names you reference -- I was not even familiar with the possibility until your post. Given you're the first to report these new issues, it makes me wonder if you'd be having the same problem if you were using the more traditional full tag names, e.g, "ARTIST" in lieu of "TPE1". Keeping things as simple and what "most people" may use is probably the best way to try and achieve compatability with whatever Tesla's programmers support -- it's hard to say.
- You may also be one of the first (at least that has said so here) that is using a home-grown Linux process to build and manipulate data, tags and file structure. I'm sure it must be possible, but I doubt most of us have extensive experience where we can help much when it comes to that level of detail, and how it may or may not influence MP. Most of us I believe are just using common Windows or macOS utilities to copy and manipulate files from whatever music library we primiarialy use, as well as generally available tools to change tagging -- not working at e.g. a lower level with file attributes or tearing-apart and manipulating tag,data structures within the files themselves. I do know from testing I did months ago that some tag utilities created more problematic files when it came to issues I had with MP. Some of that I suspect was due to the utilities being buggy or downlevel in their use of common libraries to manipulate MP3 tagging which caused some sort of internal problems within the files themselves. Sometimes those manipulated files worked fine again say in iTunes, but I couldn't then get some tags to be recognized within MP. One file I attempted to inspect from a fellow poster here on the forum, worked on his PC, not in MP, and when I stripped all tagging away using my macOS utilitiy, I could get the file to play in his and my MS again. My point being, however one manipulates files and tag packaging within our files is yet another variable in this equation, as is how good a job MP can do reading back that file that is or isn't quite right internally at a level most of us don't want to ever deal with as an owner.
Good luck in your pursuit. I look forward to further updates as you have them.
- Ever since Album Art started working, or just thereafter with another firmware drop (I forget which one), the way scan/rescan and the ability to clear all that data with a full reboot changed. I remember I documented somewhere here about album art and at least some other tag data becoming pervasive across scan/rescan and the only way to get rid of it was actually changing file structure and/or filenames. At one point, unless I changed physical album names, some of the album art stuck around. I've not explored how that may or may not be an issue again for a long time.
- Tesla of course has not documented what tags are supported. We're each making a lot of assumptions. I'm not aware that many owners are using the 4-char tag names you reference -- I was not even familiar with the possibility until your post. Given you're the first to report these new issues, it makes me wonder if you'd be having the same problem if you were using the more traditional full tag names, e.g, "ARTIST" in lieu of "TPE1". Keeping things as simple and what "most people" may use is probably the best way to try and achieve compatability with whatever Tesla's programmers support -- it's hard to say.
- You may also be one of the first (at least that has said so here) that is using a home-grown Linux process to build and manipulate data, tags and file structure. I'm sure it must be possible, but I doubt most of us have extensive experience where we can help much when it comes to that level of detail, and how it may or may not influence MP. Most of us I believe are just using common Windows or macOS utilities to copy and manipulate files from whatever music library we primiarialy use, as well as generally available tools to change tagging -- not working at e.g. a lower level with file attributes or tearing-apart and manipulating tag,data structures within the files themselves. I do know from testing I did months ago that some tag utilities created more problematic files when it came to issues I had with MP. Some of that I suspect was due to the utilities being buggy or downlevel in their use of common libraries to manipulate MP3 tagging which caused some sort of internal problems within the files themselves. Sometimes those manipulated files worked fine again say in iTunes, but I couldn't then get some tags to be recognized within MP. One file I attempted to inspect from a fellow poster here on the forum, worked on his PC, not in MP, and when I stripped all tagging away using my macOS utilitiy, I could get the file to play in his and my MS again. My point being, however one manipulates files and tag packaging within our files is yet another variable in this equation, as is how good a job MP can do reading back that file that is or isn't quite right internally at a level most of us don't want to ever deal with as an owner.
Good luck in your pursuit. I look forward to further updates as you have them.
amosnomor
Member
@BertL, thanks for the response. I'll keep plugging away at it here.
Are you saying that you tag with [URL='http://id3.org/ID3v1']ID3 V1[/URL]? With V1, only Song Title, Artist, Album, Year, Comment, and Genre were supported. No artwork.
But I suspect we are talking about the same thing here, and it is just that I was referring directly to the [URL='http://id3.org/id3v2.3.0']ID3 v2.3.0[/URL] tag [URL='http://id3.org/id3v2.3.0#Declared_ID3v2_frames']frame names[/URL]. Most of the world is in ID3 V2.3.0. I think that ARTIST and such are the tagging tools making those 4 letter tag frame names user friendly. But to be sure, could you send me one of your mp3's with the tag frames written as you write them? I could verify by examining the file.
Or could you possibly be using a combination of ID3 V1 and V2.3.0?
[QUOTE]
- You may also be one of the first (at least that has said so here) that is using a home-grown Linux process to build and manipulate data, tags and file structure.
[/QUOTE]
I'd be happy to further document what I've done. It is a small handful of bash shell scripts and tests, which use standard Unix utilities in addition to a couple of Linux tagging tools. Not ready for prime time, as I wasn't building a product, but perhaps useful to others comfortable with Linux.
Are you saying that you tag with [URL='http://id3.org/ID3v1']ID3 V1[/URL]? With V1, only Song Title, Artist, Album, Year, Comment, and Genre were supported. No artwork.
But I suspect we are talking about the same thing here, and it is just that I was referring directly to the [URL='http://id3.org/id3v2.3.0']ID3 v2.3.0[/URL] tag [URL='http://id3.org/id3v2.3.0#Declared_ID3v2_frames']frame names[/URL]. Most of the world is in ID3 V2.3.0. I think that ARTIST and such are the tagging tools making those 4 letter tag frame names user friendly. But to be sure, could you send me one of your mp3's with the tag frames written as you write them? I could verify by examining the file.
Or could you possibly be using a combination of ID3 V1 and V2.3.0?
[QUOTE]
- You may also be one of the first (at least that has said so here) that is using a home-grown Linux process to build and manipulate data, tags and file structure.
[/QUOTE]
I'd be happy to further document what I've done. It is a small handful of bash shell scripts and tests, which use standard Unix utilities in addition to a couple of Linux tagging tools. Not ready for prime time, as I wasn't building a product, but perhaps useful to others comfortable with Linux.
BertL
Active Member
I was trying to suggest that expecting Tesla to be using the very latest of the ID3 standard, which not all legacy apps use, and may have features that are not represented in many legacy digital libraries, is probably pushing your luck.
I simply suggest since we have no idea what Tesla officially intends to support or not, we are all better off assuming only a least common denominator may work. E.g. Tesla doesn't even specify what filetypes are supported in MP today (some of us have tried many different formats to see what "seems" to work, and Tesla didn't add Album Art support until more recently -- which doesn't follow the ID3 spec per se (MP extracts art from one track in an album, then displays it for all tracks in that same album even if different tracks have different art as the spec allows.) It's very apparent to some of us the Tesla designers and engineers who have worked on MP to-date, may be into streaming sources, and not like some of us that have collected and curated our physical and digital music libraries with tag data for decades. Basic MP functions continue to be broken or not as usable as many other basic media players, so I doubt Tesla's coders have intricate knowledge of the many ins/outs and variations that exist within the rather loose ID3 specification that itself is only trying to corral decades of tagging differences.
I personally have little experience with Unix/Linux coding, and that was more than 30 years ago, so won't be able to be of further detailed assist in that regard. I'm best used as an x-systems engineer that spent a career in technical support, problem determination, HW/SW requirements definition, and customer support -- who prefers to listen to his own music library 99.9% of the time in any car he drives, including his Tesla MS. Good luck with your endeavor.
Ridiculous point, I know, but the whole purpose of universal ID3v1/2 standards is to avoid issues we are seeing..... I'd still really like Tesla to just come right and say how they read, what they support, etc.....
BertL
Active Member
Yes. It is so simple that a summer intern could rustle through Tesla specs, write it up, and it would benefit so many existing an future Tesla Owners. The problem is, you're thinking what's best for the customer today, not perhaps 10-20 years from now when people are being transported underneath downtown L.A. in their autonomous vehicles, and living on Mars.
Similar threads
