Home of the Squeezebox™ & Transporter® network music players.
Page 16 of 17 FirstFirst ... 614151617 LastLast
Results 151 to 160 of 166
  1. #151
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,644
    Quote Originally Posted by mherger View Post
    >> My restart script requests the current power state of the radio from LMS
    >> before restarting squeezeplay, then waits 30 seconds after squeezeplay
    >> restarts before restoring the saved power state.

    >
    > Might there be any advantage in doing the auto reboot via an Applet ? I
    > assume it can be done. It might allow for more sophistication in
    > restoring state (if, indeed, more sophistication would be helpful).


    Why is there any reboot required?

    --

    Michael
    There is no reason.

    However, there is an issue with all the jive based clients where a timer variable wraps back to zero every 24 days +20:31 which causes squeezeplay to stop updating the watchdog shared memory semaphore which causes the watchdog to reboot the device. Here's the thread where this is discussed. Starrting around post #26.

    My understanding is that some prefer this not happen in the middle of listening and want to reboot the device when it's not likely to be in use.
    Last edited by ralphy; 2020-11-20 at 12:15.
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 1-UE Radio
    Squeezebox client builds donations always appreciated.

  2. #152
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,644
    Quote Originally Posted by mrw View Post
    I may have misspoken. It would be enough to restart SqueezePlay, I think, if it were possible to do it without triggering the watchdog.
    I suspect that may not be easily done, in any robust manner.

    But @ralphy may know better:
    You need to stop the watchdog monitoring the squeezeplay.pid file in watchdog.conf and reboot once for the change to be applied.

    Otherwise right after the restart of squeezeplay, the watchdog is still monitoring the old pid which is no longer valid and the watchdog reboots the device anyway.
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 1-UE Radio
    Squeezebox client builds donations always appreciated.

  3. #153
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,479

    Community Build Radio Firmware

    >> Why is there any reboot required?
    > I may have misspoken. It would be enough to restart SqueezePlay, I
    > think, if it were possible to do it without triggering the watchdog.
    > I suspect that may not be easily done, in any robust manner.
    >
    > ralphy wrote:
    >> I have a script on my radio that just restarts squeezeplay twice a month
    >> to keep the radio from rebooting every ~21days from the timer variable
    >> overflow issue.


    Isn't this issue fixed in this firmware?

    --

    Michael

  4. #154
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,479

    Community Build Radio Firmware

    > However, there is an issue with all the jive based clients where a timer
    > variable wraps back to zero every 24 days +20:31 which causes


    Our mails just crossed :-). I thought you had fixed this. But I guess I
    was wrong.

    --

    Michael

  5. #155
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    633
    Quote Originally Posted by ralphy View Post
    However, there is an issue with all the jive based clients where a timer variable wraps back to zero every 24 days +20:31 which causes squeezeplay to stop updating the watchdog shared memory semaphore which causes the watchdog to reboot the device.
    This may be some kind of answer if unsigned 64 bit integers are available, and don't kill performance:

    Redefine jive_jiffies to be Uint64 instead of Uint32. https://github.com/Logitech/squeezep...c/common.h#L65
    Systems that use SDL_GetTicks() won't get much benefit, because that's only 32 bit unsigned milliseconds anyway. But systems that use clock_gettime could gain.

    Fix up jiveL_get_ticks to push appropriate unsigned value. https://github.com/Logitech/squeezep...amework.c#L967
    The lua number type in use on SqueezePlay is, I believe, a double float, with 53 bits ? of integer precision, not 64, but that might be ok. It ought to give us about 300,000 years instead of 24 days. It is a compile time option.

    Find out what breaks horribly, and on what platform. Rinse / repeat.

    Just an idle thought, really. 64 bits is overkill, but 32 bits clearly isn't enough. There may be a better way...

  6. #156
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,644
    Quote Originally Posted by mrw View Post
    This may be some kind of answer if unsigned 64 bit integers are available, and don't kill performance:
    Perhap changing the lua default integer type to 64bit by changing LUA_NUMBER_MODE to 22 making the lua integer type a long long. https://github.com/Logitech/squeezep.../luaconf.h#L24
    Need to confirm the LUAI_BITSINT definitions as well. I confirmed that a long long is 8 bytes on the radio. This could have a negative impact on available memory in the radio.

    Quote Originally Posted by mrw View Post
    Redefine jive_jiffies to be Uint64 instead of Uint32. https://github.com/Logitech/squeezep...c/common.h#L65
    Systems that use SDL_GetTicks() won't get much benefit, because that's only 32 bit unsigned milliseconds anyway. But systems that use clock_gettime could gain.

    Fix up jiveL_get_ticks to push appropriate unsigned value. https://github.com/Logitech/squeezep...amework.c#L967
    The lua number type in use on SqueezePlay is, I believe, a double float, with 53 bits ? of integer precision, not 64, but that might be ok. It ought to give us about 300,000 years instead of 24 days. It is a compile time option.[/url]
    SDL_GetTicks is called directly only in jiveblit.c which is easy to fix but jive_jiffies is used a lot and in many cases expected to be only 32bits.

    I would think using a double to have a bigger performance impact on the radio than a 64bit int since it uses emulated floating point. Need to try it to be sure. If changing LUA_NUMBER_MODE doesn't work.

    I'll have a stab at trying these changes on a 32bit intel linux system to see how far I can get.
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 1-UE Radio
    Squeezebox client builds donations always appreciated.

  7. #157
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    633
    Quote Originally Posted by ralphy View Post
    Perhap changing the lua default integer type to 64bit by changing LUA_NUMBER_MODE to 22 making the lua integer type a long long. https://github.com/Logitech/squeezep.../luaconf.h#L24
    Need to confirm the LUAI_BITSINT definitions as well. I confirmed that a long long is 8 bytes on the radio. This could have a negative impact on available memory in the radio.
    This might deal with the annoyance of having negative valued jiffies in lua code. It might even double the "reboot" period:
    Code:
    int jiveL_get_ticks(lua_State *L) {
    	lua_pushnumber(L, (LUA_NUMBER) jive_jiffies());
    	return 1;
    }
    It would avoid changing the LUA_NUMBER_MODE, and possibly impacting something else. LUA_NUMBER is also defined in luaconf.h, I'm pretty sure the Radio, and all SqueezePlay, is using 'double', but needs checking. I'm never sure whether I get casts/conversions right...

    Quote Originally Posted by ralphy View Post
    SDL_GetTicks is called directly only in jiveblit.c which is easy to fix but jive_jiffies is used a lot and in many cases expected to be only 32bits.
    Most of the time 32 bits must be just fine, because working MOD (u32_MAX+1) should be just fine unless the relevant jiffies are more than 24 days apart (edit: not 48 as originally posted). Provided the code sticks to subtraction and not straight magnitude comparison. I think. Need to check against concrete example.

    Quote Originally Posted by ralphy View Post
    I would think using a double to have a bigger performance impact on the radio than a 64bit int since it uses emulated floating point. Need to try it to be sure. If changing LUA_NUMBER_MODE doesn't work.
    But I think that it is already using double as a lua number type. Or is lua being rather more subtle that I imagine ? I was thinking that that lua simply converts an integer to a double anyway, all the time. I may be wrong.


    As regards 'a better way', I am getting the feeling that checking for wrap around might actually not be too onerous an approach. Would add some element of 'complexity' to the look of the code. There's a lot of places to examine, though.
    Last edited by mrw; 2020-11-21 at 10:49.

  8. #158
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    633
    Quote Originally Posted by mrw View Post
    But I think that it is already using double as a lua number type. Or is lua being rather more subtle that I imagine ? I was thinking that that lua simply converts an integer to a double anyway, all the time. I may be wrong.
    The Lua version 5.1.1 in LMS appears to differ from the downloadable tarball version 5.1.1 and the Lua website. So that hasn't helped me, I've probably been working off false assumptions.

    LUA_TINT seems to drive matters. It's in the LMS version 5.1.1, and 5.1.5, but not in the Lua 'stock' 5.1.1.

    It seems to be set to '-2' in lua.h : https://github.com/Logitech/squeezep.../src/lua.h#L81

    Here is where lua_pushinteger is defined: https://github.com/Logitech/squeezep...rc/lapi.c#L462

    And here is where the key setivalue is defined: https://github.com/Logitech/squeezep...lobject.h#L157

    I observe that if LUA_TINT is defined, it all looks very complicated. Otherwise it just seems to cast the integer to a lua_Number.
    Code:
     #define setivalue(obj,x) \
          setnvalue( (obj), cast(lua_Number, (x)) )
    So, it looks like lua is being rather more subtle that I imagined, and my assumptions about integers being converted to double all the time may simply not be true. I'm not sure what the implications would be on my previous thinking.

    My earlier thought of using lua_pushnumber to deal with "negative" jive_jiffies is probably not the best way to go...

  9. #159
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    633
    Quote Originally Posted by ralphy View Post
    SDL_GetTicks is called directly only in jiveblit.c which is easy to fix but jive_jiffies is used a lot and in many cases expected to be only 32bits.
    I think this only a stand-alone test program, so perhaps wouldnĺt need touching.

  10. #160
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    5,380
    My Radio occasionally goes silent while playing and simply adjusting the volume control restores the sound. I have a feeling the rotary selection knob may also restore sound. I wonder if this firmware fixes this issue.

    Edit. This happened today while listening to an old "Fighting Talk" on BBC Sounds but Radio was displaying artwork from A previously played local track.

    Sent from my Pixel 3a using Tapatalk
    Last edited by slartibartfast; 2020-11-22 at 02:42.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •