Re: [SlimDevices: Radio] Squeezebox Radio would not connect to LMS 8: "Update required"
Looks like I got bit by this issue as well. Radio has the version patch installed and works with LMS 8.0.0 but fails with 8.2.0. gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111938 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Turn SueezeBox Radio off through ssh (no LMS!)
Code: # uname -a Linux SqueezeboxRadio 2.6.26.8-rt16 #1 PREEMPT RT Fri Feb 14 09:02:51 PST 2014 armv5tejl GNU/Linux # sed -e 's/"on"/"off"/' -i /usr/share/jive/applets/Playback/PlaybackMeta.lua # /etc/init.d/squeezeplay restart Stopping SqueezePlay rm: can't remove '/var/run/squeezeplay.wdog': No such file or directory Starting SqueezePlay # Squeezeplay 7.7.3 r16676 # ls crashlog.lzhz0W # sed -e 's/"off"/"on"/' -i /usr/share/jive/applets/Playback/PlaybackMeta.lua # /etc/init.d/squeezeplay restart Stopping SqueezePlay rm: can't remove '/var/run/squeezeplay.wdog': No such file or directory Starting SqueezePlay # Squeezeplay 7.7.3 r16676 Runs as expected. Maybe you can raise an issue on Ralphy's GitHub page? The main question of course is, when you apply the change to `PlaybackMeta.lua` does the Radio start up in the desired `off` mode or still show the menu (and continue playing)? ---- gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=115739 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Turn SueezeBox Radio off through ssh (no LMS!)
Just verified on my Touch, shouldn't do it. Also checked with 'off' and indeed it restarts into standby mode as I suspected it would, so I'm not sure why it doesn't work on your Radio. You did mention you were experimenting with the software? Maybe you changed something other to cause it doing a cold boot. gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=115739 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Turn SueezeBox Radio off through ssh (no LMS!)
I'm fairly certain that last time I tried (as I experimented with alternative versions of jive) it did not do a cold restart. Maybe 'off' is not the right mode? gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=115739 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Turn SueezeBox Radio off through ssh (no LMS!)
Squeeza wrote: > Yeah, You may be right. Many thanks for successfully trying to > understand my question! :) > > The "jive"-Command could be my solution! Thanks for showing this > possibility. > At the moment I do not know how to use it correctly but I will try to > find some documentation! > Don't think that will work. Jive is the main squeezeplay process and starting a second will most likely not allow you to change states in the already running instance. It is possible to restart the squeezeplay service though, so to switch Radio to standby you could run something like: Code: sed -e 's/"on"/"off"/' -i /usr/share/jive/applets/Playback/PlaybackMeta.lua /etc/init.d/squeezeplay restart #restore original setting sleep 5 sed -e 's/"off"/"on"/' -i /usr/share/jive/applets/Playback/PlaybackMeta.lua ---- gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=115739 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Turn SueezeBox Radio off through ssh (no LMS!)
Seems to me that your question is badly formulated.
Reading your second post in this thread I think that it is your
objective for the Radio to boot into standby mode rather than showing
the menu and depending on settings even playing music. I can relate to
that as it is also one of my annoyances to sometimes find the Radio on
when returning from a holiday.
The following commit is probably of interest to you:
Code:
diff --git a/src/squeezeplay/share/applets/Playback/PlaybackMeta.lua
b/src/squeezeplay/share/applets/Playback/PlaybackMeta.lua
index d4c0018a1..6f8c01645 100644
--- a/src/squeezeplay/share/applets/Playback/PlaybackMeta.lua
+++ b/src/squeezeplay/share/applets/Playback/PlaybackMeta.lua
@@ -101,13 +101,9 @@ function configureApplet(meta)
end
--must defer this since skin isn't loaded yet
jiveMain:registerPostOnScreenInit( function()
- --always start on,
unless was unclean shutdown, then start up with saved state
- if
appletManager:callService("wasLastShutdownUnclean") then
- log:info("Last
shutdown was unclean, restarting with previous soft power state: ",
settings.powerState)
-
jiveMain:setSoftPowerState(settings.powerState)
- else
-
jiveMain:setSoftPowerState("on")
- end
+ --Bug 16593: always
start on, even if soft power state was off when shutdown
+ -- this is to avoid a
situation where a Radio powers up to a black screen (fallback whenOff SS when
clock is not set)
+
jiveMain:setSoftPowerState("on")
end)
-- Connect player
Shamefully the original bug tracker is gone and so I'm not really sure
how the comment needs to be interpreted, i.e. whether the bug manifests
itself when you've set a different screensaver than clock, or when the
clock is at 1970-01-01. Either way you can try toggle the default state
to 'off' and see if the bug affects you.
----
gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050
View this thread: http://forums.slimdevices.com/showthread.php?t=115739
___
Radio mailing list
Radio@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Radio Stations: Recommended LMS Settings for getting Album Covers
When LMS controls your Radio it also controls its screen content, i.e. if you shut down LMS the Radio (or other SB) will continue playing the remote stream but it won't change the image any more. Now this part I'm not really sure about, but I think the image is actually downloaded by LMS and then pushed to the Radio (after scaling?). There is bound to be someone who can confirm this. Working from this possible faults include: - LMS machine goes to sleep - no internet access from the LMS machine - broken Image::Scale perl module gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=115261 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Somewhat unexpected result: After 49 days uptime the Radio did not restart at the first sign of trouble. Instead my log is filled with repeated dumps that are 8 seconds apart for almost 16 minutes until it finally shut down and restarted. The cause still appears to be UI no longer being updated but it seems to be less critical to watchdog than with the negative times from the original jive. gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
[SlimDevices: Radio] Unionfs I/O bug?
Reviewing the message log on my Radio I'm seeing the following message pop up when I'm connected through SSH (and only then) Code: kernel: [244297.421776] unionfs: filldir: possible I/O error: a file is duplicated in the same branch 0: Framework.lua Now I do run with an alternative version of that file, so this file does in fact exist twice on the system (as do some others), but my comprehension stops completely why this error only occurs when an SSH connection is active. Anyone else seen this or have some clue? gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=114463 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Looking good so far ;) Code: # uptime 11:50:54 up 25 days, 16:03, load average: 0.12, 0.12, 0.10 # gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Oh, that's pretty hilarious. The sources result in a binary that uses dynamic linking to libraries that don't exist on the target and is statically linked to libraries that do exist on the target. How on earth did they manage to mess that up like that? gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
ralphy wrote: > There are many patch files included in the 'squeezeos poky build > repository' (https://github.com/ralph-irving/squeezeos). > > If you post details on your build failure, we should be able to figure > out why I don't have a problem. Seems I was mostly chasing a red herring. There was an alignment error in audio decode and as a result it started spitting out various other messages including that of an unrecognized command line option. The main Make file also wants to build some LUA component `luartmp` that fails rather critically, but it appears you can build and install the components individually except for the hardware specific folders that appear to be incomplete and probably need to be combined with another folder but for which no documentation whatsoever exists. Either way, the version of jive I created started with complaining about a missing png image and a bunch of font files. I found the image in the `squeezeplay_baby` folder of which I copied the entire `share` folder, but this resulted in jive complaining about another png image and completely stop (so not even complaints about the font files even though these are still missing). It's family time, so I stopped for now. ---- gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Steevee28 wrote: > Things seem to be very complicated regarding Lua's internal value > representation of the -number- type, see LUA_NUMBER_TYPE definition in > 'luaconf.h' > (https://github.com/ralph-irving/squeezeos-squeezeplay/blob/cd98c71c4394cc39f6715014aedf8bc1c8550b96/src/lua-5.1.1/src/luaconf.h#L16). > > I just stumbled across 'this discussion' > (https://forums.slimdevices.com/showthread.php?111663-Community-Build-Radio-Firmware=995599=1#post995599) > between @mrw and @ralphy which I completely missed so far and I was not > aware that they already struggled this much to find a solution for the > wrapping problem. Wow! Ah yes. There was talking about introducing an integer type to LUA for some time, but it produced weird results. I got confronted with that when another application I used to use (Domoticz) suddenly changed its code base to use this integer type and all my automation scripts started failing after I installed the update. Either way, since the source of this issue lies in an apparent requirement for the C code and the LUA scripts to use the exact same value for some number at any given time the obvious solution is to make both environments use a compatible number format. As stated it will be dubious to store an integer value in a double, but then again it isn't actually an integer as it represents the sum of seconds and milliseconds which are itself of type time_t which is likely a floating point value as well (at least on 32 bit systems). The main problem with using a double is that you can not reliably keep adding 1 all the way to MAX_VAL, but if memory serves correct it will be accurate up to ~50 bit integer values on 32 bit systems and would therefore allow integer precision for jive_jiffies() for several years. Note that this is not related to the pull request I made. That one is purely for keeping the conversion method from C unsigned integer to lua_Number to alter the number sign when pushing it onto the LUA stack. ---- gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
ralphy wrote: > > (...) arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1 > (...) > That is weird, because then you should be seeing the same error, unless of course the build you perform skips the parts where these errors occur. I'm actually somewhat hazy on that point as well, as there does not appear to be any instruction how to build for any specific target machine even though there is a separate subdirectory for each of them. ---- gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Steevee28 wrote: > Oh, ok, there are lines like `start_jiffies = (Uint32) > luaL_optinteger(L, 2, 0);` in there, so changing the Lua jiffy timer > datatype to anything else but Lua_Integer definitely breaks this code > :-/ > *EDIT*: or can a Lua_Number or userdata type be converted here > on-the-fly to Lua_integer? I don't know. There is no integer type in LUA 5.1. The C functions lua_integer() and lua_number() are merely for interfacing between the two languages. ---- gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Yeah... The sources appear to be pretty messed up. Running a native build I'm seeing the weirdest errors pop up, including ones that appear to indicate that they are supposed to be built with at least version 4.6 of the GNU C compiler, but that doesn't fit the source's dates and would likely also cause issues with the libc version in the players. What compiler version do you use for the community edition? gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
I'm just wondering. Did you guys read this commit message from the git history? > Change from SDL_GetTicks() to jive_jiffies(). This allows a single time > epoch to be > shared between the main and alsa backend processes. > > Bug #12909 I have no working link to the original bug tracker, but from this it seems vital for the various components to be using the same time reference and at present the time registration in that ALSA backend will reset to zero after 49 days 17 hours (-ish), which is therefore what the LUA frontend should do as well and we currently have no clue what will happen if we don't because we have never been able to get past the 24th day. ---- gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Steevee28 wrote: > > It's absolutely correct what you wrote, but as @ralphy pointed out, he > -is- able to rebuild the Jive executable, or did I get this wrong? There > is a community build of Radio firmware and @ralphy is even building > PiCorePlayer from scratch, as far I know. So we -can- change that bit of > code and thus fixing the C-part should be pretty simple. > As I read it this he can only make that change based on the community version, which to me appears to imply that he uses a newer development platform that creates incompatible binaries. I'm not yet willing to go that way so I'm currently investigating a different route. As my armv5te development machine originally came with a Debian Squeeze based OS, which seems to be what the Squeezeboxes are based on as well, I did some digging and found the original install image. I'll need to change some parameters as Squeeze is obviously archived now and I will need build-essentials to get me going, but I should then be able to compile the squeezeplay sources to create a jive binary that is compatible with my Radio. In the meantime I have submitted a pull request to Ralph's fork to be included in the community build. The change is of course currently untested on the actual platform but I'm certain it will solve the sign change in the LUA part of squeezeplay. gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Oh Christ... I'm going about this all the way wrong. I was focussing on matching the numbers inside the LUA scripts, patching the code to be indifferent to the sign change, but the whole point of this jive_jiffies() thing is for all independent components to have their time values synchronized. And so even if I can get the LUA part to continue running with negative values for time this is bound to result in the unwanted behaviour that led to the introduction of jive_jiffies() in the first place. So let's break this down. As I see it there are two separate issues that require addressing: - *sign change* There is a difficult way and a simple way to address this. The problem with the simple way is that this requires the jive executable to be recompiled and therefore this is not a simple patch. The difficult and user patchable way is to handle the sign change inside the LUA scripts and the most straight forward method in this case will likely be to change all references to `getTicks()` to a new function `getCorrectedTicks()` that adds 4,294,967,296 when `getTicks()` returns a negative number. - *max integer value overrun* Be noted that it will be rather pointless to even start addressing this issue without having considered #1 first. As has been stipulated earlier the LUA number format is different from what `jive_jiffies()` returns. More specifically, `lua_number` has a much higher maximum value than the `uint32_t`that is used internally inside the jive executable *AND* the ALSA backend. At this point I'm unsure what would be the best or even simplest way to address this as both methods imply a fairly big change to the code base. Implementing some MAX_VAL routine inside the LUA scripts to handle loop issues is one method, the other one would involve changing the value type to be compatible all over the board (i.e. a double) which appears to have the highest chance of not running into other issues, be it somewhat dubious to store an integer value in a floating point type. gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Maybe... As it happens I do already have a crossdev environment for armv5te, but it will be a major challenge to create a binary that will run with the existing libc on the Radio. gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Oops! Sort of bricked my Radio by inserting an if clause on `framedue > 0x8000` which apparently LUA translated into `-1` and thus executed instantly to trigger watchdog. Luckily I was able to recover from it, but obviously it did reset the timer so I'm back to waiting another 24 days to verify what it does. ---- gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Maybe, maybe not. In my experience comparing notes often helps to identify the actual problem a lot quicker. gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
mrw wrote:
> The point being, I think, that, at least in C, checking that a signed
> integer is negative is probably more readable, and possibly more
> efficient, than checking that an unsigned integer is >= half MAX UINT +
> 1, or whatever.
>
That's actually one of the most efficient operations in computing:
Code:
if (value & 0x8000) {
...
}
----
gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050
View this thread: http://forums.slimdevices.com/showthread.php?t=111650
___
Radio mailing list
Radio@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Steevee28 wrote:
> ... 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};`.
>
That was my original point, the timer values only being used to
calculate a difference in order to detect a timeout situation. I made
one wrong assumption though, as you do now, because lua_Number is not an
`int` but a `double` (i.e. a floating point number). Meaning that when
you increment this value after it was imported as the equivalent of a
signed integer it can become a value greater than or equal to 2^31 which
the next imported value can never become and therefore the test `t1 +
something < t2` with the latter being imported as minus 22 days will
always fail. I need to follow the code why this would cause this issue
though and moreover why it consistently seems to affect the ui task.
gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050
View this thread: http://forums.slimdevices.com/showthread.php?t=111650
___
Radio mailing list
Radio@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Steevee28 wrote: > That's interesting. My findings were completely different. See, e.g.: > https://github.com/Logitech/squeezeplay/blob/49f41e48311ade3a4a879b4b27283036363724b5/src/squeezeplay/src/ui/jive_framework.c#L1305 > and following. > or see these lines of code in jive/ui/Timer.lua: > https://github.com/ralph-irving/jivelite/blob/a1307c523a7f70e28ecde3a1e238132b23323a77/share/jive/jive/ui/Timer.lua#L161 > https://github.com/ralph-irving/jivelite/blob/a1307c523a7f70e28ecde3a1e238132b23323a77/share/jive/jive/ui/Timer.lua#L177 > https://github.com/ralph-irving/jivelite/blob/a1307c523a7f70e28ecde3a1e238132b23323a77/share/jive/jive/ui/Timer.lua#L183 > 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. > > oh, and that's a funny one (although very probably irrelevant): > https://github.com/ralph-irving/jivelite/blob/a1307c523a7f70e28ecde3a1e238132b23323a77/src/system.c#L100 > Interesting comment, as it clearly shows that the programmer was aware of the limit, but didn't consider it to be critical nor realized that LUA would cast the value to a signed int. > > Note: the easiest way to test the changes may be to modify the code of > jive_jiffies(), so that it returns a timer value close to (int32_t) > wrapping right from the start, so we don't need to wait for 24 days, see > https://github.com/Logitech/squeezeplay/blob/49f41e48311ade3a4a879b4b27283036363724b5/src/squeezeplay_baby/src/common.h#L67 Yes, but that also requires compiling to the correct (ancient) support libraries, although maybe you could get away with static linking on a newer development platform. Of course once you do that you can also fix jive_jiffies() to perform the roll-over itself at some `safe` time. Another option for testing in this case would be to upgrade LUA to 5.4+ and 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. ---- gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Steevee28 wrote:
> Thank you for having a closer look.
> As I already posted before (see post '#52'
> (https://forums.slimdevices.com/showthread.php?111650-Spontaneous-turning-on=967027=1#post967027)),
> a quick code review revealed several pieces of Jive code that are not
> timer-wrapping-aware. This causes events to no longer fire and
> delay/wait loops to loop forever.
>
> Basically, all these buggy pieces of code look similar:
> >
Code:
> > if (timer_value > some_point_of_time) then {do something};
>
> (pseudocode)
> >
> To finally get that problem fixed, they all need to be reviewed and
> changed to something like this:
> >
Code:
> > if (signed_value(timer_value - some_point_of_time) > 0) then {do
something};
>
> (pseudocode)
> >
>
I actually did have a look into that and essentially all of bits of code
I examined don't really use the value itself (which would be pointless
anyway as it does not reference any 'real' time that would mean anything
to a user) but are about calculating a time difference that should not
be affected by negative numbers being fed to it. e.g. `-111 - (-110)`
still results in a valid result of positive 1 and really the only bad
thing I can imagine happening here would be something like `(-MAX+4) -
(MAX-3)` which results in -2*MAX + 7, but I would not expect this to
happen consistently with every roll-over.
I do think someone mentioned having disabled watchdog and the UI
becoming unresponsive after the critical time? That does sound
consistent with my finding that the `ui` task is no longer being called
several seconds before watchdog causes the player to reboot. It will be
interesting to know if any of the other functions seize at that point as
well, in particular the alsa backend which appears to be the reason that
this clock method is being used.
gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050
View this thread: http://forums.slimdevices.com/showthread.php?t=111650
___
Radio mailing list
Radio@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Right, that was somewhat disappointing. There's nothing weird with networking to be seen and reviewing the log times it seems like the task manager simply stops executing the `ui` task even though there is no logging of this task having been removed. This appears to indicate that the task manager thinks that the task is still running, which may actually be true if it entered an endless loop or at least longer than it takes for watchdog to kick in. On to the next restart... gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Spontaneous turning-on
Chiming in (reviving) I relocated the logs to another machine so they wouldn't get lost at reboot and since the problem appears to be related to the Tasks module I enabled some debug options on it. What I found is that the application does not actually crash, which I kind of expected already, but it appears to enter a loop where the network task repeatedly adds and removes socket tasks until watchdog intervenes stating that some semaphore was not changed (within some set time?). At that point the last time the `ui` task was executed was 8.nnn seconds ago (normally executes 20+ times per second), so that definitely seems related. I have another two weeks before the next player reaches fatality and possibly drill deeper towards the source. gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111650 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
Re: [SlimDevices: Radio] Squeezebox Radio would not connect to LMS 8: "Update required"
cozbot wrote: > So I get this error message on LMS 8.1.0 when all the Squeezebox Radios > are unplugged/off and only the two Duet and one Touch are connected (and > I restarted LMS after detaching SB Radio's). > > "You seem to be using a Radio with an outdated firmware, not recognizing > this version of Logitech Media Server. Please consider patching it" > Seems like a red herring to me. LMS should not have any issues distinguishing between Radio and Touch (and other SB devices). You probably have some (old) reference to a SB device that no longer exists. You could check/edit your preferences file, but I was made aware just recently that there is a third party plugin called `Client Cleanup` that allows you to view unconnected players and remove them in a safe(r) way. ---- gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=111938 ___ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
