collett_steve@hotmail.com wrote:

Try to understand that devs don`t put in ugly, half baked solutions when they know full well that it will create a backlash in the consumer/user community, and develpers/companies (even the ones at Roku) are not masochists.

You seem to be conveniently ignoring the fact that not having a "half-baked" solution has already caused a backlash in the user community. So Roku can't avoid that.

I also don't buy your argument in the first place. If Roku did implement FF/REW that only worked on a subset of files/servers, what have the people for whom it won't work lost? Answer - nothing, so I reject the notion that those people would have anything legitimate to complain about*.

Many of us are aware that it is perfectly technically feasible to implement at least a basic form of in-track searching. Maybe a precise 2 x, 4 x, 6 x, etc. realtime FF/REW is very hard, but approximate 10 sec, 20 sec, 30 sec or whatever skips should really not be that hard to implement, for the vast majority of files and servers (only WMA DRM would have a problem if I understand correctly). It is about time Roku delivered this basic functionality.

* Assuming that any format/servers for which the function is not implemented, it is because it would be technically impossible.

HarryDymond wrote:

I also don't buy your argument in the first place. If Roku did implement FF/REW that only worked on a subset of files/servers, what have the people for whom it won't work lost? Answer - nothing, so I reject the notion that those people would have anything legitimate to complain about*.

When customers buy Roku products, that pays for software development which goes into future firmware releases. When that software development, paid for by all Roku`s customers only benefits a subset of the installed user base, things clearly become unfair. Thats my point.

HarryDymond wrote:

approximate 10 sec, 20 sec, 30 sec or whatever skips should really not be that hard to implement

Have you performed an in depth technical assessment for implementing fast forward? If I had to guess, I`d say that you have not. I`d also guess that Roku have already performed such an assessment, and (based on the age of this thread) probably some time ago. Its really not fair at all to the Roku guys, for customers to make huge assumptions about the feasabiltiy of implementing specific features on Roku products.

collett_steve@hotmail.com wrote:

When customers buy Roku products, that pays for software development which goes into future firmware releases. When that software development, paid for by all Roku`s customers only benefits a subset of the installed user base, things clearly become unfair.

What nonsense. I've bought a M1001, before the SoundBridge Radio came out, and before the BrightSign came out. The idea that I have any sort of reason to be upset that whatever profit was made on my M1001 went into the development of products that I'm not interested in is laughable.

collett_steve@hotmail.com wrote:

HarryDymond wrote:

approximate 10 sec, 20 sec, 30 sec or whatever skips should really not be that hard to implement

Have you performed an in depth technical assessment for implementing fast forward? If I had to guess, I`d say that you have not.

No, indeed I have not. But I don't feel I need to and am 100% confident that relative to the level of effort of writing the SoundBridge's original firmware, implementing FF/REW "skips" is trivial. Pause any track playing from an iTunes server, and leave it for several hours, then come back and press play. The Roku has to request the server starts streaming the track again from a specific point, and the server and the SoundBridge pull this off without a hitch. Much of the necessary capability to implement FF/REW skips is therefore demonstrably already present in the current firmware.

HarryDymond wrote:

The idea that I have any sort of reason to be upset that whatever profit was made on my M1001 went into the development of products that I'm not interested in is laughable.

I think you miss my point. Developing significant new features which everyone wants, but which are not acessible to all because of their own choice of server or codec is neither sensible nor acceptable.

I`d like FF too. Everyone would. My money is just as good as yours. Why should you get FF because you use MP3 and I am denied that feature because I use a transcoded file format?

HarryDymond wrote:

Much of the necessary capability to implement FF/REW skips is therefore demonstrably already present in the current firmware.

Nobody has ever said it was impossible to implement, Harry. Most things are possible if you throw enough resource at them. However, given that this thread is nearly three years old now, its highly likely that Roku have looked carefully are the options for implementing FF, and when balanced with all the other enhancements they have on their list, the options available for fast forward either

A) don`t look good in a cost/benefit analysis, or
B) In Roku`s opinion simply just look too ugly to implement effectively.

My money is on B. But like you guys I`m just a dumb consumer who can only speculate on things he doesn`t fully understand.

The only thing thats laughable here is the premise that Roku have withheld a highly desirable ehancement for three years which is easy to implement (according to the self proclaimed experts in the forums), presumably for the sole reason of annoying their loyal customers and denying themselves a little bit of extra revenue.

Give it up guys, just give it up.

As an engineer I find myself often wondering who the heck had the final word in a product's design. Nowadays you find so many half baked devices on the market but I refuse to believe that the deficits always stem from the design teem not seeing things through and engineering not seeing features through.

Since I just recently acquired a NAS server, the first thing that I found missing after being able to play the first MP3 was.... tada... fast forward/backward. It's a feature I often use when playing MP3s via Winamp to quickly scan through a file.

I, too, spent quite some time trying to find information about the device before I bought it.. I specifically was looking for Shoutcast playback and it's not quite that easy to find this information - I figure being a useful product feature, the specifics would be in the data sheet but that was not the case.

mscox_au's link to Microsoft's WMconnect spec actually intrigued me, so I spent the next half hour looking for some specs on DNLA and uPNP. And, I finally ended up on a part of the uPNP site that had some specs. I believe these specs are applicable in the case of the roku. If you turn your attention to the AVTransport specification, it lists various commands devices can use to get information about media, and to transmit / receive media. Amongst other things we have play, pause, stop, and... seek. Thus, it is my belief that it's not a fundamental lack of standards but merely a question of whether you're willing to adapt the software to support this use case.

Thinking back to my first DivX enabled device, it had no fast forward/fast reverse either (except for DVDs obviously).. and it had a lot of trouble with certain codec features, couldn't handle a large variety of codecs, etc. Nowadays, devices play almost anything you can throw at them.
Back in the day when DivX got started, seeking was a problem.. people wanted it, and not even software players could handle it. I think back then I heard the not feasible or too difficult argument then as well. Then came filters which permitted some seeking but showed black frames until the next keyframe. Nowadays it's unthinkable that playback wouldn't start at the precise point you specify and there are players that support frame accurate seeking.

So, it just comes down on how willing you are to spend the required development time to send the appropriate command and reinitialize the audio decoder so that audio playback can continue.

I'm wondering, are there any competing devices that support ff/fr?

Logitech's Squeezebox has FF/RW for most content, but it's a little different of a product... as the whole device is driven by the Slimserver software running on a host system. (Think of the device as a "dumb (audio) terminal.")

I don't think Microsoft's own Xbox 360 has FF/RW while streaming audio over UPnP AV... (It does when used via Media Center, though.)

Well, "competing" the Squeezebox certainly not is, as its not comparable in terms of technology.

I also use a Pinnacle Showcenter 200, which is comparable from the technological point of view.

It serves as a UPnP client as well as another propietary streaming protocol. There are various server programs available, and while it does not matter which one you actually use, they all enable you to browse through the contents in one way or another, and also to listen to web-radio, and mp3s.

And also it allows you to seek forward and backwards. This works not only for audio files, but also for video in various codecs. Some codecs work better than others, and some highly sophisticated, high-bitrate codecs make the showcenter choke a little, but its there, at least.

Netgear EVA8000 Media Streamer supports FF without any software or PC needed (streaming media from a NAS box).

PSP with TwonkyVision (which can run on a NAS box, hence no PC required), supports FF.

I got a Zyxel DMA-1000 recently, and it, too supports FF/RW from my TwonkyMedia server - and not only for audio but video as well. And it even costs less than the Soundbridge 1001...

So, from a technical perspective it's clearly feasible - and so we wait for it to be implemented.

humba wrote:

I got a Zyxel DMA-1000 recently, and it, too supports FF/RW from my TwonkyMedia server - and not only for audio but video as well. And it even costs less than the Soundbridge 1001...

So, from a technical perspective it's clearly feasible - and so we wait for it to be implemented.

Don`t fall into the trap of thinking you have all the facts. Comparing apples and oranges doesn`t work.

Still no progress on this basic feature?

Sounds like every other major streamer provides this. Not good differentiation: "let's not provide it as it might annoy of x% our customers that wouldn't get it".

Oh and my new toy (as yet yesterday) has it

I know there has been a lot of discussion of the technical hurdles needed to overcome to get this functionality to work, but the simple fact of the matter is that in order to attract a wider audience you need to have this functionality.
I like this product in a lot of ways, but this was really a shocker to me when I bought it and is the main reason I am reticent to recommend it or buy another or give it as a gift.

-Greg

I would like to add my voice of support for the request of the ability to skip through tracks. I admit I haven't read through every post of this very long thread, but I get the gist that this is a non-trivial task. I think for the majority of short 3 or 4 minute tracks, the lack of the feature is not so much a problem, but when you get into long tracks e.g. classical or speech based podcasts, it would be good to have a seek function.
I would actually be happy with a memory recall function to return to a single point in a track at a future date - this is slightly different, but I imagine slightly simpler to implement? I'm not clear on where the crossover between the media server and the Roku control comes in, but since Roku recommend Firefly so much, it strikes me that the development of these features needs to be a joint effort between the teams. How do other streaming players deal with this - e.g. realaudio player? The BBC website uses RA for its replay features, and the embedded player they use allows skipping forward and back in fixed intervals rather than a CD player-like FF/RW control - could something like this be done?

From :: http://forums.rokulabs.com/posting.php? ... te&p=68434

RokuMike wrote:

Just to confirm a bit more: when we set the software schedule recently for 2.7 and beyond, I read through that entire feature request forum. Took me all day. I compiled the most-requested features into a list, and that list was used in weighing the priorities of features to be developed (along with other factors). We don't necessarily post a lot in there, but we do read it.

Back in April 2005 (thats 2 and a half years ago!) on this same thread::

RokuMike wrote:

Folks, seriously, we get the message. We understand it's a desirable feature. It's on our list of feature enhancements. Okay?

Make your own judgements.

p.s. yes, I do know that Mike is no longer with Roku!

This really should be a PHPBB poll. By my rough count most posters here want it vs one.