Remotes

[waldridg95]

Ben, thanks for this corrective action.  I followed what you said and it corrected the problem.  However, I'm not convinced that the problem has been resolved permanently.  I suspect there is a software issue that was introduced in one of your updates.  I say this because I have three Roku systems (Express, Express+, and Express 4K) and I was experiencing the exact same problem on all three.  I find it strange that all three remotes would exhibit the same problem when two of them are not even used. Those two are in bedrooms that belonged to my adult children who no longer live at home.  Plus, the Express 4K is about 18 months old but it has only been used three times.  Clearly, it has nothing to do with remote usage.  Anyway, they are working now.  We'll see if it lasts.

[RokuBen]

@waldridg95The timing I spoke of is not the age of the device, but how long it has been since the device last restarted.  Roku typically does big software updates that cause the device to restart about twice a year.  The last one, updating devices to Roku OS 12.0, went out to all users in May 2023, although the update was spread over several weeks, and some devices got updated multiple times as we fixed issues seen with the earlier waves of updates.

About 50 days after that update went out, some people started seeing this problem.  That was because their device had been turned on without a restart since the update.  Some people have their set-top boxes plugged into wall power so they can be on for days without use, while other people have them plugged into USB ports on the TV, so they might restart every time they turn on their TV.

Inside the OS of the device, there's a counter that counts how long it's been since the last reboot.  This is called the uptime clock.  This is used to label lots of different activities like key presses so they can be compared against each other.  In this case, that time was used to determine when there was a key repeat due to holding down the button.  There was a problem in the implementation of one of these comparisons that led the device to think the button had been held down for 49 days instead of a few milliseconds, which led it to generate extra key repeats.  This problem only showed up when doing the calculations for channels that used the "run as a process" feature in Roku OS 12.0, so that's why it didn't affect the home screen or some other channels.

Rebooting the device resets that clock to 0.  The actual fix for the bad code is coming in a future OS release, so the reboot is just a workaround until we deploy the version of Roku OS with the fix.

[joekam]

Sounds good. Sounds like you have it figured out. I think I was close in a general way on where to look. I had no idea how the system actually works only a few ideas on how it may likely work. This information is good but does not help explain how the Phone Remote channel Apps did not cause the problem to happen. Must be the Remote channel apps do not send the same Key press info to the Roku.  Apparently, Uptime is not looked at unless the key press info comes from a ROKU remote.    Uptime sounds more like an aid to habit tracking, between boots.  Which of it is , it would not make any difference how long or short uptime is to do it. This problem might never have occurred if Roku had simply linked the reboot command with every power off/on command from remote. The Power off command seems to only turn the TV off.  Tracking how long a Roku has been on (i.e uptime) since a Reboot. has become a can of worms by letting it become so long between roku updates and/or user required to to do. I would just link all reboots to power on/off since im sure people are turning off/on their TVs much more regularly. Thank you very much for the status in information. 

[RokuBen]

I simplified the bug reproduction mechanism a little, @joekam .  The phone app has a much smaller time period between key press and release versus a physical remote, and that difference was enough to avoid the effect being seen in the app.

[VA1DER]

@RokuBen A non-exhaustive review of this thread has shown at least fifteen reports of people who have experienced the issue, rebooted, and within minutes or hours experienced the same issue.  While I cannot for myself say whether or not there is an issue with counters at the 50+ day range, there appears to be a substantive number of people for whom this is, at the very least, only partially the problem.

[aaronhb]

There seems to be a difference between rebooting and pulling the power cord. I pulled the cord on my Roku Ultra in early July and the problem has not recurred, though I'll admit I'm not a heavy user and only stream a few different channels.

This may be irrelevant, but I noticed that the unit was very warm, even hot, and I've since raised it up so there's more air circulation. Electronics get hot. Electronics don't like being hot. I figure it can't hurt.

[RoyElam]

Yep, For the channel skip issue you pull the power plug to do a hard reset. 
For a similar issue that for me caused runaway volume control a full re-pairing of the remote fixed it.

I put 3 nylon stick on furniture gliders (Walmart) on the bottom of mine to raise it about 1/4”, they are 1/2” in diameter.

[joekam]

The reboot command does not appear to always work like unplugging power does. This would indicate that the Boot loader does not have a full memory and or system reset capability. In some embedded hardware systems, the boot loader can reset all memory and registers as if power was removed and all those devices lost ability to keep the memory and registers in the state they were in. However, Some boot loaders to not have a software controlled hardware  reset line that goes to every device that stores something. This is common in embedded systems that use PALs  Gate arrays and other custom programable devices that can be designed with storage ability. The designer often makes a mistake. or is unable do to pin or logic constraints to put in a full Hardware reset line that resets everything in that device. In these cases only a true power reset will work. To solve that problem often requires a hardware fix to put in a power toggle device so SW can actually toggle  power  of those custom devices or the entire system. Like a computer pulling its own plug and plugging itself back in. This requires something like a normally closed SSrelay in series with power that gets toggled open to the off state, by a CPU IO  reset command. Then the relay switches to off state, where no power to it and the system causes it to go back to normally closed state and that turn power back on. the amount of time it stays toggled off can be controlled by a simple hold up caps on the SS relay power and the control line, to keep the power off for a couple seconds. Long enough to clear Dynamic ram if there is any. If there is no dynamic ram in the system, then there is no need to hold power off for seconds at all. I doubt Roku will make a HW mod. 

[VA1DER]

---

@joekam wrote:

The reboot command does not appear to always work like unplugging power does. This would indicate that the Boot loader does not have a full memory and or system reset capability.

---

Whether or not memory is globally reset during a soft reboot is probably moot - it's extraordinarily unlikely that any memory location used for variable storage (especially global) would be used uninitialized.  If there was uninitialized memory or variable usage, that would generally cause bigger problems than a repeating remote button.

I would agree that any differences in behaviour between a soft and a hard reboot would tend to implicate issues with hardware subdevices within the unit.

In any case, it's probably not useful for those of us familiar with system level programming and embedded hardware to speculate on the internal design of a Roku.