Rockbox

I would expect that if the target uses any threads of its own and didn't define TARGET_EXTRA_THREADS, there won't be enough free thread slots to allocate.

TIP: Check System->Debug->View OS Stacks and there needs to be three thread slots free for mpegplayer to work.

Immediately after bootup, only slots 15 and 16 are available.
How can this be resolved?

I thought I already define TARGET_EXTRA_THREADS but perhaps I put the wrong value. I'll check that asap.

If I wanted to build my own, how would I define this? I only know how to build a clean build at this stage.

I ran SVN update, edited thread.h to say TARGET_EXTRA_THREADS 1, executed the make file and replaced the rockbox.sansa file. There are still only 2 threads open. What have I missed?
Running Crunchbang Statler (Debian Squeeze based)

Edit the the main config file from /firmware/export/config, not thread.h

Just apply this? :)

I have set the number of extra threads to 1 in the SVN. This should solve the issue.

Thanks! Video playback no longer fails, confirmed 3 open threads under OS Stacks.
However, playback does not work correctly.

Settings:
Limit FPS: Yes (default)
Skip frames: Yes (default)
Upon opening the video, nothing is displayed. When pausing (and thus bringing up the seek bar) there is video in a small section of the top right corner of the screen (in landscape orientation) and the video updates every second on the second (as the counter advances, and I'd imagine the region is redrawn)
After bringing up the seek bar and it disappearing, the section of video becomes slightly larger but does not advance.
Indicated frame rate is around 25.

Settings
Limit FPS: No
Skip frames: No
Exactly the same thing, except the indicated FPS is around 20.

With both scenarios, audio works perfectly. Video is refreshed if Show FPS is on (so if anything on the screen is being re-drawn)
The size of the segment of video shown varies. Same video files as mentioned above were used. More of the 128x62 video could be seen than the 320x240.

Screendump did not work correctly while playing video. I can take a picture tomorrow with a digital camera if that would help.

Sorry if I appear to be asking stupid questions or providing excessive detail. I'm pretty new to this.
Thanks for the tip regarding SVN. I'm learning quickly :)

The problems comes from the implementation of yuv blitting. For historical reason, lcd_blit_yuv bypasses the software framebuffer and writes directly into the hardware framebuffer, but since the fuze+ needs to sends command to update the screen, these are never sent and the screen is never refreshed on yuv blitting. There are several ways to solve that, one would be to implement lcd yuv blitting instead of using the generic implementation. I'm working on using the hardware to do the yuv conversion, that would solve the problem and be much more efficient.

d32891f should have fixed the isssue with mpegplayer. I don't have any videos at hand but at least it fixes yuv blitting which I believe is the culprit. Can you try again ?

d684858 works perfectly :)
Video is smooth and as it should be.
More of a matter of interest than a problem, but if showfps is enabled, the number isn't shown but flashes once every second - regardless of whether the seek bar is visible. Only when the video is paused does the fps reading stay on the screen.
I'm not complaining, I'm ecstatic that video now works. Just thought I'd mention it, since it seems strange.
Thank you very much for your work on this!

The FPS is supposed to be drawn (just copied, not completely rendered) on every frame after the video updates though perhaps things are working differently here.

this appears to be fixed, can I close this?

Yeah, you can close.
Only remaining issue is the FPS not being drawn correctly, but thats a minor thing and does not belong on this task.
Thanks!