thomsens;220410 Wrote:
Without better integration, songscanner certainly isn't a fix - it's a
workaround at best. If it could be tied to the FF button then maybe
you are getting cloer.
Check out this thread... KDF explains how to map Songscanner to the
FFWD and RW remote buttons, as well as
...and I believe Sean committed to reviewing both SongScanner and
Fishbone and integrating if appropriate.
I think we should let him and Dean do that. It seems like a pretty
good route forwards.
--
DynamicalSystem
slimkid;218199 Wrote:
Anyhow, would you care to share for which products/manufacturers you
have worked so far - I mean, I could use some avoidance references.
Many manuals have the legal disclaimer at the front that the
specifications are subject to change at any time without notice.
IANAL,
seanadams;218214 Wrote:
Wow - talk about taking a quote out of context! I think it was pretty
clear that TireLegs was referring to the difference between a user's
manual and an advertisement (the subject at hand), not saying that a
manual shouldn't be accurate.
The sentence was taken out of
slimkid;218394 Wrote:
The sentence was taken out of context for shortness and clarity. It is
marked with '...' for the purpose of pointing that fact out. Taking it
out of context didn't change the meaning and the point of the original
text. If you disagree, please, quote the original post
slimkid;218394 Wrote:
And again. What is the purpose of the manual if it isn't accurate?
Of course a manual should be accurate (and as far as I know, every one
I have written was at the time it was issued). The critical point you
are missing is that the purpose of a manual is to instruct users
Like I said a few pages earlier, this problem has been fixed by the
plugins SongScanner/Looper and the clickable progress bar in the
Fishbone skin. Hooray for the plugin programmers, and hooray for Sean
for having the wisdom and foresight to make this an open source
platform! And Sean seems to be
amey01;216917 Wrote:
Sorry - no. Sure, the manual SHOULD reflect the way the product works,
but it did not match the way the product worked when I purchased my
Squeezebox.
By all means fix the manual so this problem doesn't get raised by
future purchasers, but that doesn't eliminate Slim
TiredLegs;218190 Wrote:
...Manufacturers are not obligated to make products behave the way their
manuals say...
Really? So, what then, is the purpose of the manual?
Anyhow, would you care to share for which products/manufacturers you
have worked so far - I mean, I could use some avoidance
TiredLegs;215673 Wrote:
It's actually the other way around, i.e., the manual should reflect the
way the product operates. So if the manual is wrong, it needs
correction.
Sorry - no. Sure, the manual SHOULD reflect the way the product works,
but it did not match the way the product worked
Pat Farrell;216028 Wrote:
thomsens wrote:
Pat Farrell;216023 Wrote:
A modern PC has a gigabyte of RAM, which can hold a complete CD,
uncompressed, in memory. Serious PCs for either Vista or development
have two or three gig.
If it's really a matter of inadequate hw, then my
seanadams;216027 Wrote:
Not at all. You still have to _get_ all that data to the player. And you
still have to be able to generate some audible rendition of it as you
scan through the compressed stream. And you still have several of the
other issues I originally mentioned, such as
thomsens wrote:
To suggest based on a limited sample of this forum combined with your
opinion that a feature is not required is silly.
This forum is where customers who have bought SqueezeBoxes and
Transporters talk among themselves. The forums in total are for people
interested in
What is this thread about? There's a perfectly good FF/RW function
called songscanner, and a jump-to-a-point-in-the-track function in the
fishbone skin. IMO both should be incorporated into the main SS builds
as they are far superior to the standard FF/RW feature (which I think we
all agree is
opaqueice;216150 Wrote:
What is this thread about? There's a perfectly good FF/RW function
called songscanner, and a jump-to-a-point-in-the-track function in the
fishbone skin. IMO both should be incorporated into the main SS builds
as they are far superior to the standard FF/RW feature
Pat Farrell;216147 Wrote:
thomsens wrote:
To suggest based on a limited sample of this forum combined with
your
opinion that a feature is not required is silly.
This forum is where customers who have bought SqueezeBoxes and
Transporters talk among themselves. The forums in total are
seanadams;216027 Wrote:
Not at all. You still have to _get_ all that data to the player. And you
still have to be able to generate some audible rendition of it as you
scan through the compressed stream. And you still have several of the
other issues I originally mentioned, such as
thomsens;216015 Wrote:
I'd still be interested as to why MCE seems to be able to handle what
appears on the surface to be a much more challenging, but similar task.
The typical PC has substantially more RAM to devote to buffering
decoded frames than a Squeezebox.
Throw enough RAM at the
snarlydwarf wrote:
The typical PC has substantially more RAM to devote to buffering
decoded frames than a Squeezebox.
Right
A modern PC has a gigabyte of RAM, which can hold a complete CD,
uncompressed, in memory. Serious PCs for either Vista or development
have two or three gig.
Any modern
snarlydwarf;216019 Wrote:
The typical PC has substantially more RAM to devote to buffering decoded
frames than a Squeezebox.
Throw enough RAM at the problem and it's trivial.
My understanding was that the problem was technical implementation, not
architectural decisions made on the hw.
thomsens wrote:
Pat Farrell;216023 Wrote:
A modern PC has a gigabyte of RAM, which can hold a complete CD,
uncompressed, in memory. Serious PCs for either Vista or development
have two or three gig.
If it's really a matter of inadequate hw, then my original assertion
that initial
snarlydwarf;216019 Wrote:
Throw enough RAM at the problem and it's trivial.
Not at all. You still have to _get_ all that data to the player. And
you still have to be able to generate some audible rendition of it as
you scan through the compressed stream. And you still have several of
the
amey01;213645 Wrote:
I'm not insisting that FF/REW (or anything else) can be done - BUT I
am insisting that the Squeezebox will do what the manual says it will
do.
It's actually the other way around, i.e., the manual should reflect the
way the product operates. So if the manual is wrong, it
For me the main reason for the functionality is to be able to move
through a podcast or radio programme to get the part I want to listen
to and using the current implementation on the SB makes it very hit or
miss. Fortunately it is more possible to do so via the web UI
implementation of AlienBBC
Ok, have had a shiny new Transporter up and running for all of 8 hours
and am very happy with sound quality and most aspects of the interface
(server could be better, but hey...)
However, have to say that behaviour of FF/RWD is at best useless, and
IS a very annoying issue in my opinion.
I have
seanadams;214132 Wrote:
Which DVR is it by the way? Are the files plain old mpegs or transport
streams, or are they in some kind of special container format? If the
latter, it is possible that they have some additional data generated
during the encoding process to facilitate scanning. Would
Just curious...why do DVRs have no problem with a workable version of
this feature? I would think that would be more challenging than audio
only. Mine does it fine while streaming from my NAS over the network.
--
thomsens
thomsens;214126 Wrote:
Just curious...why do DVRs have no problem with a workable version of
this feature? I would think that would be more challenging than audio
only. Mine does it fine while streaming from my NAS over the network.
Hmmm well one thing video has going for it is that there
Which DVR is it by the way? Are the files plain old mpegs or transport
streams, or are they in some kind of special container format? If the
latter, it is possible that they have some additional data generated
during the encoding process to facilitate scanning. Would be
interesting to do a packet
Thanks and I will be trying the SongSkipper plugin - I have downloaded
it - all I need is some time to install it on my SlimServer.
--
amey01
amey01's Profile: http://forums.slimdevices.com/member.php?userid=11274
View
seanadams;211343 Wrote:
(spinning a new thread from
http://forums.slimdevices.com/showpost.php?p=211286postcount=45)
This is about the same as complaining that you can't scratch on a CD
player the same way you could on last century's phonograph... except
that in this case it is a bit
thomsens;212715 Wrote:
People who think that it should work like a CD player should just get
over it. We just need a solution to move around songs easily. Any
reasonable solution is probably ok.
I'm not going to respond to this snide stuff. Point is that you are
arguing from
seanadams;212721 Wrote:
I articulated as best I could why it is not feasible. If you have a
better idea I am all ears, but I don't think it is reasonable to insist
that it can be done without having any idea how.
I just want to state what a fantastic product the Squeezebox is. Let
that be
amey01;213645 Wrote:
all I need is a way to move around songs
So until slimdevices improves this, you should try the SongScanner
plugin, seems to be working great for me, provides just this
functionality. I'm having some trouble remapping it to the ff/rw button
hold, but this should be
bephillips;213113 Wrote:
I'd like: A clickable progress bar in the browser UI, that skips to the
position in the track clicked on.
This basic functionality already exists in Fishbone (though the
resolution is a bit coarse).
--
azinck3
I'm still in 6.5, no clicking in the progress bar yet for me. I'm glad
to hear that it's coming.
--
bephillips
More than 33159 songs on 3246 albums by 2029 artists.
SlimServer Version: 6.5.3 - 12361
Mac OS X 10.4.10 (8R218) - EN - utf8
Perl Version: 5.8.6 darwin-thread-multi-2level
MySQL
bephillips;213230 Wrote:
I'm still in 6.5, no clicking in the progress bar yet for me. I'm glad
to hear that it's coming.
Are you using the Fishbone skin in 6.5.2 or 6.5.0? The click on the
progress bar is certainly working for me with 6.5.2, and I'm sure it's
worked like that in the past
Siduhe;213235 Wrote:
Are you using the Fishbone skin in 6.5.2 or 6.5.0? The click on the
progress bar is certainly working for me with 6.5.2, and I'm sure it's
worked like that in the past for 6.5.1 at least. You do need to use
Fishbone however.
As azinck3 says, it's not precisely
Sweet, there it is.
All the info in my signature is up to date. Upgraded from 6.5.1 fairly
recently.
I thought I had clicked up there a few times and had no response, but I
now think that was just because of the coarseness of the control. KDF
himself told me it was a 7.0 feature. Very cool.
Thanks for the very clear explanation, Sean. And as this is the first
I've replied to one of your posts, thanks so much for the Slimserver
SB3. Best tech purchase since I don't know when. After a year, my
extensive collection is almost all organized and tagged up. It's been a
huge project, but
seanadams;212683 Wrote:
I agree, but the fact that is does not work the same as a CD player has
been the overwhelming complaint WRT scanning. That is the point I was
trying to answer, and in particular, why it is silly to assert that it
should be a trivial feature on the basis that a 20-yr
thomsens;212715 Wrote:
If you wanted to, you could have designed it day one to support it.
Perhaps that would involved more complex buffering and memory required
to do it...and maybe GE instead of 10/100. But, you chose not to and
now the product has a deficiency. If I knew how to code it
thomsens;212715 Wrote:
People who think that it should work like a CD player should just get
over it. We just need a solution to move around songs easily. Any
reasonable solution is probably ok.
Funny thing is, the way that most CD players work doesn't do the trick
for me. I typically want
cliveb;212722 Wrote:
On the other hand, the Song Scanner plugin goes a long way to doing
what I want. So for me, skipping around on a Squeezebox is *better*
than most CD players. If you've not yet tried it out, give it a go.
I have not tried it but I will give it a go. I would
Sorry folks...I'm not clear on why anyone accepts this answer. The
implementation is broken. There are times when I want to skip back or
skip forward in a song. Sometimes to hear a part over again.
Sometimes to get to my favorite part of the song (especially long
classical pieces). Right
thomsens;212680 Wrote:
I think the key is addressing the capability and not past
implementations. I'm surprised so much effort was spent discussing the
way CD players did it. Who cares?
I agree, but the fact that is does not work the same as a CD player has
been the overwhelming
Maybe a mechanism that allows you to ff/rr n seconds or n% _without_
audible feedback would make people happy (or _happier_, anyway ). It
would at least be (somewhat) feasible. Now that people are somewhat
used to dealing with video in this manner, it might just work.
I could see how such a
Remember Sean used to not have a boss (not in the corporate sense,
anyway). His boss was the customer. Now he probably reports to a
Logitech VP, and was probably asked the same question in his boss's
staff meeting last week! :o)
--
Zten
Zten;212695 Wrote:
Remember Sean used to not have a boss (not in the corporate sense,
anyway). His boss was the customer. Now he probably reports to a
Logitech VP, and was probably asked the same question in his boss's
staff meeting last week! :o)
Rght my boss cares about the fast
OK, I dont mind how the current fast fwd is implemented, confused me at
first but once I figured it out, no probs.
But when players are synced, fast fwd doesnt seem to work at all. And
when switching on another player, the currently playing track restarts
from the beginning.
This combined with
Thanks to Sean for the detailed explanation as to why ff/rw can't be
implemented as it is in a CD player. However, add me to the list of
people that thinks ff/rw should be done differently than it is
currently. The current implementation essentially doesn't work (at
least not for me -- I use
flipflip;211357 Wrote:
the need for jumping forward and backward in a stream is critical to
me. I listen to lots of podcasts (downloaded separately [1]) and audio
books (e.g. language courses). And in this case I need to skip
backwards a few seconds all the time to listen to a sentence I did
(spinning a new thread from
http://forums.slimdevices.com/showpost.php?p=211286postcount=45)
amey01;211286 Wrote:
Before we start adding even more features to the Squeezebox, let's just
get what we've got working - and working properly.
FF and REWIND that works as well (not better - just
Hi Sean
thanks for your (as usual) helpful commentary.
I'd just like to chip in with some thoughts: you've described well why
a scanning feature is not likely to be forthcoming, and also the
difficulty with transcoded formats.
Having read many of the same threads as you obviously have, I think
I hadn't really considered the complexity of it, but it is indeed
obvious when you stop and think (or just read that post!).
Count this as one vote for 'please ignore FF/RW forever'. I never use
it. The only conceivable use for it I can see is where you have ripped
an album as a whole. There
Sean, thanks for the detailed explanation. I am aware of the technical
reasons why scanning (like on a CD player) would not be practical to
implement. And I am not expecting from SD to implement it.
However, the need for jumping forward and backward in a stream is
critical to me. I listen to
seanadams wrote:
This is about the same as complaining that you can't scratch on a CD
player the same way you could on last century's phonograph...
Hi Sean,
Thanks for your great summary of how ff/rw work differently between CD and
tape deck. It is clear that the designers of both of those
Not that this was ever a big issue for me, but using Moose one can skip
ahead or go back in a song just by clicking on the timeline.
--
ezkcdude
There are 10 kind of people in the world - those who understand binary
and those who don't.
EZ DIY AUDIO DESIGNS:
'*Site*'
ezkcdude;211386 Wrote:
Not that this was ever a big issue for me, but using Moose one can skip
ahead or go back in a song just by clicking on the timeline.
Can you explain please?
Chris
--
krzys
krzys's Profile:
ceejay;211344 Wrote:
Having read many of the same threads as you obviously have, I think this
leaves at least one problematic area still to discuss - the UI.
I agree. I think the button _should_ behave like a CD player and I'm
not aware of any reason why we could not do that. Also,
displaying
krzys;211389 Wrote:
Can you explain please?
Chris
http://forums.slimdevices.com/showthread.php?t=35468highlight=Moose
--
ceejay
ceejay's Profile: http://forums.slimdevices.com/member.php?userid=148
View this thread:
seanadams wrote:
I agree. I think the button _should_ behave like a CD player and I'm
not aware of any reason why we could not do that. Also,
displaying a large progress bar or time line indicating the new seek
position might be helpful.
+1 on the separate buttons
The glyph convention seems
Hi Sean:
Let me premise this question by stating I love your product and I
understand it is not technically posible, so the ff/rw issue is moot,
but I found the Most of us have little or no need for scanning
comment interesting. How do you know this to be true? Was there any
market study done to
I agree that FF/RW isn't quite as smooth as a CD player and you have to
have a native format going to squeezebox. But the overloaded buttons is
at least half the issue that folks are complaining about. I actually
expected the bumpy behavior of FF to be worse and thought it was quite
good (getting
64 matches
Mail list logo
