RE: Ladies and Gentlemen, we have frozen!
One thing you can test, is the manual ;-) Are there: Missing/incorrect keys? Missing features or explanations Features documented that don't exist on your platform Sections that you don't understand... Spelling or Grammatical errors And that applies to any of the platforms, not just Ondio Mark |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Pieter Bos |Sent: 03 April 2006 20:35 |To: rockbox-dev@cool.haxx.se |Cc: [EMAIL PROTECTED] |Subject: Re: Ladies and Gentlemen, we have frozen! | | |"Christi Alice Scarborough" <[EMAIL PROTECTED]> |wrote in message news:[EMAIL PROTECTED] |> In the mean time, we need volunteers to test Rockbox on Archos |> Players, Recorders, Ondios and Iriver H1xx and H3xx. Please report |> missing functionality and bugs at |> http://www.rockbox.org/tracker/index.php?type=2. The list of things |> that ought to work in Rockbox on these platforms is at |> http://www.rockbox.org/twiki/bin/view/Main/ReleaseTodo. Please help |> us to make the best Rockbox we can. |> | |I'll certainly help by installing newest versions on my Ondio. |The ReleaseTodo page could be improved by showing what |features work on which targets though, if the purpose of that |page is to tell use what we should try and look for :) | |regards, | |Pieter | | |
Re: Ladies and Gentlemen, we have frozen!
"Christi Alice Scarborough" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > In the mean time, we need volunteers to test Rockbox on Archos Players, > Recorders, Ondios and Iriver H1xx and H3xx. Please report missing > functionality and bugs at > http://www.rockbox.org/tracker/index.php?type=2. The list of things > that ought to work in Rockbox on these platforms is at > http://www.rockbox.org/twiki/bin/view/Main/ReleaseTodo. Please help us > to make the best Rockbox we can. > I'll certainly help by installing newest versions on my Ondio. The ReleaseTodo page could be improved by showing what features work on which targets though, if the purpose of that page is to tell use what we should try and look for :) regards, Pieter
Re: Wavpack skip bug - fixed?
gl wrote:
BTW, can anybody take a look at this (below & see the rest of this
thread)? Hardeep?
To recap, this in relation to missing the beginning of Wavpack tracks
when skipping files or dirs manually. Setting both values to zero is
working for me so far with no ill effects.
Yes, that looks like the proper fix. Q_AUDIO_PLAY take an offset as
argument, anything else ought to be a bug. But I do wonder what Miika
thought when he made those changes (they are fairly recent)... ;)
Magnus
The problem call comes from audio_thread(), line 1817:
if (ev.id == SYS_TIMEOUT && play_pending)
{
ev.id = Q_AUDIO_PLAY;
ev.data = (bool *)1;
}
The offset (ev.data) is set to 1 here - anybody know what's going on?
If I set it to 0, tracks play properly (but note it doesn't fix the
skip crossfading after all).
There's another similarly strange call in initiate_dir_change(), line
1791,
queue_post(&audio_queue, Q_AUDIO_PLAY, (bool *)true);
And sure enough, if you skip a directory, the start of the first track
is missing again.
Why are these setting boolean values (especially as true compiles to 1
and not -1, which the code would at least treat differently)?? Are
these remnants from an old version of the code or am I missing something?
Re: Ladies and Gentlemen, we have frozen!
I'll volunteer for helping, I have a Recorder V1. I'm Peter200lx in the Forums. On 4/3/06, Christi Alice Scarborough <[EMAIL PROTECTED]> wrote: > I'm pleased to announce that we've reached a milestone on the road to a > release of Rockbox 3.0. As of this morning, CVS is now officially in > feature freeze. This means that until the release of Rockbox 3.0, the > only patches accepted into CVS will be those which fix an existing bug > in the proposed release platforms (Archos and Iriver). > > The freeze is expected to last a month with the proposed release date > for Rockbox 3.0 being 1st May 2006. After the release, we will be > accepting new features into CVS again. In the mean time, please feel > free to use the patch tracker to keep track of potential new > functionality for Rockbox. > > Commiters, it would be very helpful if you can include a bug database > reference in CVS commits during this period so we can track progress > towards release. > > In the mean time, we need volunteers to test Rockbox on Archos Players, > Recorders, Ondios and Iriver H1xx and H3xx. Please report missing > functionality and bugs at > http://www.rockbox.org/tracker/index.php?type=2. The list of things > that ought to work in Rockbox on these platforms is at > http://www.rockbox.org/twiki/bin/view/Main/ReleaseTodo. Please help us > to make the best Rockbox we can. > > Thanks, > > Christi > >
Re: Wavpack skip bug - fixed?
BTW, can anybody take a look at this (below & see the rest of this thread)?
Hardeep?
To recap, this in relation to missing the beginning of Wavpack tracks when
skipping files or dirs manually. Setting both values to zero is working for
me so far with no ill effects.
--
gl
- Original Message -
From: "gl" <[EMAIL PROTECTED]>
To: "Rockbox development"
Sent: Friday, March 31, 2006 3:46 PM
Subject: Re: Wavpack skip bug - fixed?
The problem call comes from audio_thread(), line 1817:
if (ev.id == SYS_TIMEOUT && play_pending)
{
ev.id = Q_AUDIO_PLAY;
ev.data = (bool *)1;
}
The offset (ev.data) is set to 1 here - anybody know what's going on?
If I set it to 0, tracks play properly (but note it doesn't fix the skip
crossfading after all).
There's another similarly strange call in initiate_dir_change(), line
1791,
queue_post(&audio_queue, Q_AUDIO_PLAY, (bool *)true);
And sure enough, if you skip a directory, the start of the first track is
missing again.
Why are these setting boolean values (especially as true compiles to 1 and
not -1, which the code would at least treat differently)?? Are these
remnants from an old version of the code or am I missing something?
--
gl
Ladies and Gentlemen, we have frozen!
I'm pleased to announce that we've reached a milestone on the road to a release of Rockbox 3.0. As of this morning, CVS is now officially in feature freeze. This means that until the release of Rockbox 3.0, the only patches accepted into CVS will be those which fix an existing bug in the proposed release platforms (Archos and Iriver). The freeze is expected to last a month with the proposed release date for Rockbox 3.0 being 1st May 2006. After the release, we will be accepting new features into CVS again. In the mean time, please feel free to use the patch tracker to keep track of potential new functionality for Rockbox. Commiters, it would be very helpful if you can include a bug database reference in CVS commits during this period so we can track progress towards release. In the mean time, we need volunteers to test Rockbox on Archos Players, Recorders, Ondios and Iriver H1xx and H3xx. Please report missing functionality and bugs at http://www.rockbox.org/tracker/index.php?type=2. The list of things that ought to work in Rockbox on these platforms is at http://www.rockbox.org/twiki/bin/view/Main/ReleaseTodo. Please help us to make the best Rockbox we can. Thanks, Christi
Re: Suspicious code in playlist.c?
[EMAIL PROTECTED] wrote: 1. This code in playlist.c look suspicious: playlist->amount is only tested against playlist->max_playlist_size AFTER playlist_>amount is used as an array index. (Lines 510, 513, 515.) 2. And, if amount >= max_playlist_size, the function returns without calling queue_post. Shouldn't we be able to use playlists up to and including max_playlist_size? Instead we can only use playlists up to max_playlist_size - 1. 3. Shouldn't we either be calling queue_post or reverting playlist_info's state if we have to end because max_playlist_size has been reached? Thanks for investigating. I've committed fixes for all these problems. -Hardeep
Re: Track skipping & shuffling cause hard lockups.
Thanks for investigating. I've committed the fix. Just saw it, cheers. -- gl
Re: Track skipping & shuffling cause hard lockups.
gl wrote: OK, the lockup is specific to having _both_ shuffle and repeat-shuffle enabled. It's caused by this call in playlist.c, line 2431: playlist_start(0, 0); It seems extraneous and causes a deadlock in the playback queue system - removing it fixes the problem. Thanks for investigating. I've committed the fix. Speaking of repeat-shuffle, I assumed this would work even without shuffle on, ie. on the first pass the list plays alphabetically, but on subsequent passes it's randomised. However the code only uses it if shuffle is also enabled. I think this should be changed. I was thinking of removing that check as well. If no one disagrees, I will do so. -Hardeep
Re: Track skipping & shuffling cause hard lockups.
If nobody cracks it in the next day or so I'll take a shot at it (I shuffle on the move all the time, and a hard lock isn't nice). If I can't figure it I'll bug it. OK, the lockup is specific to having _both_ shuffle and repeat-shuffle enabled. It's caused by this call in playlist.c, line 2431: playlist_start(0, 0); It seems extraneous and causes a deadlock in the playback queue system - removing it fixes the problem. Anybody want to commit this? We all know my patches aren't any good here... Speaking of repeat-shuffle, I assumed this would work even without shuffle on, ie. on the first pass the list plays alphabetically, but on subsequent passes it's randomised. However the code only uses it if shuffle is also enabled. I think this should be changed. -- gl
