I installed LMS 8 on a piCorePlayer a few days ago, and updated with
latest nightly yesterday. I hadn't used my Radio since, but when I
turned it on now it did work as usual. The firmware was 7.7.3-r16676.
Just to try it, I followed the instructions in the first post of this
thread and
Is the only way to test your work to build myself? Or do you have any
binaries to give a try?
--
Michael
___
Radio mailing list
Radio@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/radio
Oh... that message might only go away after a server restart. It's a
flag which will only be set if needed, but never reset. Needs some
refinement.
Just getting back to this thread, and a server restart did remove the
message. Could you add a note to the instructions about this?
I'll review
ralphy wrote:
>
> >
Code:
> > Fix up misaligned and/or jittery text after horizontal scrolling.
Squeezeplay often fails to properly "home" horizontally scrolled text when
scrolling has paused. On a Squeezebox Controller, this fault may also result in
"jittering" of
Steevee28 wrote:
> IBut I now looked through the kernel debug buffer of the Radios and
> stumbled across the message >
Code:
> > eth1 (WE) : Wireless Event too big (33)
> > each time right before Wifi connection is lost. Maybe that this is
> the
bpa wrote:
> (...)
> Is Router setup to choose channel automatically (...) Can't remember if
> channel 13 is supported well by Radios.
>
I've now set my router to some fixed channel and also disabled 802.11n
at all, so it is sticking to b/g for all devices now, but that doesn't
help.
Btw,
mherger wrote:
> Oh... that message might only go away after a server restart. It's a
> flag which will only be set if needed, but never reset. Needs some
> refinement.
Just getting back to this thread, and a server restart did remove the
message. Could you add a note to the instructions
mherger wrote:
> > OK I do see
> > User-Agent: SqueezePlay-baby/7.7.3-r16676-lms8 (armv5tejl)
>
> Oh... that message might only go away after a server restart. It's a
> flag which will only be set if needed, but never reset. Needs some
> refinement.
>
> --
>
> MichaelYup that clears it.
OK I do see
User-Agent: SqueezePlay-baby/7.7.3-r16676-lms8 (armv5tejl)
Oh... that message might only go away after a server restart. It's a
flag which will only be set if needed, but never reset. Needs some
refinement.
--
Michael
___
Radio
Just a quick update.
I've been successfully using the new firmware for the last 6 weeks as
the changes have progressed.
I've updated the ssh client/server and wpa_supplicant components,
enabled cron, applied a few bug fixes and native LMS 8.0 support.
As I indicated in my previous post, I'm
robho wrote:
> Maybe this thread is mostly about audio quality/tweaks, but if you are
> planning on releasing a new generic firmware it could be valuable to add
> support for WiFi channel 12-13. There's a simple fix here:
>
mherger wrote:
> > I got the same warning with my previously patched Radios. I
> uninstalled
> > and reinstalled the patch and still see the warning.
>
> We'll see where this goes. I've experienced cases where I had to
> re-install twice before it picked up the change.
>
> You could enable
I got the same warning with my previously patched Radios. I uninstalled
and reinstalled the patch and still see the warning.
We'll see where this goes. I've experienced cases where I had to
re-install twice before it picked up the change.
You could enable debugging for network.http, then
mherger wrote:
> > I've successfully patched both my Radios, but the message "You seem to
> > be using a Radio with an outdated firmware, not recognizing this
> version
> > of Logitech Media Server. Please consider patching it. Get more
> > information." remains in Server Settings when I select
Steevee28 wrote:
> It's very unlikely that my own router is the problem, because I have
> some other devices in the network that still work flawlessly.
But don't rule it out. LMS Streaming audio requires continuous
connections. Newer video/audio streaming protocols allow for "breaks"
and can
bpa wrote:
> Common point of failure may be the router. (...) Also check for other
> nearby Wifi networks ?
>
It's very unlikely that my own router is the problem, because I have
some other devices in the network that still work flawlessly.
But there are over 30 other Wifis of neighbours
16 matches
Mail list logo
