headers
tracker | 3 Feb 2007 00:00
Favicon

Open bugs in Rockbox

Flyspray contains 150 open bugs:

2 years 291 days old: Corrupt files using time split feature
6 comments, 0 files: http://www.rockbox.org/tracker/2147

1 years 134 days old: Rewinding at end of song confuses playback 
9 comments, 0 files: http://www.rockbox.org/tracker/2687

343 days old: iPod going into USB mode when using the wall charger.
4 comments, 0 files: http://www.rockbox.org/tracker/4724

342 days old: text viewer setting saving not working on ipods
2 comments, 0 files: http://www.rockbox.org/tracker/4729

339 days old: USB Bootloader Mode not working properly
20 comments, 0 files: http://www.rockbox.org/tracker/4753

336 days old: Random resets when playing while plugged in (USB)
2 comments, 0 files: http://www.rockbox.org/tracker/4762

311 days old: Ipod Video constant ticking and scrollwheel noise bug
4 comments, 0 files: http://www.rockbox.org/tracker/4937

309 days old: convbdf segfaults on very large fonts
7 comments, 2 files: http://www.rockbox.org/tracker/4955

308 days old: chessbox gets frozen on hold
2 comments, 0 files: http://www.rockbox.org/tracker/4977

300 days old: Bookmarking does not work in connection with Tag Cache Database
(Continue reading)

Permalink | Reply | 0 comments |
headers
tracker | 3 Feb 2007 00:00
Favicon

Open patches in Rockbox

Flyspray contains 314 open patches:

3 years 336 days old: Edit ID3 Tags
23 comments, 9 files: http://www.rockbox.org/tracker/1008

3 years 167 days old: Sleep mode after n tracks (Request FS#826)
2 comments, 1 files: http://www.rockbox.org/tracker/1642

3 years 166 days old: Extended volume fade options
10 comments, 2 files: http://www.rockbox.org/tracker/1645

3 years 162 days old: Enhanced menus + MDB patch (for recorder)
2 comments, 1 files: http://www.rockbox.org/tracker/1656

3 years 148 days old: beep when battery low
8 comments, 1 files: http://www.rockbox.org/tracker/1682

3 years 125 days old: Increase/decrease volume from .cfg file
0 comments, 1 files: http://www.rockbox.org/tracker/1720

3 years 125 days old: Increase/decrease volume from cfg file
0 comments, 1 files: http://www.rockbox.org/tracker/1721

3 years 43 days old: Fade out until sleep mode
0 comments, 1 files: http://www.rockbox.org/tracker/1887

3 years 19 days old: Beginnings of F2/F3 configuration
6 comments, 2 files: http://www.rockbox.org/tracker/1924

3 years 15 days old: honor the rva2/xrva/xrv frame
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Gordon | 4 Feb 2007 13:46
Picon
Gravatar

Re: next step for the settings changes - the menus

OK,
I was alot lazier than expecting last week, but the first step is
ready for inclusion (attached .patch)

I know you dont like the heavy use of macros but I think these can be
exceptions, without them there will be plenty of places for copy/paste
errors and other bad stuff.

now, before I forget, I just did a compile for the fm rec, the binary
size increases about about 1Kb, but this is expected because only the
main menu uses the new system (it bassicaly does exactly the same as
before, but with more code.)

The plan is to fix the wiki page
(http://www.rockbox.org/twiki/bin/view/Main/SettingsRecode) to explain
how interested people can help, then commit this, then work through
the menu, 1 submenu at a time to convert the existing code to this new
system. This will mean moving code out of apps/*_menu.c to
apps/menus/*_menu.c in a neat manner so adding items later or
rearranging items will be simple.

Doing it this way instead of in 1 big hit means it will probably take
the same amount of time (a few weeks if its only me doing it), but
bugs will be found more quickly and there is more chance others' will
chip in.

any objections or comments?
(if there isnt I'll nag everyone in IRC in the next few days before I
commit.. not doing that without an ok)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jonathan Gordon | 4 Feb 2007 14:05
Picon
Gravatar

Re: next step for the settings changes - the menus

On 04/02/07, Jonathan Gordon <jdgordy <at> gmail.com> wrote:
> OK,
> I was alot lazier than expecting last week, but the first step is
> ready for inclusion (attached .patch)
>
> I know you dont like the heavy use of macros but I think these can be
> exceptions, without them there will be plenty of places for copy/paste
> errors and other bad stuff.
>
> now, before I forget, I just did a compile for the fm rec, the binary
> size increases about about 1Kb, but this is expected because only the
> main menu uses the new system (it bassicaly does exactly the same as
> before, but with more code.)
>
> The plan is to fix the wiki page
> (http://www.rockbox.org/twiki/bin/view/Main/SettingsRecode) to explain
> how interested people can help, then commit this, then work through
> the menu, 1 submenu at a time to convert the existing code to this new
> system. This will mean moving code out of apps/*_menu.c to
> apps/menus/*_menu.c in a neat manner so adding items later or
> rearranging items will be simple.
>
> Doing it this way instead of in 1 big hit means it will probably take
> the same amount of time (a few weeks if its only me doing it), but
> bugs will be found more quickly and there is more chance others' will
> chip in.
>
> any objections or comments?
> (if there isnt I'll nag everyone in IRC in the next few days before I
> commit.. not doing that without an ok)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tomasz Malesinski | 4 Feb 2007 20:01
Picon
Picon

Re: Profiling the codecs

> I notice that on mpa 5.7 and on vorbis a whopping 7.3% of CPU time is
> spent in switch_thread.  Can you by chance try turning off priority
> scheduling and see how that impacts those percentages?  That seems like
> an awefully high scheduling overhead.

I tried switching off HAVE_PRIORITY_SCHEDULING in
firmware/export/config.h and it doesn't make a big difference. With
mp3 playing, the number of cycles spent in switch_thread decreased
from 14.5M to 13.5M. When I slowed down the audio DMA in the emulator,
so that the codec thread had to wait once in a while for space in the
audio buffer, the number of cycles spent in switch_thread increased to
36M with no priority scheduling and 41M with it.

My benchmark is simply the boot process and playing 5s of audio (it
happens automaticaly, I play the song instead of calling browse_root
in apps/main.c). I haven't traced where most of switch_thread calls
come from.

--

-- 
Tomek Malesinski
Permalink | Reply | 0 comments |
headers
Jonathan Gordon | 5 Feb 2007 06:09
Picon
Gravatar

Re: next step for the settings changes - the menus

attached is the new patch against svn. all builds compile fine.
Attachment (changes.patch): text/x-patch, 34 KiB
Permalink | Reply | 1 comment |
headers
Jonathan Gordon | 5 Feb 2007 07:07
Picon
Gravatar

Re: next step for the settings changes - the menus

sorry, forgot to svn add the apps/menus folder.

I cleaned up menus/main_menu.c a bit and added stub files in menus/ to
help get the conversion effort moving a bit faster.
Attachment (changes.patch): text/x-patch, 50 KiB
Permalink | Reply | 0 comments |
headers
Jacob Rau | 6 Feb 2007 18:26
Picon

Possibility of a 3GP video player

Hey all,

I know that you guys shoot down anyone who has a feature request on this 
list, and for good reason; this is a hobby project. So, don't look at 
this as a feature request, rather, an idea for improvement on something 
that's already being developed.

I recently encoded some video for my friend's phone. It plays 3GP files. 
The file I encoded was about 3 minutes long; about 3-4 MB. That's really 
good; the video looked fine and there was not one artifact in the sound 
or video. And the encoder for 3GP is part of mplayer, I believe; I have 
a freeware tool that is just a frontend for a bunch of free encoders 
that could do 3GP. And it is already used in embedded devices.

So why not? Does it sound like 3GP would be a good format? I understand 
MPEGs can get huge fast, but at a little over a meg a minute in 3GP 
format, quite a few full-length movies could be stored on the nano. I'd 
be willing to help, but I know almost nothing about the current video 
setup in Rockbox. And I got more confused when I saw previously written 
plugins that used the frame buffer; I don't understand the format.

Just wanted to mention it.

Jacob

--

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.28/672 - Release Date: 2/6/2007 10:22 AM
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Stenberg | 8 Feb 2007 08:37
Favicon

Re: jdgordon: r12227 - in trunk/apps: . menus recorder

On Thu, 8 Feb 2007, mailer <at> svn.rockbox.org wrote:

To me, this move is a wrong move. This introduces a complicated system that 
fewer people will understand/change and that will be bad for us in the long 
run.

Some nits in the actual code follows:

> /* -----------------------------------------------------------------
>  * vim: et sw=4 ts=8 sts=4 tw=78
>  */

I realize you didn't add this chunk, but I personally think we should not have 
stuff like this in source files.

> +    if (m->flags&MENU_HAS_DESC)
> +        menu_callback= m->callback_and_desc->menu_callback;
> +    else menu_callback = m->menu_callback;

This latest line is normally written on two separate lines in other Rockbox 
code, and I would appriciate if we stayed with that source code style. You use 
this same style in multiple places.

> +                            DEBUGF("%x\n",setting->flags);
> +                            if (setting->flags&F_INT_SETTING)
> +                            {DEBUGF("boo");

These DEBUGF() calls seem like leftovers that should be removed.

> +#ifdef CONFIG_TUNER
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jonathan Gordon | 8 Feb 2007 09:42
Picon
Gravatar

Re: jdgordon: r12227 - in trunk/apps: . menus recorder

On 08/02/07, Daniel Stenberg <daniel <at> rockbox.org> wrote:
> On Thu, 8 Feb 2007, mailer <at> svn.rockbox.org wrote:
>
> To me, this move is a wrong move. This introduces a complicated system that
> fewer people will understand/change and that will be bad for us in the long
> run.
>
> Some nits in the actual code follows:
>
> > /* -----------------------------------------------------------------
> >  * vim: et sw=4 ts=8 sts=4 tw=78
> >  */
>
> I realize you didn't add this chunk, but I personally think we should not have
> stuff like this in source files.
>
> > +    if (m->flags&MENU_HAS_DESC)
> > +        menu_callback= m->callback_and_desc->menu_callback;
> > +    else menu_callback = m->menu_callback;
>
> This latest line is normally written on two separate lines in other Rockbox
> code, and I would appriciate if we stayed with that source code style. You use
> this same style in multiple places.
>
> > +                            DEBUGF("%x\n",setting->flags);
> > +                            if (setting->flags&F_INT_SETTING)
> > +                            {DEBUGF("boo");
>
> These DEBUGF() calls seem like leftovers that should be removed.
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane