slartibartfast wrote: > Is a fix for this issue possible?
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 :-/ 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
