I think i have tracked down my Rockbox crashing bug...
... i believe its related to the fact that Rockbox doesnt check a file exists in a playlist before trying to play it. If you generate a playlist of the form ./folder/song.mp3 ./folder2/song2.mp3 it crashes on the 'loading' screen every time. If you change it to /music/folder/song.mp3 /music/folder2/song.mp3 form it works. I understand that the first format is invalid (caused by a 'find' accident, fixed by sed), but its ungraceful. I think Rockbox should check a file exists before trying to play it, and display an error if not, rather than crashing. The reason this is interesting to me is because I have been getting lots of crashes even with a valid playlist (while the loading message is displayed). I believe this is because I delete a lot of tracks after listening to them (podcasts). I reckon Rockbox is trying to play the now-dead song, and causing it to crash via the same mechanism as described above. It certainly continues to play the track after ive deleted it. Am i on the right track (so to speak!) ??? g
My vote for BMP cache removal
Hi I'm not at all fond of the BMP cache thing that was added the other day. I think it bloats code, is complex and is the wrong answer to the minor performance problems we might have when loading WPS configs with large amounts of pics. I'd rather see us move towards using a single BMP with chop instructions for what to use. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: My vote for BMP cache removal
Thom Johansen wrote: I think it should be taken out as soon as possible. It's flawed in the sense that it can't possibly detect whether the cache is invalid without destroying the entire purpose of the cache in the first place. We've already had a user coming in asking questions about why his WPS wasn't updating when it should, and more will come. It certainly is confusing. While wee on the subject, the image tag method currently used is deeply unsatisfactory, since it arbitrarily limits the number of images. I'm vaguely in favour of moving to a top left/bottom right co-ordinate based syntax for specifying which part of the image to display once we have single image. Thoughts? Christi
Re: About Rockbox utility, for Christi
Alessio Lenzi wrote: I am a Rockbox blind user , i found your post dealing with your utility to simplify Rockbox installation and upgrade reading this list. I immediately installed the program, i think it's really useful. Since last december have you released any other version? Im afraid the project's been on hold as I'm rather busy preparing to move house at the moment. Things should calm down in a month and a half or so, and then I can hopefully devote more time to it. As i already translate Rockbox for italian, i'd like, if possible, do the same with yours. What do you think about that? Waiting for your answer Certainly the infrastructure for translations is built into wxWidgets. Its probably better to wait until rbutil is a bit more stable though, when I porpose to implement full localisation support. Christi
Re: My vote for BMP cache removal
On 31.01.2006, Daniel Stenberg wrote: Hi I'm not at all fond of the BMP cache thing that was added the other day. I think it bloats code, is complex and is the wrong answer to the minor performance problems we might have when loading WPS configs with large amounts of pics. I'd rather see us move towards using a single BMP with chop instructions for what to use. I'm with you here. There seems to be an additional area for gaining performance - it was reported that WPS loading on iPod is way faster than on iriver. The CPU speed is similar, so I can only imagine 2 possible causes: (1) The iriver ATA driver needs optimising. (2) The endian swap in fat.c. Regards, Jens
Re: My vote for BMP cache removal
There seems to be an additional area for gaining performance - it was reported that WPS loading on iPod is way faster than on iriver. The CPU speed is similar, so I can only imagine 2 possible causes: (1) The iriver ATA driver needs optimising. (2) The endian swap in fat.c. My measurements show that the current ATA driver gives us roughly 5.2Mbytes/s transfers at 124Mhz. A simple asm optimization gave 7.8Mbytes/s for burst-aligned transfers. Linus
