PDA

View Full Version : RSS Feeds when client is off?



Michael Sigalos
2004-11-12, 15:55
kdf,

This information is GREAT! I doubt I'll ever contribute much Perl code
(more of a VB junkie myself), but I am always looking for insight into the
inner workings of SlimServer. If nothing else, it's just nice to know how
things work and you have cleared up a number of missing pieces.

I personally don't see the point in having something other than NOW PLAYING
when listening to audio and I'd prefer the screensaver to kick in only when
idle. But that's just me and I can see the rationale for not doing so.
Unfortunately, what I want is impossible right now AFAIK so screensavers
are basically worthless to me. If I set any screensaver, it covers up NOW
PLAYING and if I set NOW PLAYING as the screensaver, the display doesn't do
much when the client is idle. The proverbial catch-22.

I filed the screensaver when "off" enhancement as a means to an end. I
don't really need one in "off" mode per se, I just don't like the client
sitting around with a static display and having it display nothing seems
like such a waste given my investment. It seemed at the time that my
suggestion would be a quick and easy solution. But having alternate
display choices for "off" mode is a great idea and that certainly may be a
better long-term approach for "off" mode. I wonder what the people at Slim
think of that.

Honestly, if I had the ability to set an idle screensaver (LineX or RSS or
whatever) AND a non-idle one (NOW PLAYING), or if I could set the activity
as IDLE-PLAY-BOTH the chosen screensaver, I'd probably never ever ever turn
the clients "off" and I could map that big red button to something else.

Thoughts anyone?

Michael


On Fri, Nov 12, 2004, kdf wrote...
>
> I've posted this to the bug report, but perhaps this needs to be made
> available for public opinion as well.
>
> a little bit of history:

kdf
2004-11-12, 16:38
Quoting Michael Sigalos <miguel.slimdiscuss (AT) zoemail (DOT) net>:


> I personally don't see the point in having something other than NOW PLAYING
> when listening to audio and I'd prefer the screensaver to kick in only when
> idle. But that's just me and I can see the rationale for not doing so.
> Unfortunately, what I want is impossible right now AFAIK so screensavers
> are basically worthless to me. If I set any screensaver, it covers up NOW
> PLAYING and if I set NOW PLAYING as the screensaver, the display doesn't do
> much when the client is idle. The proverbial catch-22.

Nor did I. I makes sense if there is something to show related to playback, but
that doesn't exist yet. However, things can get persuasive when you get the
usual flood of 'me too's after a complaint. Such was the change.

>
> I filed the screensaver when "off" enhancement as a means to an end. I
> don't really need one in "off" mode per se, I just don't like the client
> sitting around with a static display and having it display nothing seems
> like such a waste given my investment. It seemed at the time that my
> suggestion would be a quick and easy solution. But having alternate
> display choices for "off" mode is a great idea and that certainly may be a
> better long-term approach for "off" mode. I wonder what the people at Slim
> think of that.

from what I can see, this is the only way to do it without breaking what is
already out there. I also feel, however, that it shouldn't be a huge priority.
If any eye candy is required to be competitive, tehn the visualisers need the
focus. With the upcoming release, a flood of users are going to make requests
to have radio work just they way they have always wanted. That will be some
distraction. The SQL backend needs some time too. There is a pile of
backlogged problems all related to the current data handling, and a lot of
things just don't make sense to put effort into until the SQL is in working
order. I think the off display should wait until it can be properly dealt
with. IE, a fully bitmapped display where users can pick and choose which
objects to display. The framework is in the roadmap.

Having said that, I'm perfectly willing to work on the off-display/screensaver
stuff if there is any specific design decision on it. I have nothing to offer
in the SQL, so it wont cost anything there.

>
> Honestly, if I had the ability to set an idle screensaver (LineX or RSS or
> whatever) AND a non-idle one (NOW PLAYING), or if I could set the activity
> as IDLE-PLAY-BOTH the chosen screensaver, I'd probably never ever ever turn
> the clients "off" and I could map that big red button to something else.
>
> Thoughts anyone?

if I could map it to a command to bring me beer, that would make me happy!
-kdf

Jack Coates
2004-11-12, 21:18
....
>> are basically worthless to me. If I set any screensaver, it covers up
>> NOW
>> PLAYING and if I set NOW PLAYING as the screensaver, the display doesn't
>> do
>> much when the client is idle. The proverbial catch-22.
>
> Nor did I. I makes sense if there is something to show related to
> playback, but
> that doesn't exist yet. However, things can get persuasive when you get
> the
> usual flood of 'me too's after a complaint. Such was the change.
>

agreed that it doesn't make sense. Or one might say, "me too!"

>>
>> I filed the screensaver when "off" enhancement as a means to an end. I
>> don't really need one in "off" mode per se, I just don't like the client
>> sitting around with a static display and having it display nothing seems
>> like such a waste given my investment. It seemed at the time that my
>> suggestion would be a quick and easy solution. But having alternate
>> display choices for "off" mode is a great idea and that certainly may be
>> a
>> better long-term approach for "off" mode. I wonder what the people at
>> Slim
>> think of that.
>
> from what I can see, this is the only way to do it without breaking what
> is
> already out there. I also feel, however, that it shouldn't be a huge
> priority.
> If any eye candy is required to be competitive, tehn the visualisers need
> the
> focus. With the upcoming release, a flood of users are going to make
> requests
> to have radio work just they way they have always wanted. That will be
> some
> distraction. The SQL backend needs some time too. There is a pile of
> backlogged problems all related to the current data handling, and a lot of
> things just don't make sense to put effort into until the SQL is in
> working
> order. I think the off display should wait until it can be properly dealt
> with. IE, a fully bitmapped display where users can pick and choose which
> objects to display. The framework is in the roadmap.
>
> Having said that, I'm perfectly willing to work on the
> off-display/screensaver
> stuff if there is any specific design decision on it. I have nothing to
> offer
> in the SQL, so it wont cost anything there.
>
>>
>> Honestly, if I had the ability to set an idle screensaver (LineX or RSS
>> or
>> whatever) AND a non-idle one (NOW PLAYING), or if I could set the
>> activity
>> as IDLE-PLAY-BOTH the chosen screensaver, I'd probably never ever ever
>> turn
>> the clients "off" and I could map that big red button to something else.
>>
>> Thoughts anyone?
>
> if I could map it to a command to bring me beer, that would make me happy!
> -kdf

You do have Perl as a backend, so you could map it to page someone, if you
have someone who'll bring beer after getting a page...

--
Jack At Monkeynoodle.Org: It's A Scientific Venture...
"Believe what you're told; there'd be chaos if everyone thought for
themselves." -- Top Dog hotdog stand, Berkeley, CA