-
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
Shuffle and resume are still massively broken. The same set of songs now resumes after the current playing song when re-entering the vehicle during the day or overnight. Tracks reset on re-entry just like before. Give me a break....
BertL
Active Member
Album Art w/ 2.42.40
I have spent most of the day running additional test cases before I discard my recent set of test data. More on that in another post here this coming weekend. In the meantime, be aware that Tesla has made an interesting twist somewhere along the way with their implementation of Album Art. It's taken me a good 3.5 hours running back and forth to my MS to figure this out this afternoon, but here's the scoop (I think!):
"Album Art" is specified at the track level, meaning you can have different cover art for every track as it's defined in the ID3 standard. This isn't the way Tesla has implemented it in Media Player 2.42.40. The net is:
IMHO: This may be good from some peoples POV. Perhaps it's not all that bad if we knew what Tesla was intending. It certainly makes things a little more efficient from Tesla's playback perspective on system resources IF you play tracks in sequence (but as we know, that's for the most part broken in most views of this release.) I also appreciate the standard tag is officially called "Album Art", but the reality is, this should always be handled and presented at the track level and never consolidated the way Tesla is -- it's just an odd perversion of what the standard is, changes what audiophiles would expect, and isn't the way other Media Players work. Sigh. Another weird anomaly in the present Media Player design that was probably well intended, but in practical use just isn't the right solution especially when it's not documented to set Owner expectation Tesla has chosen a different way.
I have spent most of the day running additional test cases before I discard my recent set of test data. More on that in another post here this coming weekend. In the meantime, be aware that Tesla has made an interesting twist somewhere along the way with their implementation of Album Art. It's taken me a good 3.5 hours running back and forth to my MS to figure this out this afternoon, but here's the scoop (I think!):
"Album Art" is specified at the track level, meaning you can have different cover art for every track as it's defined in the ID3 standard. This isn't the way Tesla has implemented it in Media Player 2.42.40. The net is:
- Tesla appears to have taken "Album Art" to literally mean just that, art for all tracks with the same ALBUM (title) tag
- Tesla appears to be taking the first track within a single ALBUM, as is found alphanumerically by FILENAME, and using that for all subsequent tracks with the same ALBUM tag name, even if you have none or different Album Art specified in those other tracks. Got it? If not, read it again, it's sort of strange.
- If you delete Album Art from a specific track, but another track with a matching ALBUM tag has art, you'll still see something on the track with no art.
- A Full Reboot of the CID does not seem to necessarily eliminate all Album Art from the Cache, so it can tend to reappear even if you change the higher-level directory or filenames on your USB stick as we used to trick Media Player in earlier releases
- If you want to change Album Art for a track or tracks within an album, you need to change ALBUM (title tag) in all tracks so Media Player does not find anything in its cache. Then, you are at the mercy of your file naming convention as to what art will be displayed. The first track alphanumerically with Album Art wins.
IMHO: This may be good from some peoples POV. Perhaps it's not all that bad if we knew what Tesla was intending. It certainly makes things a little more efficient from Tesla's playback perspective on system resources IF you play tracks in sequence (but as we know, that's for the most part broken in most views of this release.) I also appreciate the standard tag is officially called "Album Art", but the reality is, this should always be handled and presented at the track level and never consolidated the way Tesla is -- it's just an odd perversion of what the standard is, changes what audiophiles would expect, and isn't the way other Media Players work. Sigh. Another weird anomaly in the present Media Player design that was probably well intended, but in practical use just isn't the right solution especially when it's not documented to set Owner expectation Tesla has chosen a different way.
Boatguy
Active Member
I did some testing on this today and the only conclusion I can reach is that the MP is very flakey.
I identified an album on my larger stick (~ 6,000 tracks) that was not displaying album art (there were many). I copied just the tracks from one album, there were 21, to a second stick.
When I inserted that stick:
- The Folders view listed 21 folders and then showed the 21 tracks. So apparently Folder view is really just whatever is on the top level of the hierarchy.
- The Album and Artist views correctly displayed the album art.
- Playing a track did not show the album art, but also would not play the tracks at all. It just sat there showing the progress bar at 1:30 and would not play.
- The stick was scanned (Loading...) quickly.
- Album and Artist views showed the album art.
- Playing a track still did not show album art and would not play. At this point I was beginning to think something was wrong with the files.
- I flipped between TuneIn, Radio, Streaming and then back to USB.
- I again tried to play the tracks and this time they displayed the album art and played with no problems. I set the shuffle and moved around the various tracks with no problems.
In any case the failure to display album art and/or play apparently has nothing to do with the files, album art, number of tracks, or any boundary condition. Just buggy code. Something else to add to the master list of bugs.
BertL
Active Member
There is a bug where playback on the Track screen just sits there, but you'll note some of the icons are greyed-out. Workaround as you found when a Media Player seems stalled on playback, is to just quickly switch to something like Radio, then back to USB and it works then as you found. Clearly another bug.
Last edited:
If it's the same album why would there be different or no art on a track? Same album same album cover jpg. I still don't get why this is problematic.
Haven't tried it myself, but given that the current player does not separate albums by the Album and AlbumArtist tag pair, but rather just the Album, you may end up having tracks from multiple real albums with the same name in the same Tesla album.
BertL
Active Member
As I said, it likely isn't a problem for some, or even many. I simply believe if there are standards with things like ID3, and most modern players adhere to those standards and expectations, why does Tesla elect to do their own thing with something they don't really need to stray from? IMHO audio standards are pretty well accepted, and are not a Tesla sweet spot like EV technology where they are out front setting the trend for our future.
OTOH, the Album Art spec already allows 15 different types of art, so basically any type of thing in any sort of combination can be attached to a track depending on ones need and desire, no different than how obsessive some people are with tagging and categorizing their music libraries for hours or weeks on end. E.g while I don't do it, I used to know of at least one guy that on some compilation albums preferred to place the original album cover that applied to each track, or perhaps put a picture of their favorite artist on some tracks -- or if it's Live, a Concert they attended, or a Broadway Theatre album, perhaps photos of those parts of the show applicable to that specific track. The possibilities are endless for those that want to make use of the standard or maybe use their music library as a digital consolidation point for more things than others do. Perhaps you or I don't want to, but isn't having the capability better than Tesla restricting something most other modern players do not?
That's retorical. You don't need to answer or respond. Peace.
aesculus
Still Trying to Figure This All Out
I spent more time trying to use the search feature with USB today. I could find only one track that came up under USB and no albums or artists. From my point USB search is totally flummoxed.
If anyone knows a secret let me know. And I tried rescanning/rebooting to see if it would help and it did not.
BTW I verified that all my tracks have an artist, genre, title and date besides album artwork embedded and have passed the very recent dbPoweramp sniff test.
If anyone knows a secret let me know. And I tried rescanning/rebooting to see if it would help and it did not.
BTW I verified that all my tracks have an artist, genre, title and date besides album artwork embedded and have passed the very recent dbPoweramp sniff test.
If you are searching for an album abc, you need to switch to the Album tab in the search results. The Songs tab will not show songs of the album abc. It will only show songs titled abc The same way, if you search for an Artist, the artist will show up in the Artist tab.
But selecting the artist will only play one song by that artist, not all of them.
It works well for me and immediately starts playing the first search result. Here's some screenshots of my search results for "play Bob Dylan" by tab.
Incidentally, my rescan this morning after opening the door to my car after it was asleep was about 15 seconds. 7040 tracks approximately 240 gigs.
Last edited:
BertL
Active Member
Scan Tests Continued - Part II (2.42.40)
For those that have no clue what I'm talking about, reference Post 589 and read forward. If you don’t care about detail, please just skip this post or perhaps read the bold summary points.
Discussion in this thread on Thursday with @aesculus and @msnow got me thinking. I was going to delete my last batch of test data yesterday morning from my Mac, but decided to embark on a few more tests before I sent it all into the sunset. Here's what I did:
Tesla has implemented ”Album Art" a bit differently from the ID3 standard. See Post #604 for detail.
Key to subsequent discussion here is that Tesla appears to be retaining some amount of Album Art across full CID reboots, and there is one piece of art for each unique Album.
TEST 5) Determine where my new Sweet Spot* really is for the number of tracks I maintain in my MS based on Scan Time (YMMV!)
* “Sweet Spot” for this exercise is a rather subjective max number of tracks on the USB stick that can both be successfully scanned, and before avg scan time per track takes a nose dive becoming increasingly long — especially given MS is still doing unnecessary rescans upon occasion.
I last did this work in Fall 2015 with V7.x firmware, timing increments of 1K tracks (and related albums) up to 15K tracks. The net at that time was scan duration started to dramatically drop-off for me somewhere between 6-7K tracks. It’s why I landed ever since housing about 6K tracks in my MS. Note that my tracks back then were from the same source as today and each track contained an original size Album Art (some in excess of 1500x1500) even if it was not displayed by Media Player — the only difference being the tracks were encoded in mostly M4A Lossy format (vs FLAC today and in these tests).
Method: I created a series of 6 actual tests, incrementally adding groups of albums & tracks to the same USB stick to finally reach the same total as TEST 2 data composed of 6829 Songs, 430 Artists, 1196 Albums, 13 Genre and 1216 Folders. Every track has a JPG of 300x300 or smaller. As before, I performed a full CID Reboot and allowed a minimum 5 minute settle time before beginning each scenario with my MS off.
Test Summary. I won't bore you with all the detail:
As previously described in my Premise #3, the actual mix and number of subdirectories, files, tracks, albums and each of the tag contents itself influence scan time. We can’t compare e.g. 1K tracks from one of us to another for that reason, as our library contents are completely different, and so scan times are gonna vary.
For me with 8.0, if I’m willing to wait long enough, I can achieve perhaps half the number of tracks being available in my MS compared to 7.1. Realistically, I need to bring the number of tracks on my USB device down by about 15% to achieve similar scan times and not worry with scans restarting.
I last did this work in Fall 2015 with V7.x firmware, timing increments of 1K tracks (and related albums) up to 15K tracks. The net at that time was scan duration started to dramatically drop-off for me somewhere between 6-7K tracks. It’s why I landed ever since housing about 6K tracks in my MS. Note that my tracks back then were from the same source as today and each track contained an original size Album Art (some in excess of 1500x1500) even if it was not displayed by Media Player — the only difference being the tracks were encoded in mostly M4A Lossy format (vs FLAC today and in these tests).
Method: I created a series of 6 actual tests, incrementally adding groups of albums & tracks to the same USB stick to finally reach the same total as TEST 2 data composed of 6829 Songs, 430 Artists, 1196 Albums, 13 Genre and 1216 Folders. Every track has a JPG of 300x300 or smaller. As before, I performed a full CID Reboot and allowed a minimum 5 minute settle time before beginning each scenario with my MS off.
Test Summary. I won't bore you with all the detail:
- First four sets of data (932, 1887, 2773, and 3738 tracks respectively) all had similar avg scan times per track within reasonable variation
- Beginning with the 5th set (4594 tracks from 835 albums), avg scan time per track increased 25-30% than any of the first four sets
- The 6th set (6829 tracks from 1197 albums) was as slow as set 5
As previously described in my Premise #3, the actual mix and number of subdirectories, files, tracks, albums and each of the tag contents itself influence scan time. We can’t compare e.g. 1K tracks from one of us to another for that reason, as our library contents are completely different, and so scan times are gonna vary.
For me with 8.0, if I’m willing to wait long enough, I can achieve perhaps half the number of tracks being available in my MS compared to 7.1. Realistically, I need to bring the number of tracks on my USB device down by about 15% to achieve similar scan times and not worry with scans restarting.
- I cannot achieve even half the number of tracks I was able to scan if I were willing to wait long enough with 7.x. Tesla’s algorithms have changed and/or memory usage is different. Today, at somewhere around 6600 tracks, the probability of my scan restarting or not completing increases.
- Because of that, and where the knee in my scan time curve appears to be, my new Sweet Spot (before scan time begins to substantially increase) for number of tracks in my MS is now closer to 5K tracks vs 6K with 7.x.
- While I can’t prove it, circumstantial observations lead me to believe that Tesla’s design decision to cache a single piece of art for each Album is consuming memory that could previously be used for track access. For someone with perhaps proportionally more Albums to Tracks, that could be another part of the reason for some of us seeing less tracks being able to be scanned with 8.0 than 7.x, as well as longer general scan times for a similar number of tracks. It all depends how Tesla codes their scanning routine. (FWIW I suspect I’m a fairly hefty 1:5.7 ratio of albums to tracks compared to some that place full albums on their USB sticks, as tracks on my USB device are for the most part my 4-5 Star tracks across my larger music library.)
TEST 6) Validate my previous assumption that eliminating all unused ID3 tags will have no effect on scan time.
Method: Same TEST 2 data: 6829 Songs, composed of 430 Artists, 1196 Albums, 13 Genre and 1216 Folders, EXCEPT that I removed all ID3 Tags except for ALBUM, ALBUMARTIST, DISCNUMBER, GENRE, TRACKARTIST, TRACKNUMBER, TRACKTITLE. Album Art remained embedded in every individual track.
My Observation: Scan Time remained effectively the same with extra tags and their data in place, and when they did not exist.
My Observation: Scan Time remained effectively the same with extra tags and their data in place, and when they did not exist.
TEST 7) Validate the effect of eliminating all unused ID3 tags AND ALL ALBUM ART on scan time.
Method: Same TEST 6 data: 6829 Songs, composed of 430 Artists, 1196 Albums, 13 Genre and 1216 Folders, where I removed all ID3 Tags except for ALBUM, ALBUMARTIST, DISCNUMBER, GENRE, TRACKARTIST, TRACKNUMBER, TRACKTITLE, and Album Art was also removed from every individual track. In other words, these tracks in a 2-level directory structure have only the basic tag data needed to play and use them within Media Player (assuming Tesla fixes other previously described bugs and requests.)
My Observation: Scan Time was approximately 8% faster without any embedded Album Art. Of note though: Tracks I randomly checked still showed Album Art after the scan was complete. This was how I found and starting investigating the oddities associated with Tesla’s Implementation of Album Art.
My Observation: Scan Time was approximately 8% faster without any embedded Album Art. Of note though: Tracks I randomly checked still showed Album Art after the scan was complete. This was how I found and starting investigating the oddities associated with Tesla’s Implementation of Album Art.
GENERAL NOTES:
Twice in my 11 times attempting to scan my full 6829 library, I had instances where the scanning process went berserk. I’ve never encountered symptoms like this. Perhaps you have. My assumption is I've hit some sort of wall with memory usage, be that physically, or how it's used during scan -- or this whole Album Art thing can create another type of bug:
- Scanning began as normal. The "Loading (_%)..." indicator typically shows numbers incrementing over time, sometimes bouncing between 1 digit up/down I suspect because of odd rounding issues. Fine. In this case though during the initial scan, the Loading indicator constantly flipped between two numbers as their spread increased over time, e.g. 1% & 10%, 22% & 35%, 54% & 82%.
- Somewhere after 92% complete (when I last physically checked it), and then came back, I found the scanning process had restarted. It processed normally to completion.
- The scan reached 99%, then Loading started alternating with 100%, and within a few seconds, Media Player restarted the scan from zero. No CID reboot took place, but the scanning process was normal in the subsequent run.
aesculus
Still Trying to Figure This All Out
Mine does not even come close to this. It's also interesting your song titles look more like file names.
If you are referring to the underscores, those particular tracks were converted incorrectly using underscores instead of spaces. If I had scrolled down more on that tab or picked a different artist you wouldn't have seen spaces instead. If you mean something else let me know.
aesculus
Still Trying to Figure This All Out
No. Not just the underscore but the entire name. Your songs are listed with file names including the .jpg
I could see this if you were in folder view, but not songs view.
Interesting. Perhaps @BertL could explain why that is and if it has any material impact on search results.No. Not just the underscore but the entire name. Your songs are listed with file names including the .jpg
I could see this if you were in folder view, but not songs view.
Similar threads
