-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Dan43
Member
Same here, and also my HW1 is so much more responsive, quicker, clearer animations, lines for AP picked up quicker and so forth. It is like it has all speeded up, thats how it is on first drive yesterday
The sensors appear a lot busier too, constantly looking for info rapidly, I have noticed quite a change here.
Cyclone
Cyclonic Member ((.oO))
I had an opportunity to check this out today (in the parking deck). Yup, works perfectly on 7.1.
MarcG
Active Member
Thanks! If you select "Call Options", can you please remind us what options show up exactly?
Cyclone
Cyclonic Member ((.oO))
HankLloydRight
No Roads
Ok, I cracked a little bit more of the build number components.
Up until now, it does appear that the second number was "week number" of the build release. But if you think about it, that would definitely cause collisions across years! (i.e. a new build released the same week as a prior year) . So I went back to look at what happened between 2015 and 2016, and why there aren't any collisions.
Turns out they moved to the "week#" starting in 2016. So, duh, that's going to break in 2017.. which is why they moved from "2.x.y" for all previous builds to a "Year.Week.Sequence" scheme.
I went back to look at the build numbers for all of 2015, and there are only these across the entire year:
And the first build # in 2016 started at 2.9.y, so there would be no collisions going forward (well, until 2017, that is!).
But along with the 'brain drain' that caused regression testing to go out the window, I guess so did conventional build numbering schemes.
And this is exactly why I posted above that trying to use "smart numbers" in build number assignment is a very bad idea.
Up until now, it does appear that the second number was "week number" of the build release. But if you think about it, that would definitely cause collisions across years! (i.e. a new build released the same week as a prior year) . So I went back to look at what happened between 2015 and 2016, and why there aren't any collisions.
Turns out they moved to the "week#" starting in 2016. So, duh, that's going to break in 2017.. which is why they moved from "2.x.y" for all previous builds to a "Year.Week.Sequence" scheme.
I went back to look at the build numbers for all of 2015, and there are only these across the entire year:
- 2.2.y
- 2.4.y
- 2.5.y
- 2.7.y
- 2.8.y
- 2.9.y
And the first build # in 2016 started at 2.9.y, so there would be no collisions going forward (well, until 2017, that is!).
But along with the 'brain drain' that caused regression testing to go out the window, I guess so did conventional build numbering schemes.
And this is exactly why I posted above that trying to use "smart numbers" in build number assignment is a very bad idea.
Gah. That explains a lot of head-scratching during 2016, and it's totally obvious in retrospect. Nice detective work.
Both "Major.Minor.Patch" and "Year.Week.Patch" are pretty common. Both of them are sensible if applied consistently (I admit to being a fan of the former, coupled with semantic versioning, or some convention that reflects codeline structures). I've seen projects move from one to the other. This is the first time I've seen a software project move from one numbering scheme to another in two steps. I can't think of a good technical reason for that. I would love to hear the story behind this (like so many other things about Tesla software I don't understand).
Bruce.
lakerholic
Member
This update broke my Tunein...anyone else? Two reboots and it just keeps saying "loading error" on any selection I make.
More specific please. Which update is "this update". TuneIn working fine for me on 2.52.22.
I have been noticing more loading errors with Tunein on 17.4.14. Specifically once it has a loading error it stays in this state for a bit. Happened to me once yesterday and once today. Trying to manually advance to the next song (which was my usual fix on prior releases) nor selecting a different stream does not help. For me streaming recovers on its own after a few minutes. Yesterday I tried a reboot with no immediate effect. Today I did nothing.
In both cases it seemed like the 3G signal strength was registering as zero, although both times I was in places where I typically have good signal. Moreover, today I was sitting in traffic when the problem occurred and I had probably moved no more than 50 feet before streaming started working again. Since you have newer 4G hardware, I am guessing the problem is slightly higher in the communications stack and not actually with the phone network connection.
TuneIn has had loading errors for a few versions now in my car. Really do not think it is 100% new in the last 2 versions...
Agreed there has been more of a problem in recent builds, but advancing to the next song or selecting another stream usually resolved the problem for me. With 17.4.14 it becomes a solid failure that lasts for several minutes before apparently resolving on its own. (In the couple of cases so far, I haven't been patient enough to see if it really clears up with absolutely no action on my part.)
ArtInCT
Always Learning
Upon returning home from a long 3,500 road trip, I noticed near constant streaming load errors when my S was in my garage and on
my WiFi. Songs would begin to load, show the album cover, play one note and then go on to the next song. Ratta tat tat...
What I did to correct this was as follows...
Reboot using both scroll wheels and brake pedal.
Go into WiFi and FORGET all WiFi networks that I had attached to on my long road trip.
There were about 12 of them.
Unplug and reboot my WiFi routers (3 eeros) which causes them establish my mesh network anew.
Reboot again using both scroll wheels and brake pedal.
Drive car out of garage and WiFi range and then return to my garage.
Problem solved...
BTW, this was on firmware 2.52.22 which was installed on 1/12/17.
my WiFi. Songs would begin to load, show the album cover, play one note and then go on to the next song. Ratta tat tat...
What I did to correct this was as follows...
Reboot using both scroll wheels and brake pedal.
Go into WiFi and FORGET all WiFi networks that I had attached to on my long road trip.
There were about 12 of them.
Unplug and reboot my WiFi routers (3 eeros) which causes them establish my mesh network anew.
Reboot again using both scroll wheels and brake pedal.
Drive car out of garage and WiFi range and then return to my garage.
Problem solved...
BTW, this was on firmware 2.52.22 which was installed on 1/12/17.
BertL
Active Member
The best thread to check is the "counterfate" thread you cross posted this post from. @Tech_Guy had a recent update but it didn't fix the problem. Like I said in the other thread, the update you're looking for is likely 8.1 and there will be plenty of publicity on that when it rolls out.
Dan43
Member
With Elektrec reporting another delay, but nothing more in journalism than pub speculation and online rumour not much in any actual facts except 8.1 is delayed, again.
Their site really does depend on Reddit and TMC for its 'journalism'
Their must be a new world for it, rumourism or something
Their site really does depend on Reddit and TMC for its 'journalism'
Their must be a new world for it, rumourism or something
Just completed another drive from Napa to Tucson, the first since firmware 2.52.22. I noticed a big difference, and improvement, in the Trip computation. In the past, after I stopped and supercharged, the new destination would show, say, 20%. I'd then start driving and that number would invariably drop by 5 - 10% immediately. Then as the trip progressed beyond halfway, that number would normalize back to 20%. On this trip that initial drop has been eliminated, and in fact usually is increased by 3-5% during the first 10 minutes of that leg, then lock at that level. Much less stress.
I subtly noticed the same thing on my last Vegas trip with 2.50 and 2.52....
Before, from the time I unplugged to the time I made it back on the highway, the momentarily high Wh/mi usage would cause my estimate to plummet 5-10%, which of course is scary and leaves you wondering if you should turn back or not. Now, that effect seems gone.
With that said, estimates are still estimates. Going through the mountains to Barstow, my estimate actually was off by 20 rated percent (e.g. it told me I needed 70%, I charged to 90% and still just arrived with 15%), due to a combination of high winds, heavy rain, and periods of following traffic at 75mph during the good weather.