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.

Dirk

 

A Glitch in the Roku

The , 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 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 controls. My TV has 3 HDMI inputs, and all 3 are currently connected to some sort of appliance.

calls this feature “One-Touch Play”.

Samsung calls it ““.

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

What happens is that as it goes into standby, the ‘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 , because by then, we may have switched the TV input to something else. But, when the 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 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 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 , that the 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 ““. This tells me that the TV is sending the signal to the as well, telling the latter, it is no longer the selected input.

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

Dirk

This bug exists with

(Edit 02/15/2017 : )

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

The 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 “” next to the currently-chosen input. Then, I can switch the TV off.

If the has not gone into standby yet – i.e., its white LED is still lit – and I use the remote both to Turn On the TV, and to allow the 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 “” next to the currently-chosen input, and
  • After that, using the remote no longer recaptures the TV input.

Dirk

 

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:

phoenix_nmbd_1

 

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.

Dirk

 

Firmware Update Today

One subject which I have written about at length, is the apparent instability of the Realtek WiFi chipset, on my laptop named ‘Klystron’. If anything is likely to improve that, it would be a firmware update.

Well just today, a firmware update was installed, to ‘linux-firmware’ version 1.158, and this was also followed by a reboot.

After the reboot, I tried to test whether my 802.11n WiFi performance had improved. One main test which I did, was to transfer a 500MB file to the local laptop, from a Samba server on another computer on my LAN. And what I found, was some improvement in peak speed, to 2.0 Megabytes per second, corresponding to 16 mbps.

Before I could obtain that speed however, I first needed to restart the Samba server, which had been running on the originating computer since April 17. And this detail helps show, how speed limitations in transferring, may be due to numerous problems, other than the actual link quality of the WiFi client.

Dirk