I was programming my Logitech Harmony Remote for a new DVD player when I
remembered this thread.
Slim Devices is now a Logitech company, how about replacing the Slim
Remote with a Harmony 525 (or similar) pre programmed for SC, modify SC
to respond to a third remote, (JVC, Classic Slim and now Ha
On Tue, Apr 15, 2008 at 1:51 PM, getprogs <
[EMAIL PROTECTED]> wrote:
>
> Cheers,
> Even though I am not using transcoded audio (WMA was implemented in HW
> in some 6.x release, cant really remember when) FF/RW does not work for
> WMA.
Are you using WMA-lossless? This is not supported in the fi
Cheers,
Even though I am not using transcoded audio (WMA was implemented in HW
in some 6.x release, cant really remember when) FF/RW does not work for
WMA.
I would prefer any sort of functionality than the none-at-all that I
currently have, so looking into this is a very welcome suggestion! And
w
>Is this circle-jerk ever going to end and see Fast-Forward and Rewind
>implemented for the Squeezebox? It takes all of a second for anyone
>familiar with other audio equipment to realize that functionality is
>completely missing.
>
Existing functionality works fine for me; in fact I found it extr
MelonMonkey;285941 Wrote:
> I'm not sure what foul language Mike was talking about
MelonMonkey;285757 Wrote:
> Is this circle-jerk ever going to end
It's a pretty obscene connotation and shows a lack of respect for the
developers.
Also, why not talk about what is desired BEFORE the feature is
Not new, I just want to see the idea get some traction. It's pointless
to keep discussing the same thing over and over when there has already
been (in this or other threads) a consensus of what needs to be done.
I'm not sure what foul language Mike was talking about nor why he seems
to think I me
MelonMonkey;285757 Wrote:
> The design goal is pretty straight forward, so I don't understand how so
> much time can be wasted talking about it when it can better be spent on
> the engineering to achieve that goal.
You must be new. This is nothing compared to >
http://bugs.slimdevices.com/s
Melon,
Please have a little patience, messing with FF/RW was never going to be
a part of the 7.0 release, and that just came out a few weeks ago. This
thread is part of the developers specing out what is going to happen
down the line for a future release.
Also please watch you language, your las
Overall I like awy's proposal, but have a suggestion for an additional
feature. When in scanner mode, it would be useful to be able to enter a
time offset into the track using the numeric keypad on the remote. I
used to have a CD player that allowed for this, and it was the most
efficient way to g
Is this circle-jerk ever going to end and see Fast-Forward and Rewind
implemented for the Squeezebox? It takes all of a second for anyone
familiar with other audio equipment to realize that functionality is
completely missing.
The design goal is pretty straight forward, so I don't understand how
max.spicer;283375 Wrote:
> I don't like the audio feedback, but that's mainly due to how it's
> implemented. Audio feedback is a good thing and many devices do it
> much better. The current method basically sounds like a skipping cd,
> which is horrible. I've used devices that do this much bet
hi awy,
I like your proposal, well thought of, well rounded.
The only thing, about left/right vs up/down buttons. Are you planning
on making it available in .map file? That way anybody can adjust it to
their liking On SB it's common to use left/right buttons to traverse up
and down the menu stru
max.spicer;283375 Wrote:
> It sounds to me as if you are needlessly mixing the scanner mode and
> accelerated playback modes. I think it would be much better if they
> were entirely separate.
Thanks Max.
The original proposal was simply to get rid of the accelerated playback
modes. There has
It sounds to me as if you are needlessly mixing the scanner mode and
accelerated playback modes. I think it would be much better if they
were entirely separate. During playback, single presses of ffwd/rwd
should trigger accelerated playback. Holding ffwd/rew when there is a
current track (but n
Here is a revised proposal based upon some of the feedback received and
the experience of playing around with the implementation.
PROPOSAL:
- Press-and-hold ">>" (FWD) or "<<" (REW) to enter Scanner. The
scanner is a modified version of kdf's Song Scanner plugin. It
displays an input b
How do I just skip to the next/previous song?
a
--
arainert
arainert's Profile: http://forums.slimdevices.com/member.php?userid=16091
View this thread: http://forums.slimdevices.com/showthread.php?t=41235
___
"Do you mean on the WebUI or the player display? On the player display
that it pretty much what you get already."
On both the web interface and on the player. I am running 6.5. If 7
does this, I guess I have another reason for upgrading when it is
stable. :-)
--
dickmc
Dick
__
dickmc;278956 Wrote:
>
> 1. Display the elapsed time of a song (minutes:seconds) on the player
> window in Slimserver. (I've always missed this.)
>
It does (in SC 7).
>
> 2. When the << or >> is clicked display the resulting speed and
> direction such as: 2X> 8X< and show the resulting ela
I don't mind the current design that bad, but find it finicky to use. I
do like the audio feedback.
I suggest the following:
1. Display the elapsed time of a song (minutes:seconds) on the player
window in Slimserver. (I've always missed this.)
2. When the << or >> is clicked display the resulti
awy;276929 Wrote:
> No, no decisions yet. I am thinking hard about the practicality or
> retaining the audio feedback, where possible. The current mechanism
> really is horrible but I can see that it has some use and there is
> clearly some support for it.
>
> The 'press centre button to enter s
I really hate the FF/RW function...It is the most useless feture when
playing my music-collection. (most Flac).
And the DVD speed-x-factor adding x times with each push, is confusing.
I would rather have CD-type FF, even with "AM quality"(32-64+kbs)
sound...
Arne K
--
Cobra2
-
Any way to move back and forward in a track would get my vote!! I'm
actually in two minds whether audio feedback is useful or not - I
personally don't care whether audio feedback is available or not. Even
a system where you could type in a time as a "GoTo" field would be
fantastic!!
--
amey01
-
No, no decisions yet. I am thinking hard about the practicality or
retaining the audio feedback, where possible. The current mechanism
really is horrible but I can see that it has some use and there is
clearly some support for it.
The 'press centre button to enter scan/select mode' sound interest
But any FF/RW functionality that is usable with WMA files gets my vote!
I have votet for the bug regarding the inability to scroll through
transcoded files, but just want to add my 5C worth here as well (4
then? 3? 2...?)
I do not care about changing the way it works, I mean even having the
abilit
kdf;276728 Wrote:
> >
> > Have any decisions been made on this?
>
> nothing public. I supposed awy could answer this if he's not busy with
> everything else.
>
> > I'd prefer silent with a progress bar as well. All my files need to
> be
> > transcoded so I'm biased.
>
> You are still out of l
Phil Meyer;251074 Wrote:
> The iPod also has two mechanisms for seeking through a song.
> 1. Press and hold >> to fast-forward with audio feedback.
> 2. Press the middle circular button to go to a song progress bar. The
> wheel is then used to set a specific position within the song. The
> musi
>
> Have any decisions been made on this?
nothing public. I supposed awy could answer this if he's not busy with
everything else.
> I'd prefer silent with a progress bar as well. All my files need to be
> transcoded so I'm biased.
You are still out of luck with the current implementation. A pr
Have any decisions been made on this?
I'd prefer silent with a progress bar as well. All my files need to be
transcoded so I'm biased.
But as the above poster says if I have use timeline that would work for
me as well. Just need some way to move around transcoded files.
Thanks,
Jeff
--
Je
The one thing I really miss at the moment is the ability to jump around
in transcoded material by clicking in the SqueezeCenter track timeline
(like I can for native streams). Whatever changes are made to FF/REW
functionality, I'd be very happy if only support for that was added.
I agree that the
this is an excellent idea. I think the current FF/REW is the poorest
part of the system. On my SB3 the loud cracking and jumping that often
happens makes it virtually unusable. I would agree with the audio mute
feature as this would prevent this. Keeping it simple and reliable with
just the progre
On Sun, 23 Dec 2007 15:07:14 -0800, "cbemoore"
<[EMAIL PROTECTED]> said:
>
> Phil Meyer;251058 Wrote:
> > The problem is the FF key will skip to next track if pressed briefly.
> > The key must be held down to invoke some form of fast-forward
> > behaviour.
>
> Here's a controversial suggestion,
cbemoore;251239 Wrote:
> Here's a controversial suggestion, but the more I think about it the
> more sense it seems to make. Why not reverse the current logic so that
> a brief press of FF or RW increases or decreases the speed, and a long
> press skips to the previous or next track?
>
> This wo
>Why not reverse the current logic so that
>a brief press of FF or RW increases or decreases the speed, and a long
>press skips to the previous or next track?
>
It did cross my mind too for a split second, as I often navigate through the
now playing list to choose a song to skip to, rather than us
Phil Meyer;251058 Wrote:
> The problem is the FF key will skip to next track if pressed briefly.
> The key must be held down to invoke some form of fast-forward
> behaviour.
Here's a controversial suggestion, but the more I think about it the
more sense it seems to make. Why not reverse the cur
>It's much like the way the volume up/down buttons work. Except now the
>display bar indicates the location inside the current track.
>
Not really. Volume up/down is instant - as soon as you start to press the
volume up key, it will start to raise the volume. However, you'll still have
to hold
On Sun, 23 Dec 2007 11:00:41 +, "Phil Meyer"
<[EMAIL PROTECTED]> said:
> >I'm probably to fast ;-)
> >
> Slow down and chill out then ;-)
>
> >i press >> nothing happens or it goes silent
> >then a little later a sound snippet ? by then i've pressed play again.
> >Confused as ever. Now i get
On Sun, 23 Dec 2007 10:50:58 +, "Phil Meyer"
<[EMAIL PROTECTED]> said:
> I compare the current fast-forward functionality to my Sky+ box for
> digital TV control, which is considered by many to be the best and most
> user-friendly PVR on the market. With that box, you press >>. This
> takes
Phil Meyer;251058 Wrote:
>
> >Perhaps even better -- momentary presses would have that DVR-like
> >behavior, and held presses would have Alan's proposed behavior.
> >
> The problem is the FF key will skip to next track if pressed briefly.
> The key must be held down to invoke some form of fast-
>I would like to see current situation where each FFWD press speeds it
>up, but would be nice if FRWD stepped the speed back down so could
>control speed.doesn't seem to do that now.
The current functionality uses repeated press-and-hold FWD presses to speed up,
use repeated REW presses to sl
>There is considerable dissatisfaction with the current implementation,
>although I suspect that it probably
>meets the needs of some people just fine.
>
Can you recap what features of the current functionality users are dissatisfied
with? Maybe there's just a lack of information on how it works
Tend to agree with an earlier poster: need to be able to hear what you
are skipping for this to be useful. Currently I find that the lack of
responsiveness is the biggest cause of frustration but I like being
able to skip forward or backwards in a track. I agree if this is a
problem on transcode
>I'm probably to fast ;-)
>
Slow down and chill out then ;-)
>i press >> nothing happens or it goes silent
>then a little later a sound snippet ? by then i've pressed play again.
>Confused as ever. Now i get it, I'm not patient enough to let the
>function kick in.
>
There would be no difference wi
>How would you feel about DVR-like behavior? Press Fwd once and you jump
>~30 seconds ahead (rough computation based on file size if not natively
>supported format?), pres Rew once and you jump ~10 seconds back. The UI
>should let users choose different Fwd and Rew jump amounts.
>
That would be eve
>If there were the first rule of coding, then, I'd imagine it would be -
>the code has to do something useful and purposeful, preferably what the
>paying side asked for.
>
That's not a rule of coding - that's the role of requirements capture and
design :-)
>Good that this thread was started (kudo
I have never undestood the ff function untill today :-)
It works even worse in an wifi setupp.
"Let me start by recapping on the current functionality, as I
understand it:
* FFW mode can be entered by press-and-hold of the ">>" button on
the remote. It will remain in FFW mode once the ">>" butto
Phil Meyer;250943 Wrote:
> My most frequent use for fast-forwarding is when I am listening to
> podcasts that I have downloaded and scanned into my music library. For
> example, Coverville. An episode of this podcast generally lasts 30mins
> to an hour. When I hear a bad song, I want to skip f
Phil Meyer;250971 Wrote:
>
> There is no first rule of coding.
> Phil
If there were the first rule of coding, then, I'd imagine it would be -
the code has to do something useful and purposeful, preferably what the
paying side asked for.
Good that this thread was started (kudos to the idea that
>I read Sean's explanation (in the quoted thread) on why it's difficult
>to do ff's perfectly. It seemed leaving out audio would make it easier
>*for the developers*
>
I can't see how rewriting the implementation would be easier than doing nothing
;)
>I find the current method confusing and - for
>For most (all?) formats we should be able to just seek proportionally
>to the designated point in the _source_ file, and just re-start
>transcoding from there.
>
Perhaps play audio feedback when playing non-transcoded, and don't play audio
when playing transcoded files.
Display a progress bar wh
On Sat, 22 Dec 2007 20:37:55 +, "Phil Meyer"
<[EMAIL PROTECTED]> said:
> >I read it but there doesn't seem to be anything that contradicts this
> >solution. Alan suggests a 'silent' ffwd/rew, basically like you would
> >lift the pickup from an old-fashioned record and place it somewhere
> >
>In fact, I'd just like to say thank you to everyone for all your hard
>work. I'm running a nightly from 2 weeks ago on Vista. And it's working
>perfectly, very stable and I'm loving all the improvements.
>
Here here. I think SC7 is very good - very stable. I can recommend upgrading.
However, pl
>I agree that using a proportional bar would be much better than what we have
>now.
I disagree.
The way it works at the moment is better, because the user is in total control,
deciding when to accelerate. An automatic acceleration in fast-forward speed
is unpredictable (esp. without audio feed
>I read it but there doesn't seem to be anything that contradicts this
>solution. Alan suggests a 'silent' ffwd/rew, basically like you would
>lift the pickup from an old-fashioned record and place it somewhere
>else. No sound while moving, just a visual indicator should surely make
>this a lot
+1
And I was told to lengthen my reply.
I totally agree to this. Love my SB.
The box, proning on top of my televison, interferes with my TV antenna
signal. So... I listen more to music, and watch less television. :)
--
muvee69
--
seanadams;250676 Wrote:
> For most (all?) formats we should be able to just seek proportionally to
> the designated point in the _source_ file, and just re-start transcoding
> from there.
>
> The main reason transcoding does not work with the current ffw/rw
> architecture is because of complexit
Toby Dickenson;250649 Wrote:
> awy wrote:
>
> > I would be pleased to get feedback on these proposals and additional
> or
> > alternative suggestions.
>
> It all looks good.
>
> Is there any possibility this could be made to work for transcoded
> files
> too? If only to avoid the inconsistency
awy wrote:
> I would be pleased to get feedback on these proposals and additional or
> alternative suggestions.
It all looks good.
Is there any possibility this could be made to work for transcoded files
too? If only to avoid the inconsistency in behaviour.
I guess the implementation would invo
Another Vote for Alan's suggestions! I too find the current solution
unpredictable and therefore do not use it.
And if the multi-SB synch in SC7 that Alan worked on is anything to go
by it will be brilliantly implemented.
In fact, I'd just like to say thank you to everyone for all your hard
work
Check out what song scanner plugin does. It delivers nice solution to
the problem (IMNSHO).
K
--
slimkid
The sound stage will open up, bass will tighten and the imaging will
improve. DVD performance will also increase substantially.
cbemoore;250534 Wrote:
> Before going any further, I'd recommend reading Sean Adams' explanation
> of the current FFWD/REW design. He makes some very interesting points!
>
> http://forums.slimdevices.com/showthread.php?t=36446
Most may not be aware that Alan was the person recently responsible
cbemoore wrote:
> Before going any further, I'd recommend reading Sean Adams' explanation
> of the current FFWD/REW design. He makes some very interesting points!
>
> http://forums.slimdevices.com/showthread.php?t=36446
>
I read it but there doesn't seem to be anything that contradicts this
so
Before going any further, I'd recommend reading Sean Adams' explanation
of the current FFWD/REW design. He makes some very interesting points!
http://forums.slimdevices.com/showthread.php?t=36446
--
cbemoore
cbemoore's Pr
awy wrote:
> I am looking at changing, I hope improving, the design and
> implementation of the fast-forward (FFW) and rewind (REW)
> functionality in SqueezeCentre. There is considerable dissatisfaction
> with the current implementation, although I suspect that it probably
> meets the needs of so
(This is a repost of a message from the Developer
forum as this topic probably deserves a wider audience.)
I am looking at changing, I hope improving, the design and
implementation of the fast-forward (FFW) and rewind (REW)
functionality in SqueezeCentre. There is considerable dissatisfaction
wi
64 matches
Mail list logo
