Garmin fenix 5x auto-update stuck at 50%.

I just recently purchased a ‘Garmin fenix 5x’ smart-watch, with emphasis on sports features. And, to make the watch work as smoothly as possible, it was necessary to allow it to install its latest firmware version, which happens to be 20.0 at the time of this posting. But there was a problem. I was intending to use this watch mainly with the ‘Garmin Connect app’, available on Google Play, which communicates with the watch only via Bluetooth. (:1) Installing a firmware upgrade to an unknown, generic device, via Bluetooth, depends on how large a file-size the F/W upgrade is supposed to have. Bluetooth tends to be a slow interface, in the day and age where WiFi as fast as 802.11n is possible. And in this case, the update was apparently stuck at 50%, perhaps not even due to how slow the file transfer would have been, but rather, due to Garmin preferring we install the update via the ‘Garmin Express application’, of which there is a Windows as well as a macOS version.

Problem? I neither have a Windows, nor a macOS device. I depend on installing that update otherwise. But, as indicated below, I found a solution that seems to work for me…

The ‘fenix 5x’ allows the watch itself to be connected to a WiFi network. The possibility should exist, to restart the update process, but, using the watch’s WiFi link, not the Bluetooth upgrade that somehow got broken. In order to accomplish that, the first thing I needed to do was, to add my home WiFi network to the watch’s WiFi networks. Fortunately for me, because the actual Bluetooth pairing between the watch and Android app works 100%, I was able to set up WiFi for the watch, using the Android app.

My phone is a Samsung Galaxy S9, with its latest firmware, and my Garmin Connect app is up-to-date.

The next thing needed to be done manually, because the watch did not just abandon its discontinued Bluetooth upgrade in favour of a new, WiFi-based upgrade.

  • On the watch, Press the ‘Menu’ and the ‘Up’ button simultaneously,
  • Next, Scroll Down to the ‘Settings Entry’,
  • Press the ‘Activate’ button once,
  • Scroll Down to the ‘System Entry’,
  • Press the ‘Activate’ button once, again,
  • Scroll down to the (last) ‘Software Update Entry’,
  • Press the ‘Activate’ button once, again,
  • There should be an ‘Auto-Update Entry’ set to ‘On’, as well as an ‘Update Available Entry…’ Scroll to this last Entry, if there is one after the ‘Auto-Update Entry’.
  • Press the ‘Activate’ button again, once,
  • Press ‘Continue’ if so instructed,
  • Repeat until doing this no longer reveals an ‘Update Available Entry’. At that point, the last menu should only have the ‘Auto-Update (== On) Entry’.

Because the watch was set up to connect to my WiFi without problems, it was able to install a major and a minor update quickly and without issues. After its major update, it restarted.


(Update 10/12/2020, 16h05: )

Continue reading Garmin fenix 5x auto-update stuck at 50%.

The latest Roku firmware update seems to have fixed a glitch.

In this earlier posting, I had written that my Roku Ultra had a glitch.

More specifically, this glitch involved the ‘Anynet+’ feature, by which the Roku can wake up the TV it’s connected to, when we only turn on the Roku. This should happen due to the HDMI cable that connects them, because of this named protocol.

Previously, this feature was only working intermittently.

The Roku received a Firmware Update dated May 5, which seems to have fixed that problem. Now it seems to happen reliably, that when I just turn on my Roku, my TV also turns on, and switches to the input automatically, that the Roku is connected to.



A Glitch in the Roku

The Roku, like many home appliances today, periodically downloads firmware updates, designed to fix glitches. Yet, it might be helpful for its developers to know what all of them are – and what they have yet to fix.

(Edit 05/11/2017 : The status of this glitch or bug has been superseded, by a firmware update which took place since the time of this posting, and which I’ve written about in this later posting. The bug seems to have been fixed. )

One feature the Roku has, which I have described before, is its ability to use the HDMI interface, to tell the TV, to make it the selected input, as soon as we operate any Roku controls. My TV has 3 HDMI inputs, and all 3 are currently connected to some sort of appliance.

Roku calls this feature “One-Touch Play”.

Samsung calls it “HDMI Anynet+ CEC”.

The problem becomes noticeable, if we leave the TV input switched to the Roku, turn off the TV, and then simply allow the Roku to go into standby, at some later point in time.

What happens is that as it goes into standby, the Roku ‘remembers’ that it was the selected input of the TV. This may in fact not be the case anymore, when we next want to use the Roku, because by then, we may have switched the TV input to something else. But, when the Roku resumes, it still ‘thinks’ it is the selected input, and fails to send the signal to the TV again, to make itself the selected input.

This problem can lead to confusion until the cause is identified, and carries on in a very persistent way. When we have multiple remotes, being able to understand what each of them does may no longer be satisfying. We may actually want to keep their operation as direct as possible as well.

IMHO, The correct behavior would be, that the Roku forget it was the selected input, and that it resend the signal to the TV anyway, to select itself, as soon as a control is pressed.

I have been able to create another similar situation, in which the Roku was simply on its home-page, after viewing video for an hour or more, and in which to switch the TV to a different input – using the TV remote – did not send the message to the Roku, that the Roku was being disconnected.

Actually, I can tell whether this feature is working correctly or not, while I switch the TV to another input, before shutting everything down. When things are working, my TV displays a message saying “Disconnecting Anynet+ Device”. This tells me that the TV is sending the signal to the Roku as well, telling the latter, it is no longer the selected input.

This only happens with the Roku, not with the Sony Blu-Ray player, which suggests that it may still be a glitch with the Roku.


This bug exists with

Software version: 7.5.1

Build: 4095

(Edit 02/15/2017 : )

The other situation in which this glitch occurs is as follows.

The Roku could be on its Home Page, and I could use my TV remote, to switch the TV to a different input. At that time, the TV Menu does display the word “Roku” next to the currently-chosen input. Then, I can switch the TV off.

If the Roku has not gone into standby yet – i.e., its white LED is still lit – and I use the Roku remote both to Turn On the TV, and to allow the Roku to Recapture the TV input, this next works. But after that, the next time I use the TV remote to switch its input to another input, first of all,

  • The TV Menu no longer displays the word “Roku” next to the currently-chosen input, and
  • After that, using the Roku remote no longer recaptures the TV input.



My router may have been flashed.

One of the ironies of my LAN is, I am hosting a Web-site from it, but I do not even own my present router. Mine is a router owned by my ISP, and which provides me with proprietary TV as well.

This means that my ISP has the right to perform a firmware update on the router, which can also be called ‘flashing the router’.

I suspect that this may have happened, around Wednesday Morning, November 9.

My main reason for suspecting this, was a subtle change in the way my router manages my LAN.

According to This Earlier Posting, I previously needed to set my router as the WINS server as well.

To explain in lay-terms what this means, I need to mention that the local IP addresses which computers have on a LAN do exist, in addition to which Windows has introduced its own way of giving the local computers names. Linux can mimic how this works, using its ‘Samba’ software suite, but also tries to avoid ‘NetBIOS’ (naming) as much as possible, outside of Samba network browsing, or ‘copying-and-pasting of files, between computers on a LAN’.

Just like domain-names need to be resolved into IP addresses on the Internet, which is the WAN to this LAN – the Wide-Area Network – on the Local Area Network, computer-names also need to be resolved into IP addresses, before the computers can actually ‘talk to each other graphically’. Traditionally, Windows offered its whimsical mechanism for doing so, which was named NetBIOS, by which any and every computer could act as the WINS server – thus offering its repository of LAN locations to the WINS clients, but alternatively, there could also exist one dedicated WINS server.

What I had grown used to, was that on my LAN, the router would insist that it be my WINS server, thus ‘not trusting’ any of my Linux boxes to do so in some way. I therefore had to defer to this service, as provided by the router.

I had previously set my ‘/etc/samba/smb.conf‘ to

   wins support = no

   dns proxy = yes

Well as of Wednesday, the LAN had suddenly ‘looked different’ according to client-browsers. Each computer had suddenly remained aware only of its own identity, with no Workgroup of other computers to network with.

This was all happening, while my connection to the WAN still seemed secure and operative.

Long story short, I think that my ISP may have performed the Firmware Update, and that according to the new firmware version, the router was suddenly not willing to provide this service anymore. And so what I felt I had to do next, was change these settings back to


   wins support = no

   dns proxy = no


Now that I have done so, each computer can ‘see’ my whole Workgroup again – which was apparently not feasible according to earlier experiences.

Further, for laypeople I might want to emphasize, that it is not just a frivolous exercise of mine, to give each computer a name. If they did not have names, then according to the screen-shot below, I would also not be able to tell them apart, since they all have the same icon anyway:



Now I suppose that an inquiring mind might ask, “Since Linux can imitate Windows, why does Dirk not just set ‘wins support = yes‘ as well?” My answer to this hypothetical question would be, that

  • According to common sense, this option will just make the current machine available, as a potential WINS Server, but
  • In my practical experience, the LAN will interpret this as more of an imperative gesture, of a kind that will actually cause a feud to break out between the machines.

In my experience, if I even set one of my Linux machines to do this, all the other Linux machines will refer to its repository of (4) LAN names, the others becoming clients, but the Windows 7 machine named ‘Mithral’ will refuse to have it. In this case, Mithral will insist that it must be the WINS Server, and not some Linux box. And then, further logic-testing of which machines can see which, will reveal that in practice, I must leave this option switched off, if there is also to be any Windows machine to share the LAN with.