It is trying to tell you that the way to listen to music is flat
Ohhh, one of those nut jobs. You flat equalizer people are all the same. You try tuning an aftermarket sub with only 3 equalizer bands....
-
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
Ohhh, one of those nut jobs. You flat equalizer people are all the same. You try tuning an aftermarket sub with only 3 equalizer bands....
ArtInCT
Always Learning
This AM my music just did not sound right to me. Checked the graphic equalizer and my mid range was a zero. I reset it to my normal which is +6. The bass and treble were fine and normal. Then I got to thinking... what would change this? What event would reset these settings?
I then recollected that I had not done a central screen reboot in a few weeks..... did the reboot allowing the T logo to appear and waited 15 more seconds to let go of the scroll wheels. After the reboot, I went into the graphic equalizer again. Viola! This time the bass was at 0 and the mid and treble were as I normally set them.
So not very scientific, but perhaps the central screen reboot may not be relied upon to save the equalizer settings and could be the change agent for them? More testing would need to be done IMHO.
As a funny aside.... Am I totally WRONG in thinking that the new product announcement would be "The Return of the 7.1 Entertainment App!??" fingers are crossed. Sadly... kidding.
I then recollected that I had not done a central screen reboot in a few weeks..... did the reboot allowing the T logo to appear and waited 15 more seconds to let go of the scroll wheels. After the reboot, I went into the graphic equalizer again. Viola! This time the bass was at 0 and the mid and treble were as I normally set them.
So not very scientific, but perhaps the central screen reboot may not be relied upon to save the equalizer settings and could be the change agent for them? More testing would need to be done IMHO.
As a funny aside.... Am I totally WRONG in thinking that the new product announcement would be "The Return of the 7.1 Entertainment App!??" fingers are crossed. Sadly... kidding.
Kidding aside, best way to do that is with separate amp and volume control for the sub. I was contemplating wiring my stock sub like that, but I always chicken out on mods that involve prying panels (to hide wiring in this case) for fear of causing rattles.
BertL
Active Member
I reported this EFI thing weeks ago in the main Firmware 8.0 thread. Reboot your CID and it will go away, or at least mine did and has not reappeared. (Foot on brake; Hold both control wheels until Tesla T appears on the CID; Let up on the brake).
BertL
Active Member
Well then, all I can suggest is you should report it to Tesla next time you're in for service. Good luck.
I'm sure tesla tunes does standardize. However I have the feeling that the WAY it creates directory structure makes 8.0 load times impossible for large collections. That's why I'd like to see structure.
Personally, I went from 2 level structure (albums within artists) to 3 level (albums within artists within alpha index) to help with navigation, and my load time went from 2 minutes to 6+. Same number of songs... so clearly 8.0 load time is sensitive to depth of directory structure, among other things...
BertL
Active Member
FWIW, I have used a single directory, TeslaTunes built USB stick since 6.2 days. All my tracks are under the single subdirectory off the root. In other words, something like this:
Volume
/Playlist
Track1
Track2
Track3
etc. to Track6100
...and my 6100 track scan time completed in 15-20 mins with 7.2, to 80% complete and then at a snails pace at the 2-hour mark with 8.0. That is an extremely flat structure. I think the problem likely has more to do with file formats and/or tagging (including Album Art) with the new Media Player that were not there with 7.2. Having the same stick effectively fail with 8.0 points in that direction. Perhaps the new Media Player ends up having memory leakage issues during scan when there are many tracks in a single directory, and that's why it seems to slow down more and more after some point... very difficult to troubleshoot that without a whole lot of time and many test cases, and even then as a user, I doubt we'd know for certain what the issue was under the covers. My personal workaround I want to try is to put my same 6100 tracks into 6 different subdirectories off the root... but I have to get my MS back first.
I have reported this to my SvC, and provided the problematic 6100 stick, as well as another with a 1100 subset also in a single directory, that scans in just over 2 minutes with 8.0. It looks like my MS was finally moved inside an hour or two ago to be worked on, so perhaps I'll have input from them in a day or two. Not holding a lot of hope related to this issue, but at least it will have been reported via a method other than email I suspect most have been using.
...I should add, I have back in the earlier 7.0-7.1 days had as many as 16K tracks scan just fine with a single TeslaTunes built directory. I reduced the number of tracks to around the 6K level after much trial-and-error, deciding it was the best sweet spot for me having sufficient variety, but something that could still scan in less than 20 minutes when unexpected rescans would occur, and that after about 6K tracks, my CID hangs/slowdowns increased beyond what was a reasonable threshold for me.
Volume
/Playlist
Track1
Track2
Track3
etc. to Track6100
...and my 6100 track scan time completed in 15-20 mins with 7.2, to 80% complete and then at a snails pace at the 2-hour mark with 8.0. That is an extremely flat structure. I think the problem likely has more to do with file formats and/or tagging (including Album Art) with the new Media Player that were not there with 7.2. Having the same stick effectively fail with 8.0 points in that direction. Perhaps the new Media Player ends up having memory leakage issues during scan when there are many tracks in a single directory, and that's why it seems to slow down more and more after some point... very difficult to troubleshoot that without a whole lot of time and many test cases, and even then as a user, I doubt we'd know for certain what the issue was under the covers. My personal workaround I want to try is to put my same 6100 tracks into 6 different subdirectories off the root... but I have to get my MS back first.
I have reported this to my SvC, and provided the problematic 6100 stick, as well as another with a 1100 subset also in a single directory, that scans in just over 2 minutes with 8.0. It looks like my MS was finally moved inside an hour or two ago to be worked on, so perhaps I'll have input from them in a day or two. Not holding a lot of hope related to this issue, but at least it will have been reported via a method other than email I suspect most have been using.
...I should add, I have back in the earlier 7.0-7.1 days had as many as 16K tracks scan just fine with a single TeslaTunes built directory. I reduced the number of tracks to around the 6K level after much trial-and-error, deciding it was the best sweet spot for me having sufficient variety, but something that could still scan in less than 20 minutes when unexpected rescans would occur, and that after about 6K tracks, my CID hangs/slowdowns increased beyond what was a reasonable threshold for me.
Last edited:
Ok. Just trying to test a theory based on fact my scan time went up 300% when only change was directory structure.FWIW, I have used a single directory, TeslaTunes built USB stick since 6.2 days. All my tracks are under the single subdirectory off the root. In other words, something like this:
Volume
/Playlist
Track1
Track2
Track3
etc. to Track6100
...and my 6100 track scan time completed in 15-20 mins with 7.2, to 80% complete and then at a snails pace at the 2-hour mark with 8.0. That is an extremely flat structure. I think the problem likely has more to do with file formats and/or tagging (including Album Art) with the new Media Player that were not there with 7.2. Having the same stick effectively fail with 8.0 points in that direction. Perhaps the new Media Player ends up having memory leakage issues during scan when there are many tracks in a single directory, and that's why it seems to slow down more and more after some point... very difficult to troubleshoot that without a whole lot of time and many test cases, and even then as a user, I doubt we'd know for certain what the issue was under the covers. My personal workaround I want to try is to put my same 6100 tracks into 6 different subdirectories off the root... but I have to get my MS back first.
I have reported this to my SvC, and provided the problematic 6100 stick, as well as another with a 1100 subset also in a single directory, that scans in just over 2 minutes with 8.0. It looks like my MS was finally moved inside an hour or two ago to be worked on, so perhaps I'll have input from them in a day or two. Not holding a lot of hope related to this issue, but at least it will have been reported via a method other than email I suspect most have been using.
...I should add, I have back in the earlier 7.0-7.1 days had as many as 16K tracks scan just fine with a single TeslaTunes built directory. I reduced the number of tracks to around the 6K level after much trial-and-error, deciding it was the best sweet spot for me having sufficient variety, but something that could still scan in less than 20 minutes when unexpected rescans would occur, and that after about 6K tracks, my CID hangs/slowdowns increased beyond what was a reasonable threshold for me.
I suspect you are right, it is probably some threshold number of tracks that overwhelms memory allocation. May be impossible for us owners to ascertain.
<whine> Mine now takes 20 to 30 minutes. On 7.1 it only took 5 minutes, and only once per reboot. 20,650 tracks, 4 levels of directory structure. </whine>
Did you format the drive with GUID Partition Table (GPT)? Try Master Boot Record (MBR) instead.
I have 706 albums, and my directory structure is simply one folder for each album, and all folders right under root. Although my scan time has also increased manifold since I got 8, it is still within 10 mins or so. Don't get me wrong, I still have all those other issues that make the media player unusable for me, but scan and load time is not one of them. May be more depth in your directory structures is causing the infinite scan time for you guys?
Also, for those complaining about how they could make a decision to take a feature away, I do not believe that is what really happened. I think they just sat down and built a new media player from scratch, just like they did the first time around. And just like the first time around, a bunch of basic required features got implemented and a bunch got skipped.
Also, for those complaining about how they could make a decision to take a feature away, I do not believe that is what really happened. I think they just sat down and built a new media player from scratch, just like they did the first time around. And just like the first time around, a bunch of basic required features got implemented and a bunch got skipped.
jgs
Active Member
Beat me to it. For those wondering, EFI is EFI system partition - Wikipedia and well-behaving OSes (ahem) just hide that partition. You can safely ignore it, or as @cynix says, try MBR if it's driving you crazy.
Similar threads
