Comprehensive USB Bug List

[Boatguy]

As reported much earlier upthread in one of my dissertations , I have some JPG and PNGs that display fine in native Mac, iTunes, iOS Music Player, and work with non-Apple apps like Pixelmator and some others, but fail with Photoshop and in Tesla's Media Player. I'm not astute enough to understand all the color implications, but IIRC I narrowed it down a few weeks ago to some problem with Color Spaces. I found the dBpoweramp JPEG Conversion option, and those same pieces of art in my case do show OK in Media Player after its conversion in my workaround process. I may have some other art that does not show correctly in my Tesla like you're finding, but I have not yet noticed any thus far ...sorta hard to scan through 6K tracks and check them out one-by-one sitting in my MS.

If you do track down something more specific on the pieces of art not showing in the Tesla, please report back. I'd suggest you send me the failing art itself via email, but I'm honestly beyond my skill level trying to do any more debugging on graphics and color standards to go any further on that oddity. Good luck!

I used the dbPowerAmp work around to process all the art down to 300x300 and some tracks with that art are not displaying album art. I'll send you a sample.

 

[BertL]

I used the dbPowerAmp work around to process all the art down to 300x300 and some tracks with that art are not displaying album art. I'll send you a sample.

I've sent @Boatguy an email with more detail.

Net for others is it seems Tesla still (as of .40) does have an odd issue with art not displaying in all circumstances.

I tried his example track in my MS and embedded art displays fine. I extracted and inspected the art. It has characteristics like the rest of mine. I tried viewing it with multiple macOS tools and all is good. The key difference between our MS environments is the number of tracks Media Player has access to on the single USB device... In my tests of 2 tracks and ~6800, the art displays fine. In his with some other number (larger I think), the art fails to appear as the track is played.​

 

[RichardL]

I just got .121 on my X. Since I recently did some timing tests and still have the identical stick, I thought I would check the load times again.

I did a full reboot (including brake) after install. Sitting in the garage, the large item load, which previously took 11 minutes, loaded in 7 minutes - so a noticeable improvement for me. Obviously no idea yet how long that will become while actually driving. Still need to see if there is any kind of caching across shutdowns which never previously happened on the X

Another issue, the reboot did not cause the favorite station logos to refresh, even when listening to the station with the wrong image

 

[msnow]

I just got .121 on my X. Since I recently did some timing tests and still have the identical stick, I thought I would check the load times again.

I did a full reboot (including brake) after install. Sitting in the garage, the large item load, which previously took 11 minutes, loaded in 7 minutes - so a noticeable improvement for me. Obviously no idea yet how long that will become while actually driving. Still need to see if there is any kind of caching across shutdowns which never previously happened on the X

Another issue, the reboot did not cause the favorite station logos to refresh, even when listening to the station with the wrong image

How many tracks and how many gigs do you have on that stick? Mine still takes 2 minutes for over 7k tracks 240 gigs.

 

[BertL]

...Another issue, the reboot did not cause the favorite station logos to refresh, even when listening to the station with the wrong image

Not related to USB and this thread, but while it's a PIA, how about you try deleting your FM favorite now that you are in the right city, then add it back? Hopefully you'll get the correct-for-you logo that way.

 

[Boatguy]

How many tracks and how many gigs do you have on that stick? Mine still takes 2 minutes for over 7k tracks 240 gigs.

That's very fast. Please tell us (again) the file structure you are using.

To their credit, Tesla is not reading every byte on the stick to retrieve the tag data since USB 2.0 would take hours to transfer the entire contents of the stick.

 

[msnow]

That's very fast. Please tell us (again) the file structure you are using.

To their credit, Tesla is not reading every byte on the stick to retrieve the tag data since USB 2.0 would take hours to transfer the entire contents of the stick.

Sure, it's Music/Artist/Album. There's really no need for the "Music" folder other than its consistent with the structure of my iTunes folders. My stick is a PNY Elite 256G.

 

[supratachophobia]

Sure, it's Music/Artist/Album. My stick is a PNY Elite 256G.

That would further confirm that the more flat the directory structure, the faster the scanning.

 

[BertL]

Guys, it may not have been covered all together in this particular thread, but there are several things that (at least I continue to believe) are fact related to USB scan times through 2.42.40:

1. More depth to the directory structure will add scan time.
   • Remember though, with 8.0 2.36.108, if it was too shallow, it would cause Media Player to (I suspect run out of resources) and never complete scanning for some people. My same stick of 6100 tracks worked in 7.1, but would never complete scanning even after 2 hours with the initial drop of 8.0. When I moved from a 3 to a 2-deep directory structure, the same tracks completed scanning and were playable. Others had no problem with libraries much larger.
   • As I continue to recommend, if you have any sizable library, at least a 2-deep directory structure is best, and don't add more than you really need as it impacts scan time and memory consumption.
2. The physical size of the files and total data just don't make that big of a difference.
3. I continue to suspect that as Tesla evolves their scanning algorithms, this is changing, but the length of directory names, filenames, and tag content itself (including how much is or isn't duplicated) influences scan time. It's why none of our numbers match from person-to-person despite everyone asking questions and posting numbers that make at least me a bit crazy. As to how these things influence scan time, only Tesla programmers could hesitate a guess. X-programmers like myself can think of a zillion ways that different approaches would influence time up or down, and without any sort of detailed release notes to this fine level of detail, it's not worth our guessing here as our world can change with each new firmware drop.

To prove my points to non-believers, I just completed several tests. My MS was sitting in my garage OFF, with only the driver door open, no music playing, and I wasn't fiddling with the IC or CID. Before each test, I performed a full CID reboot (foot on brake version), then waited at least 5 minutes for it to settle down, Nav maps being fully displayed and my WiFi connection having been re-established. Thats about as close to the same environment for each test as I could get.

TEST 1) 6829 Songs, composed of 430 Artists, 1196 Albums, 13 Genre and 1 Folder - 161GB in size on a PNY Elite 256GB Stick

• A 3-level directory structure: YYYY-MM-DD/ALBUM-ALBUMARTIST/tracks
• It took 21 minutes to scan
• This becomes my baseline test case

TEST 2) Same 6829 Songs, composed of 430 Artists, 1196 Albums, 13 Genre and 1216 Folders - 161GB in size on a PNY Elite 256GB Stick

• A 2-level directory structure: ALBUM-ALBUMARTIST/tracks
• It took 17 minutes to scan
• I believe this is a good proof point towards my premise point #1. FWIW, this is what I have migrated back to in my MS.

TEST 3) Same 6828 Songs plus 1*, composed of 430 Artists, 1196 Albums, 13 Genre and 1216 Folders - 201GB in size on a PNY Elite 256GB Stick.

*What I did here was manually reconstruct one track to fill up a whole lotta space with a bunch of nothing, so I still had 6829 tracks, it's just the aggregate contents of all files on the stick was ~25% larger.​

• The same 2-level directory structure: ALBUM-ALBUMARTIST/tracks
• It took the same 17 minutes to scan
• I believe this is an adequate proof point towards my premise point #2.

TEST 4) Same 6829 Songs, composed of 1 Artists, 1 Albums, 1 Genre and 1216 Folders - 161GB in size on a PNY Elite 256GB Stick

What I did was make a mass change of the TRACKARTIST, ALBUM, and GENRE tags in each of the 6829 tracks to be the same for my whole library. Completely unreasonable use-wise, but a great test case (yes, I used to make test data in the good 'ol days for my programs and systems).​

• The same 2-level directory structure: ALBUM-ALBUMARTIST/tracks
• It took a whopping 39 minutes to scan (compare against test case #2). That's extraordinary isn't it?
• I believe this is a great proof point towards my premise point #3.

THE NET IMHO:

• If we want to do high level comparisons of USB scan times, we need to specify both number of tracks and depth of the directory structure. Even with that, as I've suggested for a very long time, there is HUGE variability in how each of us names and tags each and every track that prevents us from providing any useful comparative scan data that we can draw any real conclusions from. I'm over it, and IMHO you should be too.
• I just know scan times are far too long, and could use an extraordinary amount of tuning AFTER other bugs are addressed.

 

[supratachophobia]

This would support my longer scan times with small amounts (in GB) of music. I have Genre/Sub-Genre/Artist/Album/Track

 

[X Fan]

Great info guys....appreciate the work you are doing to inform the USB community....now, if only Tesla would send me 2.44.12 or even 2.42.40, I could join the analytics party......

 

[msnow]

Guys, it may not have been covered all together in this particular thread, but there are several things that (at least I continue to believe) are fact related to USB scan times through 2.42.40:

1. More depth to the directory structure will add scan time.
   • Remember though, with 8.0 2.36.108, if it was too shallow, it would cause Media Player to (I suspect run out of resources) and never complete scanning for some people. My same stick of 6100 tracks worked in 7.1, but would never complete scanning even after 2 hours with the initial drop of 8.0. When I moved from a 3 to a 2-deep directory structure, the same tracks completed scanning and were playable. Others had no problem with libraries much larger.
   • As I continue to recommend, if you have any sizable library, at least a 2-deep directory structure is best, and don't add more than you really need as it impacts scan time and memory consumption.
2. The physical size of the files and total data just don't make that big of a difference.
3. I continue to suspect that as Tesla evolves their scanning algorithms, this is changing, but the length of directory names, filenames, and tag content itself (including how much is or isn't duplicated) influences scan time. It's why none of our numbers match from person-to-person despite everyone asking questions and posting numbers that make at least me a bit crazy. As to how these things influence scan time, only Tesla programmers could hesitate a guess. X-programmers like myself can think of a zillion ways that different approaches would influence time up or down, and without any sort of detailed release notes to this fine level of detail, it's not worth our guessing here as our world can change with each new firmware drop.

To prove my points to non-believers, I just completed several tests. My MS was sitting in my garage OFF, with only the driver door open, no music playing, and I wasn't fiddling with the IC or CID. Before each test, I performed a full CID reboot (foot on brake version), then waited at least 5 minutes for it to settle down, Nav maps being fully displayed and my WiFi connection having been re-established. Thats about as close to the same environment for each test as I could get.

TEST 1) 6829 Songs, composed of 430 Artists, 1196 Albums, 13 Genre and 1 Folder - 161GB in size on a PNY Elite 256GB Stick

• A 3-level directory structure: YYYY-MM-DD/ALBUM-ALBUMARTIST/tracks
• It took 21 minutes to scan
• This becomes my baseline test case

TEST 2) Same 6829 Songs, composed of 430 Artists, 1196 Albums, 13 Genre and 1216 Folders - 161GB in size on a PNY Elite 256GB Stick

• A 2-level directory structure: ALBUM-ALBUMARTIST/tracks
• It took 17 minutes to scan
• I believe this is a good proof point towards my premise point #1. FWIW, this is what I have migrated back to in my MS.

TEST 3) Same 6828 Songs plus 1*, composed of 430 Artists, 1196 Albums, 13 Genre and 1216 Folders - 201GB in size on a PNY Elite 256GB Stick.

*What I did here was manually reconstruct one track to fill up a whole lotta space with a bunch of nothing, so I still had 6829 tracks, it's just the aggregate contents of all files on the stick was ~25% larger.​

• The same 2-level directory structure: ALBUM-ALBUMARTIST/tracks
• It took the same 17 minutes to scan
• I believe this is an adequate proof point towards my premise point #2.

TEST 4) Same 6829 Songs, composed of 1 Artists, 1 Albums, 1 Genre and 1216 Folders - 161GB in size on a PNY Elite 256GB Stick

What I did was make a mass change of the TRACKARTIST, ALBUM, and GENRE tags in each of the 6829 tracks to be the same for my whole library. Completely unreasonable use-wise, but a great test case (yes, I used to make test data in the good 'ol days for my programs and systems).​

• The same 2-level directory structure: ALBUM-ALBUMARTIST/tracks
• It took a whopping 39 minutes to scan (compare against test case #2). That's extraordinary isn't it?
• I believe this is a great proof point towards my premise point #3.

THE NET IMHO:

• If we want to do high level comparisons of USB scan times, we need to specify both number of tracks and depth of the directory structure. Even with that, as I've suggested for a very long time, there is HUGE variability in how each of us names and tags each and every track that prevents us from providing any useful comparative scan data that we can draw any real conclusions from. I'm over it, and IMHO you should be too.
• I just know scan times are far too long, and could use an extraordinary amount of tuning AFTER other bugs are addressed.

So if the conclusion is my fast 2 minute scan time is based on tagging and naming I thought I should mention that mine were ripped and tagged from WAV, FLAC or Monkey using a very old version of Tag&Rename (used global defaults for tagging and naming Windows only) converted to MP3 with dbPowerAmp at 320 Kbps then for the Tesla stick I used (I think) HandBrake Free MAC to go to FLAC on the stick.

 

[BertL]

So if the conclusion is my fast 2 minute scan time is based on tagging and naming I thought I should mention that mine were ripped and tagged from WAV, FLAC or Monkey using a very old version of Tag&Rename (used global defaults for tagging and naming Windows only) converted to MP3 with dbPowerAmp at 320 Kbps then for the Tesla stick I used (I think) HandBrake Free MAC to go to FLAC on the stick.

...it's what the names of your directories and files actually are, and the contents of your tags themselves that are the big variables; likely not the tools used to accomplish those things.

There could also be something with file type that changes with Media Player scan. I've thought of that, but not spent the time to try timing with enough files, then making different sets with same filenames/tags through each supported encoding method, to make any sort of statement. It well could be a difference, but I just see it as an outlier case why Tesla would write code like that. Again, only Tesla personnel would know until someone other than me has many hours to build all the test data and do the test work required.

Another variable of course is the physical USB device itself. I've been through a lot. E.g. I have one of my in-theory fast PNY Elites that is great, but a cheaper and slower PNY and SanDisk that are nearly as fast. Then again, I have another of my fast PNY Elites that is presently in transit back to NY because it wrote and read fine for the first week, but all of a sudden became a tortoise trying to read any data from it. Point being, physical device is yet another variable, and IMHO these newer 256GB sticks are far more problematic than the older, cheaper and smaller capacity varieties from the same big names. It seems I get a good one, a dud (I'm just returning one of my Patriots for the third time in 3 months), or they fail after a few hours of use. It's why in tests like I've been trying to do, I take the time to rebuild onto the same stick each time trying to eliminate variables when I can -- but as a comparative point between owners, the physical USB stick may well be part of the scan time variance, especially the time it takes for it to first be recognized as it's inserted into the MS USB slot. (My timinings are from the moment I plug the device in, not when it shows on the Media Player menu, until the views are presented for play, and remember, I had at least one stick that seemed fine from a macOS a perspective, but was throwing internal errors to the CID only my SvC could see.). It's difficult to be sure.

 

[msnow]

...it's what the names of your directories and files actually are, and the contents of your tags themselves that are the big variables; likely not the tools used to accomplish those things.

There could also be something with file type that changes with Media Player scan. I've thought of that, but not spent the time to try timing with enough files, then making different sets with same filenames/tags through each supported encoding method, to make any sort of statement. It well could be a difference, but I just see it as an outlier case why Tesla would write code like that. Again, only Tesla personnel would know until someone other than me has many hours to build all the test data and do the test work required.

Another variable of course is the physical USB device itself. I've been through a lot. E.g. I have one of my in-theory fast PNY Elites that is great, but a cheaper and slower PNY and SanDisk that are nearly as fast. Then again, I have another of my fast PNY Elites that is presently in transit back to NY because it wrote and read fine for the first week, but all of a sudden became a tortoise trying to read any data from it. Point being, physical device is yet another variable, and IMHO these newer 256GB sticks are far more problematic than the older, cheaper and smaller capacity varieties from the same big names. It seems I get a good one, a dud (I'm just returning one of my Patriots for the third time in 3 months), or they fail after a few hours of use. It's why in tests like I've been trying to do, I take the time to rebuild onto the same stick each time trying to eliminate variables when I can -- but as a comparative point between owners, the physical USB stick may well be part of the scan time variance, especially the time it takes for it to first be recognized as it's inserted into the MS USB slot. (My timinings are from the moment I plug the device in, not when it shows on the Media Player menu, until the views are presented for play, and remember, I had at least one stick that seemed fine from a macOS a perspective, but was throwing internal errors to the CID only my SvC could see.). It's difficult to be sure.

I brought up the tools because I used their global defaults. Such as artistname would be tagged artist firstname space lastname. Same with album title, track, etc. I noticed my original metadata is pretty extensive and that's because the tool allows for going out to various Internet databases to pull as much about each album, artist, track, art, songwriters, dates, genre, etc, etc as you want.... I only mentioned that because it's more data than normal. Probably excessively so. Therefore all of the tracks, folders, names follow the same natural language format which I didn't alter, expand or shorten. I would guess we all have that. I also think that recoding from MP3 to FLAC may have pulled out some of those ID3's not sure as I haven't looked.
I don't really understand the comment about file type as all of mine are FLAC but I do agree that there's still an open question about media device type except for the fact that we both have 256G PNY Elites with a similar number of files and size yet very different scan times. Our disk read times should be the same, right?
I know your testing ruled this out but it does make logical sense that the more files you have and the more complex file structure you use should impact scan times but I'll take your word it doesn't.

Again, thanks for your tireless testing of this but in the end we are at the mercy of boys and girls in Fremont. .

 

[aesculus]

FWIW when adding my album art directly to the tracks from my folder.jpg files, I ran into about 50 tracks there were basically corrupt with regard to tags. I could not change the tags or the artwork using dbpoweramp of the companion PerfectTunes app. The way I had to fix it was to do a batch update with dbPoweramp on the selected albums/files and then I was able to go and cleanup and add the artwork.

Not sure if this had any affect on my cars ability to scan but after doing so my 3500 tracks do load in less than 2 minutes on 2.40.21

 

[BertL]

I brought up the tools because I used their global defaults. Such as artistname would be tagged artist firstname space lastname. Same with album title, track, etc. I noticed my original metadata is pretty extensive and that's because the tool allows for going out to various Internet databases to pull as much about each album, artist, track, art, songwriters, dates, genre, etc, etc as you want.... I only mentioned that because it's more data than normal. Probably excessively so. Therefore all of the tracks, folders, names follow the same natural language format which I didn't alter, expand or shorten. I would guess we all have that. I also think that recoding from MP3 to FLAC may have pulled out some of those ID3's not sure as I haven't looked.
I don't really understand the comment about file type as all of mine are FLAC but I do agree that there's still an open question about media device type except for the fact that we both have 256G PNY Elites with a similar number of files and size yet very different scan times. Our disk read times should be the same, right?
I know your testing ruled this out but it does make logical sense that the more files you have and the more complex file structure you use should impact scan times but I'll take your word it doesn't.

Again, thanks for your tireless testing of this but in the end we are at the mercy of boys and girls in Fremont. .

Thx.

Tools are interesting, but from my knowledge, what goes into the tags is rather free format for most of them (not all)... I spent lots of time a long time ago going through everything in my library were all "firstname lastname" and not some other permutation, same with groups, common misspellings, etc -- but again, unless Tesla has done something really unexpected coding-wise, I don't see data inside tags as an issue. We know e.g they are not parsing TRACKARTIST into seperate artists as they probably should, so I doubt they are doing it elsewhere.

As far as extra tags, again, I doubt that is an issue. I think I've proven that the physical size of a track does not create a problem, so having tags that the interface never uses are simply bypassed. Tesla like any app would be looking for specific tags and ignoring the rest. I too have some tracks with I'd guess 20 tags... so that's not a difference between us.

If conversion tools are well behaved, they shouldn't get rid of tags (there is a little exception, but I wont compound this with that), but then again, you mentioned some of your tools may have been older versions. There have been updates to ID3 specs, so some of the newer tags may not be in older tools in which case it's a guess how they would have handled that situation. Certainly not a Tesla issue, and honestly I doubt is an issue because with the exception of Album Art that is a little bit newer, Tesla only uses tags that have been there since day 1.

Possible issue with filetype is same as audio encoding format. IF, and I think that is a big doubtful IF, Tesla is doing some different logic in scanning files (not playing back) based on their encoding type, that could be a difference and account in some way for some of the variability. As a I tried to explain, I see no reason why Tesla would be doing that, hence why I've spent no time trying to test details. With Tesla rather blindly pulling in all .m4a file types now, it sort of confirms my thought. You've seen my reference to that a few times now that Tesla plays M4A Lossy, but puts M4A Lossless in the interface but then can't play it... because they are just saying, oh, it's .m4a so we should process it via the scan and pull in all the tag data, but they never look at the real data of the audio track until they go to play it.

USB Read times. During all this, I invested in a little tool to help me test a drive read and write speed. Yes, in theory your and my PNY drives should have the same speeds, but not necessarially true -- it's why one of mine is in the mail for an exchange... it's speed dropped off on day 3 of use. Too much to discuss here on all that, but it seemed fine when writing ~1-6 tracks at a time to the stick, but then would pause for 20 seconds or more before writing the next few files... what took 2 hours upon receipt was not even 15% complete in the same time when I went to do it again. It was similar issue with reading... the failing stick would take perhaps 30 secs to just be recognized by my Mac, where it was less than 5 when it was new. So, move that sort of problem to the MS... how would that appear? Likely not even visible when playing tracks on the stick, but the initial scan where it's going through lots of files would probably take a lot longer with a stick that was failing in this way Ive had happen with PNY, SanDisk, and IIRC Kingston. That sort of failure would also be the reason why CID reboots seem to take a lot longer with certain USB devices plugged in vs others.

More files and more tags will increase scan time. But what my testing showed is the way Tesla has coded their scan process, as it looks at that tag data to do what it needs to do, some combinations of what that content actually is (names of artists, albums, etc and how much of that is the same or different across your library) can dramatically change the time it takes to process the scan. To me, that's a bug because the scan routine is poorly designed, but technically I suppose since it eventually gets the job done, it becomes a requirement to improve the speed it does its task. Does that make it more clear? It's not the tags, it's what is inside them that my test #4 showed very clearly can be a significant difference. We may have the same physical kind of USB Stick, and roughly the same number of tracks, but the data inside each of our tags has to be vastly different, and THAT is what I've proven can influence scan speed rather dramatically as libraries get larger.

 

[BertL]

FWIW when adding my album art directly to the tracks from my folder.jpg files, I ran into about 50 tracks there were basically corrupt with regard to tags. I could not change the tags or the artwork using dbpoweramp of the companion PerfectTunes app. The way I had to fix it was to do a batch update with dbPoweramp on the selected albums/files and then I was able to go and cleanup and add the artwork.

Not sure if this had any affect on my cars ability to scan but after doing so my 3500 tracks do load in less than 2 minutes on 2.40.21

Great observation. I have always believed the same thing, just unsure of any method to isolate tracks that offend Media Player, esp when they all work fine on my other media players.

 

[msnow]

Thx.

Tools are interesting, but from my knowledge, what goes into the tags is rather free format for most of them (not all)... I spent lots of time a long time ago going through everything in my library were all "firstname lastname" and not some other permutation, same with groups, common misspellings, etc -- but again, unless Tesla has done something really unexpected coding-wise, I don't see data inside tags as an issue. We know e.g they are not parsing TRACKARTIST into seperate artists as they probably should, so I doubt they are doing it elsewhere.

As far as extra tags, again, I doubt that is an issue. I think I've proven that the physical size of a track does not create a problem, so having tags that the interface never uses are simply bypassed. Tesla like any app would be looking for specific tags and ignoring the rest. I too have some tracks with I'd guess 20 tags... so that's not a difference between us.

If conversion tools are well behaved, they shouldn't get rid of tags (there is a little exception, but I wont compound this with that), but then again, you mentioned some of your tools may have been older versions. There have been updates to ID3 specs, so some of the newer tags may not be in older tools in which case it's a guess how they would have handled that situation. Certainly not a Tesla issue, and honestly I doubt is an issue because with the exception of Album Art that is a little bit newer, Tesla only uses tags that have been there since day 1.

Possible issue with filetype is same as audio encoding format. IF, and I think that is a big doubtful IF, Tesla is doing some different logic in scanning files (not playing back) based on their encoding type, that could be a difference and account in some way for some of the variability. As a I tried to explain, I see no reason why Tesla would be doing that, hence why I've spent no time trying to test details. With Tesla rather blindly pulling in all .m4a file types now, it sort of confirms my thought. You've seen my reference to that a few times now that Tesla plays M4A Lossy, but puts M4A Lossless in the interface but then can't play it... because they are just saying, oh, it's .m4a so we should process it via the scan and pull in all the tag data, but they never look at the real data of the audio track until they go to play it.

USB Read times. During all this, I invested in a little tool to help me test a drive read and write speed. Yes, in theory your and my PNY drives should have the same speeds, but not necessarially true -- it's why one of mine is in the mail for an exchange... it's speed dropped off on day 3 of use. Too much to discuss here on all that, but it seemed fine when writing ~1-6 tracks at a time to the stick, but then would pause for 20 seconds or more before writing the next few files... what took 2 hours upon receipt was not even 15% complete in the same time when I went to do it again. It was similar issue with reading... the failing stick would take perhaps 30 secs to just be recognized by my Mac, where it was less than 5 when it was new. So, move that sort of problem to the MS... how would that appear? Likely not even visible when playing tracks on the stick, but the initial scan where it's going through lots of files would probably take a lot longer with a stick that was failing in this way Ive had happen with PNY, SanDisk, and IIRC Kingston. That sort of failure would also be the reason why CID reboots seem to take a lot longer with certain USB devices plugged in vs others.

More files and more tags will increase scan time. But what my testing showed is the way Tesla has coded their scan process, as it looks at that tag data to do what it needs to do, some combinations of what that content actually is (names of artists, albums, etc and how much of that is the same or different across your library) can dramatically change the time it takes to process the scan. To me, that's a bug because the scan routine is poorly designed, but technically I suppose since it eventually gets the job done, it becomes a requirement to improve the speed it does its task. Does that make it more clear? It's not the tags, it's what is inside them that my test #4 showed very clearly can be a significant difference. We may have the same physical kind of USB Stick, and roughly the same number of tracks, but the data inside each of our tags has to be vastly different, and THAT is what I've proven can influence scan speed rather dramatically as libraries get larger.

Got it. TU for explaining it.

 

[aesculus]

Can someone who has 42 or 121 with the new USB features explain to me how to use search to find USB albums or artists?

It seems to find tracks (at least sometimes), but I never see any USB artists or albums. I would really like it to only search the USB if I added that as a keyword.

The release notes says it does but my short experience (one day), says it doesn't.

 

[msnow]

On my .42 when I search for let's say "The Beatles", the UI will show results from all media sources under headings of where they were found so I can select one.