Steevee28 wrote: 
> I already thought some time about a fix, but it is really not that easy.
> Basically I only see two options:
> 
> 1. fix jiveL_get_ticks(), see
> https://github.com/Logitech/squeezeplay/blob/public/7.7/src/squeezeplay/src/ui/jive_framework.c#L967
> or
> 2. fix *all* lines of code that directly compare timer values.
> 
> 
> Regarding option 1:
> 
> This would include to change the type of returned value of
> -jiveL_get_ticks()- from -lua_Integer- to -lua_Number-, meaning that it
> would be required to extend the (missing) upper bits of the jiffy timer
> value before passing it on to Lua. Checking if the upper bits need to be
> increased, compared to the value previously returned, would require the
> storing of the last returned value in some variable, which in turn would
> either require a multi-thread locking in some way, usage of
> thread-local-storage or, which would probably be best, the use of
> interlocked intrinsics. -(This is not required, of course, if the Jive
> framework is single threaded. i don't know that.)-
> For some time, facing the notable amount of buggy code lines directly
> comparing timer values, I thought that this may be a good option. But
> digging some further in the code, I saw eg. code of -process_event()- in
> the jive framework that is storing jiffy timer values in some
> -JiveEvent- structure. 
> Thus, changing the retured datatype of -jiveL_get_ticks()- would require
> to also change the datatype of timer values in structures like that,
> otherwise the adaption could break further code (e.g. comparing event
> timestamps to -now- - don't know whether there is such code).   
> 
> Regarding option 2:
> 
> As it was possible to find a notable amount of such buggy code lines in
> a relatively short amount of time, I guess that there are much more
> similar lines of code that would require fixing. I'm unfortuantely not
> completely sure how to fix them all, because I don't exactly know how
> Lua handles 2-complement -lua_Integer- values in the wrapping case. In
> C, I would know what to do, see my post #7, namely only work on
> timestamp -differences-.
> As already pointed out, one would also have to pay special attention to
> code lines like this: -framedue = framedue + framerate-, see
> https://github.com/Logitech/squeezeplay/blob/public/7.7/src/squeezeplay/share/jive/ui/Framework.lua#L353,
> because, depending on Lua's handling of datatypes, this may result in
> values that are out of range of the actual timer values.
> In fact the -only- valid arithmetic operation on timestamps should be
> -subtraction from each other-. (For that reason, in the company I'm
> working, we wrapped timestamp values by a special datatype only allowing
> testing of equality of two timestamps and subtraction from each other.)
> 
> Anyway, I now believe that option 2, thus fixing all these lines of code
> is the only option to finally get rid of the problem. But this looks
> like a pretty bunch of work.
> 
> I'm currently still too far away from enough knowledge about Lua and the
> Jive framework to be able to do this :-/@mrw  suggested a managed reboot at a 
> set time. Would that be possible?

Sent from my Pixel 3a using Tapatalk




------------------------------------------------------------------------
slartibartfast's Profile: http://forums.slimdevices.com/member.php?userid=35609
View this thread: http://forums.slimdevices.com/showthread.php?t=111650

_______________________________________________
Radio mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/radio

Reply via email to