gordonb3 wrote: > I read that somewhat different, because the values of xxx.expires are > created elsewhere from jive_jiffies incremented with some > max_process_time value. The sole purpose of those lines you mentioned is > thus to identify timeouts. I'm sorry. I don't see the point of what you saying here. Being important or not, those timeout checks -won't work- in the timer-wrapping case, as already pointed out before, and need to be fixed.
*Please also re-visit my post '#79' (https://forums.slimdevices.com/showthread.php?111650-Spontaneous-turning-on&p=1013358&viewfull=1#post1013358).* I added further findings of buggy direct timer value comparisons. gordonb3 wrote: > (...)replace all instances of `lua_Number` (signed) to `lua_Integer` > (unsigned), which should either shift the restart to after 49 days or > possibly continue indefinitely. Yes, this should shift the restarts to 49 days. But continue indefinitely? Surely not. AFAIK, for `lua_Number` and `lua_Integer`, the same modular arithmetic rules apply. Btw, although it feels more "natural" to have unsigned timer values, I would -not- recommend switching to an unsigned value type `lua_Integer`, because as also @mrw pointed out, in order to fix the wrapping problems, we need to only deal with timer value _differences_. And when Lua behaves similar to C/C++, then, the difference between two unsigned values would in turn be unsigned, thus comparing the result to be smaller or greater than zero would be pointless and thus requiring an additional conversion back to a signed value. I already noted this in pseudocode in post #77, `if (signed_value(timer_value - some_point_of_time) > 0) then {do something};`. Of course, this could be done, but in order to increase code readability and to prevent programming errors, I'd thus recommend sticking to a -signed- timer value `lua_Number`. mrw wrote: > (...)One checks the _difference_ between timer value and current time. > Just modular arithmetic.)(...) YES!!! mrw wrote: > (...)Alternatively perhaps a LUA user defined type might be made to look > and act cleaner.(...) Yes, as I already mentioned somewhere before, this is exactly what the company I'm working for (as uC-firmware developer...) did, in C/C++, to prevent code that directly compares timer values, instead of inspecting differences. We had timer wrapping in mind when we decided to do so. But that might be a step to far here - I don't know, because I know Lua too little and I'm not aware of the amount of code changes required for this here. mrw wrote: > (...)no Radio has ever run longer than 24 days. What else might be > revealed ? That's a very valid thought that has been discussed before, but IMO, fixing bugs should not be prevented by the fear of finding more bugs ;-) Anyway, as you said, a regular scheduled restart might definitely still be a very good idea for Radios. 1x Squeezebox Classic, 3x Radio, 1x Touch, LMS 7.9.1 running on ODROID-U3, Ubuntu 16.04 and I'm happy with it! :) ------------------------------------------------------------------------ Steevee28's Profile: http://forums.slimdevices.com/member.php?userid=36395 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 _______________________________________________ Radio mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/radio
