My opinions on release 3.0

[robin0800]

Sansa C200 should not be released until The OF is not needed for things like charging and transfering files. In fact Any target like this should in my opinion not be released. Rockbox should perform all basic functions before a version 3.0 release for these targets.

[saratoga]

Sansa C200 should not be released until The OF is not needed for things like charging and transfering files.

This was discussed on IRC and most people seemed to think it wasn't a big deal, since using the OF for file transfer works smoothly enough on the Sansas.  Though I think there was some thought that automatic rebooting back into the OF should be fixed if at all possible.

[robin0800]

Well I think both charging and file transfers should be in rockbox.
It is perhaps true the are both not far away.
So really I would rather wait until these are done before release three, at least this would keep the pressure on. It might also help in support as you could tout release three as a replacement and any thing less still needing the OF.

[Llorean]

It's "3.0" not "Release three" as there have been more than two previous releases.

Please, it's really not that hard to just accept that it's a specific version number and use it.

The USB problems in all likelihood will not be resolved by the 3.0 release date. Delaying the release will not happen, as we all know what happens if we fall into that trap. Either the release coordinator will decide using the OF USB mode is acceptable, or he won't. That's about all there is to it. If it's decided to be unacceptable, 3.0 won't include those targets that must use it. But this seems very unlikely to happen, so you'll frankly just have to accept that.

[Zardoz]

Just a question - maybe two..... three...also maybe a little off-topic. Why is there any importance placed on a release 3.0? Is it a means of applying a little pressure, cleaning out unnecessary code, making the whole thing tidier and so on? If this is an open source project, and not a commercial release, what does it matter if there are bugs and whatnot?

[Llorean]

The whole point of "release" versions is that we can say "here is a copy of the code, in a known state, that should work reasonably well if you don't wish to simply download current development builds."

It also takes pressure *off* the developers in terms of the current development builds, because if something breaks there's always the release version for users to make use of until it's fixed.

Currently people don't seem to be in the clear that when using "current builds" they're testers, more than users, as it's an actively developed piece of code, and they're getting the most recent, and not always stable, developments.

Bugs in 3.0 are okay if they're documented, and if they do not prevent normal use of the player. Depending on the OF's USB can be documented, and it certainly doesn't prevent use of the player.

[Zardoz]

Thanks for the explanation. 

(Something I often wondered - is there a 'repository' of all rockbox builds/revisions somewhere?)

I've always understood that I'm using untested (and free) software and think there should be NOO pressure on developers to do jot if they don't wanna! But would it be feasible to fix revisions/builds known to be 'least buggy' on the repository rather than strive for a 'release'?

[Llorean]

Builds are only kept around for one month, but an entire revision history of the entire project is kept so it's possible at any time to re-create any historical build.

More or less, though, the idea of "taking a reasonably working build and patching it up" is the idea we're going to be following for this release. Specifically playback seems to have settled down to a reasonable state, so we're hoping the "reasonably working build" will be "Rockbox as it is when the time comes for the feature freeze" but if it's gotten bad again by that point, we'll consider builds from a slightly earlier time period.

[Zardoz]

I guess that's exactly what you described a release as, and that takes some work and collating of benches, feedback, realtime data, code etc (ok now I understand it's a big undertaking. I just don't know why you guys and girls don't do less - this is FREE!! But I understand the feeling of doing a good job and so on.) Playback has been completely flawless for me since I started using the [more-evil-than-microsoft] ipod 80GB with rockbox. Only issues I had (and I risk deletion here) were with playlists, making and saving large playlists, displaying them etc

I love rockbox and couldn't care for release.
keep the faith.
Z

[Llorean]

There were some issues with playback occasionally seemingly randomly going out of order, and that was one of the two big showstoppers we decided needed to be addressed before 3.0. It got addressed, and so did the other one (which was a similar significant playback issue) and that's why we're going ahead with it now.

There's still quite a few bugs here and there (possibly even a lot) but we feel that we can write up a "Known Issues" and release with them, so that there's a 3.0 version for people to fall back on, rather than never having a stable-ish version.

In fact the current plan is to designate a release every 3 months, if at all possible.

[Strife89]

About the only bug that bothers me is the delay there is on decoding .MP3s if I quickly switch tracks, i.e., before they're buffered well. I wound up adjusting my habits to conform, but I'd still love to see it improved.

[NicolasP]

About the only bug that bothers me is the delay there is on decoding .MP3s if I quickly switch tracks, i.e., before they're buffered well. I wound up adjusting my habits to conform, but I'd still love to see it improved.

What do you mean by "decoding"? Do you mean the displaying of the track information has a delay, or is the delay before audio actually starts playing?
In both cases, enabling dircache helps to an extent. Keep in mind that not everything can be buffered and that a hard drive has to be spun up.

[robin0800]

and that a hard drive has to be spun up

A C250 is flash based and probably not part of his problem

[Strife89]

Do you mean the displaying of the track information has a delay, or is the delay before audio actually starts playing?

The latter. I've been using r17979 for about a week now, but I haven't seen any notes about changes in the playback code (and yes, I know that other code can affect playback performance) (and yes, I will update).

In both cases, enabling dircache helps to an extent. Keep in mind that not everything can be buffered and that a hard drive has to be spun up.

On a whim, I turned that on yesterday. Although

A C250 is flash based

I still noticed an improvement. My guess is that part of the problem might have to do with my enormous MUSIC folder on the internal memory: the MUSIC folder has no subdirectories, just 500+ files (I looked at the list limits, just to be sure).

Sansa C200 should not be released until The OF is not needed for things like charging and transfering files.

I'd settle for a good USB driver. The OF now takes ten minutes to refresh its database when my memory card is inserted (I can remove it for charging) (I have dozens of cihptunes and MIDIs; that's mostly why it takes so long, and why it refreshes on EVERY OF boot and after every USB "session").

[tmcarson1]

Sansa C200 should not be released until The OF is not needed for things like charging and transfering files. In fact Any target like this should in my opinion not be released. Rockbox should perform all basic functions before a version 3.0 release for these targets.

I didn't even realize there was  a version 3.0 already, glad to hear =)

How do I determine if I have the latest stable release?  The version screen on my player says:
r18064-080715

Thanks for your reply.