Our tick timer eats CPU even when the app is closed and music is stopped. To fix this, I added a tick_pause() and tick_resume() to kernel-android.c, to be called from java when appropriate.

I've figured out where to call pause, but the current location of resume is inadequate. The app wakes up to a black screen.

A clue, anyone?

The OF ide_power_enable routine sets some GPIO _ENABLE bits to zero when enabling power and sets them to 1 when disabling power. This makes a difference of about 1 in 4066_ISTAT ( FS#9728 ) on my 30 gig iPod, which probably means saving about 0.75 mA. But if 1 is enable, why does enabling pins save power?

Here is a preliminary patch for TV out on a 5th generation iPod. Play a BMP file and TV out will activate. NTSC is the default. If the file has 576 lines, the output will be in PAL. The image stays until another is loaded or TV output is disabled via the debug menu..

The following formats ought to work:
720×480, 24 bpp for NTSC
720×576, 24 bpp for PAL
Many programs including Windows Paint and ImageMagick convert can write such files. Other resolutions and bit depths may work. For example WPS background screens display properly but other WPS bitmaps don’t.

Known issues:
- More work needs to be done to integrate this with Rockbox. No, you cannot view the Rockbox interface, JPEGs or mpegplayer output yet.
- When the LCD is updated, there is a temporary disturbance on TV output
- http://en.wikipedia.org/wiki/Macrovision#Analog_copy_prevention is enabled. Yes, the hardware can disable it, but I haven’t figured out how to do that yet.
- The original firmware probably outputs images differently. It can load programs into the BCM which perform decoding there, and that is probably faster.

With my 5th generation iPod, if I connect USB while the hard drive is spinning, I often get full speed mode instead of high speed mode. This testing is with 00b8563, but I’ve observed the same problem in the past. Here’s the relevant part of Linux 3.8.0-21-generic dmesg output:

[26644.712035] usb 2-2: new high-speed USB device number 18 using ehci-pci
[26644.904471] usb 2-2: device descriptor read/all, error -71
[26644.965905] ehci-pci 0000:00:1d.7: port 2 reset error -110
[26644.967780] ehci-pci 0000:00:1d.7: port 2 reset error -110
[26644.968004] ehci-pci 0000:00:1d.7: port 2 reset error -110
[26644.971577] ehci-pci 0000:00:1d.7: port 2 reset error -110
[26644.973440] ehci-pci 0000:00:1d.7: port 2 reset error -110
[26644.973459] hub 2-0:1.0: hub_port_status failed (err = -32)
[26645.176048] hub 2-0:1.0: unable to enumerate USB device on port 2
[26645.428038] usb 6-2: new full-speed USB device number 8 using uhci_hcd
[26645.979070] usb 6-2: not running at top speed; connect to a high speed hub
[26646.009069] usb 6-2: New USB device found, idVendor=05ac, idProduct=1209
[26646.009076] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[26646.009080] usb 6-2: Product: Rockbox media player
[26646.009083] usb 6-2: Manufacturer: Rockbox.org
[26646.009087] usb 6-2: SerialNumber: 100000000000A270014B32BEB
[26646.024242] scsi21 : usb-storage 6-2:1.0
[26647.038109] scsi 21:0:0:0: Direct-Access TOSHIBA MK3008GAL BU11 PQ: 0 ANSI: 4
(I’ve removed the remaining USB storage messages because they don’t seem relevant)

If the hard drive is not spinning, I get high speed mode. However, there is a disconnect and the device is detected twice:

[27356.784126] usb 6-2: USB disconnect, device number 9
[27371.208044] usb 2-2: new high-speed USB device number 24 using ehci-pci
[27371.347053] usb 2-2: New USB device found, idVendor=05ac, idProduct=1209
[27371.347058] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[27371.347062] usb 2-2: Product: Rockbox media player
[27371.347065] usb 2-2: Manufacturer: Rockbox.org
[27371.347069] usb 2-2: SerialNumber: 100000000000A270014B32BEB
[27373.079038] scsi25 : usb-storage 2-2:1.0
[27373.337244] usb 2-2: USB disconnect, device number 24
[27373.640029] usb 2-2: new high-speed USB device number 25 using ehci-pci
[27373.779220] usb 2-2: New USB device found, idVendor=05ac, idProduct=1209
[27373.779226] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[27373.779229] usb 2-2: Product: Rockbox media player
[27373.779233] usb 2-2: Manufacturer: Rockbox.org
[27373.779236] usb 2-2: SerialNumber: 100000000000A270014B32BEB
[27373.820382] scsi26 : usb-storage 2-2:1.0
[27374.823266] scsi 26:0:0:0: Direct-Access TOSHIBA MK3008GAL BU11 PQ: 0 ANSI: 4
(Again, I’ve removed the remaining USB storage messages because they don’t seem relevant)

I get the same behaviour regarding high speed vs. full speed mode in Windows 7, but I’m not aware of Windows reporting other USB errors anywhere.

I was sometimes having USB difficulties that seemed to be due to contact oxidization or dust from not using the dock connector in a long time, but I don’t think that’s the cause here.

I’m attaching USB traces from WireShark using Linux usbmon. In both cases I removed all the USB mass storage stuff after get max lun because it seems irrelevant and increases file size a lot. When the result is full speed, something goes wrong after the set address response. When the result is high speed, something goes wrong after the set configuration request. In both cases the first sign of trouble is an interrupt from the USB hub.

This is on a Gigabyte GA-P35-DS3R rev V1.0 motherboard with Intel P35 + ICH9R chipset.

This patch implements HAVE_LCD_SHUTDOWN functionality for Photo and Color iPods. It is in response to issue 2 in http://forums.rockbox.org/index.php?topic=20994 : “2. The LCD screen on the iPod is not cleared properly when I shut down rockbox. I see 1-2 horizontal lines remain on the screen (which do fade after a minute or so). Nothing is wrong with my IPod’s LCD screen as I did not experience this with Apple’s Firmware”

It seems the Color iPod can have 4 different LCDs. They’re detected via two GPIO bits in lcd-color_nano.c. Types 0 and 2 are the old LCD with an unknown controller and they use the same init, shutdown and update procedures, and they are reported as 0. Types 1 and 3 are similar to HD66789R. They have different init and shutdown procedures but they share the same update procedure. Both 1 and 3 were reported as 1 earlier.

To see what LCD type you have, from the main menu go to System → Debug (Keep Out) → View HW Info and then see the number after “LCD type:”.

This patch has only been tested with LCD type 3 so far.

I am submitting this as a patch because I feel it is not a significant bug. Theoretically, the DC voltage that’s left can degrade the LCD, but the line fades quickly and no negative after-effects were reported.

I would like to also add LCD initialization code and develop HAVE_LCD_SLEEP functionality.

If LCD_SLEEP is put on the backlight queue immediatly after BACKLIGHT_ON, the LCD will go to sleep immediately after the backlight turns on. On the 5G iPod, the next backlight_on() call will wake it, but on some other targets it might not wake again.

For example, consider the following sequence of events:
1) backlight_on() is called, putting BACKLIGHT_ON on the queue
2) The LCD sleep timeout from the previous backlight shutoff puts LCD_SLEEP on the queue
3) BACKLIGHT_ON is received and the backlight is turned on. The call of backlight_lcd_sleep_countdown(false) does nothing about the LCD_SLEEP on the queue.
5) The LCD_SLEEP is received, putting the LCD to sleep again.

This patch causes LCD_SLEEP to be ignored by backlight_thread() when the backlight is on. It also removes a workaround from 5G iPod LCD sleep code.

This issue is theoretical and very improbable. I am not able to trigger this bug in r20774.

While examining disk performance with  FS#9708 , I found one album where the disk stayed spinning with no activity for 5 s longer when using PIO. This is repeatable with that particular album. With the downloaded r19739-090109 build, this did not happen with the default settings but it started happening as soon as I enabled dircache. Prolonging the disk timeout prolongs the extra sleeping time.

Experimentation with shows that the storage_sleep() part of fill_buffer() (in apps/buffering.c) is executed early in the buffering and it is not executed at the end. With another album where spindown happens properly, ata_sleep() is called twice. Note that ata_sleep() just sets last_disk_activity, and sleep happens over half a second later if there is no disk activity during that period and last_user_activity has timed out.

I think this is a race condition based on how dircache and transfer rates change things. I wonder if it is related to  FS#9541 .

The data mentioned is located at http://spreadsheets.google.com/ccc?key=pkeRcfM0sg949P3a5EYXtew and the delayed spindown is seen in the EP7 PIO test. In that data, also note how sectors written are 5, 10 or 15, with differences between different tests with the same album.

I have a 30GB 5th generation iPod, but I expect this issue affects all SW-codec players.

I noticed that when filling the buffer my Video iPod (32MB RAM) does noticeable seeks at semi-regular intervals even if reading from a single non-fragmented file. It seems this is due to having to read the next FAT sector. In firmware/drivers/fat.c there is a FAT cache but no read-ahead of the FAT.

I created fat_preload( struct fat_file *file, long sectorcount ) in firmware/drivers/fat.c to preload the FAT cache. In firmware/common/file.c I created file_preloadfat(int fd, size_t count) because calling a fat_ function directly would be too much of a kludge. I use file_preloadfat in apps/buffering.c just before filling the buffer.

This got rid of that regular seeking and it seems to it can remove about two seconds from the time needed to fill the buffer when reading a single non-fragmented file. Currently the code is quite simple and unintelligent. Fragmentation or other activity can overwrite the pre-loaded FAT sectors in the cache, and in such cases the pre-load leads to needless extra reads. More work is probably needed before this can be included in Rockbox.

Currently this patch is for SW-codec only. I think file_preloadfat could be called from HW-codec buffering code also, though few seeks would be prevented with 2MB of RAM. This patch is also probably useless with flash storage.

“First Keypress Enables Backlight Only” doesn’t work on the 5G iPod. For example, if that’s enabled, the backlight is off and I press next track while at the WPS, Rockbox will go to the next track.

It seems like clickwheel event(s) generated when I touch the wheel turn on the backlight. When the button is pressed, the backlight is already considered to be on and the button press performs its usual action. If I carefully hold my finger still on the clickwheel, let the backlight fade, and then carefully press a button without moving my finger on the clickwheel, I am able to turn on the backlight without causing anything else to happen.

I don’t know what to do about this. Requiring a physical button press might be annoying. Removing this option on affected targets might be okay, because it’s easy to turn on the backlight by touching the clickwheel (and that doesn’t seem to cause anything else to happen). Another possibility is to require more or specific wheel events.

I set player type to iPod 5G because that’s all I have, but I expect this problem also exists on other clickwheel iPods. This problem exists on r20079 and r20033.

To reproduce, ensure car adapter mode is enabled, start playback, and leave the now playing screen. If the charger isn't connected, connect it now. Then, disconnect the charger, causing a car adapter mode pause. Some parts of the now playing screen will overwrite the current screen. I see this in file view, main menu and settings. The main menu is quickly redrawn and back to normal, but the file view is only redrawn after I do something. Now, reconnect the charger, which causes a car adapter mode unpause after a short delay. The same thing happens.

I've seen this on:
- 5G iPod using Firewire power, running 3.10RC and r31106
- Archos Recorder V2 using charger, running 3.10RC and r31106

Edit: The same thing happens with headphone plug-in unpause (but not headphone unplug pause). I expect the problem also happens when using BUTTON_MULTIMEDIA_PLAYPAUSE, but I did not test that.

The problem is due to the pause_action() and unpause_action() calls in apps/misc.c. The second parameter is "bool updatewps". It is true in all cases except headphone unplug pause. I don't know why it's false in that particular case.

The second parameter probably shouldn't be there. The WPS should simply update itself if it is currently displayed.

Setting the Idle Poweroff setting seems to work just fine initially because the player ceases to respond to any input. However, when you push the power button back up to turn it on, the screen lights up and says “Shutting down…” for a few seconds before actually powering off. You then have to push the power button back on to turn it on proper.

The following patches will allow someone running openBSD to run ipodpatcher. This is my first pass at these patches, so they cannot be integrated without some problems.

A few outstanding questions remain:

1) should I use /dev/sd0c or /dev/rsd0c?

2) why do byteorder(3) functions exist in fat32format.c?

3) how do the developers want to handle disk geometry?

I ask the last question because my patch overwrites the existing ioctl with what works for openBSD, rather than separate it out. And the patch doesn't fully use what is available in struct disklabel. I plan to re-write this one.

The fat32format.diff comments out byteorder(3) functions. The ipodio-posix.diff converts the file to openBSD disk geometry. The ipodpatcher.diff corrects the device used.

I have only tested the patches above for ipodpatcher on iPod nano 1st gen.

The Case Game

Here is a variant of Deal or No Deal for Rockbox.

26 cases contain random amounts of virtual money. After choosing 1 case for yourself, you open the other cases until the banker makes you an offer to buy your case. If you choose to accept the offer the game ends and you receive that offer as your final score. By declining the offer, you continue to open the remaining cases until the next offer. If you decline all offers you get the amount that was in your case as your final score. If play continues until your down to 1 case plus the case you chose, you are given the option to swap cases.

Gameplay controls:

() While opening cases: pressing UP shows the remaining case amounts.

                      pressing DOWN shows the high scores.

() While deciding on an offer: pressing UP shows the previous offers.

                             pressing DOWN shows the high scores.

This game allows name entries into a high score board.

This game currently only works on color lcd screens (Sansa e200 176×220) or greater.

Apply the patch and place the .bmp files in the “apps/plugins/bitmaps/native/” directory.

Please post results for other platforms as well as comments. I tested the game out on the Gigabeat simulator and it seemed to work well.

I am running 3.4 on a 5.5G iPod modified with a 240gb drive. Rockbox is stock 3.4 with LBA48 added in and the max sector size turned off. The database was working ok on 3.3. Only issue was it took forever to add new files. After upgrading to 3.4 I noticed every time I powered on rockbox would lock up in the menus for up to 10 minutes before functioning normally. So I completely removed the .rockbox dir (including the database files of course) and re-expanded a fresh copy. I then tried to init the db. It runs until it is around ~44k files and 99% and then just sits there. If left alone it will eventually just turn it self off. When I turn it back on it will ask me to init the db again. I have seen it try to commit once or twice but it never takes. I am not really sure how to debug this at this point. Also in the debug disk info area, it things my drive is 131071MB. Under Rockbox Info it says 223GB which is better, but these two things are the same as in 3.3. All my Oggs are converted via a script I wrote from my flacs. I do not believe my flacs have any art, I am not even sure you can store art in a flac tag and even them I don’t think the ogg encoder is transferring them. I ran a tag dump (ogginfo) against my oggs and do not see anything to do with album art. I had 4 files on the device with album art. They were all in a directory with a database.ignore file. So they should not have been noticed. Just in case I removed that directory and rebuilt. It went though 44k files, commited 1-9 and then went back to “scanning” but the disk activity had stopped. Upon reboot it asked me to init the db again.

This is not a patched build. I simply changed the config to include large drive support. This is an issue that needs to be looked at. Please check into it, I will be happy to test any ideas.

There is a bug with the clip zip that when you plug a device in for the first time it doesn't install succesfull the driver and when i unplug it the device crashes and needs a hard reset

So, I have a Clip Zip at the moment. Been using rockbox on it since day 1, and since day one i've always had an issue: during playback, when accessing files from the SD card, the player randomly freezes. It's not always, it's not when accessing the same files or some specific characteristic shared by them, it just appears to be random. When it freezes, the LCD usually still responds to my commands (i can access menus, see the file info, even change song and it will display in the playback screen), but the actual playback doesn't, and I eventually have to hard reset it. I guess it's some kind of SD compatibility issues: I have an 8GB class 4 PNY. I know it's not the own card's problem since it worked perfectly on my Clip+ and does on my Android Cellphone.
I've been updating daily builds for this device at least once a week since I got it, and it happens with every build.

This patch adds does three related things:

- Adds *basic* support for seeking and buffering callbacks so different codecs may manage their buffer space differently
- Extends a few buffering and metadata structures to store information on two files rather than one
- Modifies the Wavpack codec to make use of these features to play back hybrid files with readable correction files losslessly.

This code should not in any way interfere with anything other than the situation where a Wavpack hybrid file is present AND its correction file is readable.

There are several things that need to be done before this patch may be committed:
1. Currently there are two ginormous linear buffers inside the Wavpack codec. They should be replaced with smaller dissimilarly-sized ring buffers.
2. The interspersal of primary and correction file chunks is currently 1/1/1/1. This should probably be more like 1/3/1/3 as that better matches the size rations of a .wv to its .wvc.
3. seek_wavpack needs to support seeking where rebuffering is required.
4. The wavpack hybrid decoding function needs to be modified to decode smaller chunks in a go so that the small ring buffers mentioned above won’t overflow.
5. Gracefully handle the end of a hybrid lossless file (currently it freezes the sim)

The attached patch enables simultaneous buffering of multiple files in a minimally intrusive way. It also contains code to allow the playback of Wavpack hybrid files, both lossy and lossless. In the event that a Wavpack file is not a hybrid file, only original code paths are used. This patch will not affect users who do not use this file type.

How it works:
A handle may now be marked as "chunky". If a handle is so marked, adding a new handle will NOT reserve space in the buffer for the remaining portion of the file. Instead only a small amount of space (currently 2*BUFFERING_DEFAULT_FILECHUNK) is reserved. Additional checking is also added to ensure that buffer_handle will not allow one handle to overflow into another; in the event that a handle's widx would cross into the next handle's header, the handle is "extended" by calling add_handle a second time and linking from the original via file_next. Thus, there are two paths to iterate from a "chunky" handle - the next handle in the buffer layout (h→next), or the next handle containing data from the same file (h→file_next).

Key new methods:
extend_handle: used to create more space for a handle which is active but would overlap its successor if widx were advanced
clean_handle: remove pieces of a handle marked as "invalid", but don't remove the whole handle (as close_handle does)
bufopenchunky: as bufopen, but for a chunky handle
finish_handle: reserves either some or all space for a handle in the buffer
finish_chunky_handles: finishes all chunky handles

What works:
- Playback of lossless hybrid mono and stereo files in the sim functions mostly as expected. Occasional segfaults may occur - these are probably a thread safety issue. Trying on a unicore target would be productive.
- The functionality of any of rockbox other than hybrid wavpack files is not impaired
- Playback on an iPod 5.5G works as well, but is not yet real-time (apparently the hard disk isn't fast enough to buffer both files and keep up with playback, so priority should be given to the .wv file to fix this)
- Buffer space utilization is very efficient, the only waste is caused by the 300 bytes per struct memory_handle created. This could be minimized by only storing ridx, widx, and data in a minimal memory handle and copying the rest of the information to file_next as necessary (this is how open file descriptors are currently handled)

What doesn't work:
- Seeking does not always work, although seeks not requiring a rebuffer are usually OK (even those which must cross into file_next!). Especially unlikely to work is backwards seeking. This is because the Wavpack codec uses approximate seeking, which is fine when you don't have to worry about only one file but falls apart when you need to have the same block in both the wv and wvc files.
- Segmentation faults, especially at the end of very large hybrid files. These are almost all caused by the Wavpack codec in apps/codecs/libwavpack/words.c's response to reading extra 0 bytes. Wavpack does not check the validity of wvbits.ptr before reading from it! When combined with any error at all in the buffering code, or even any corruption in the input files, this leads to a segfault! There are also some issues in the original Rockbox buffering code. For example, in rebuffer_handle, h→next is used without first holding llist_mutex. This is a thread safety issue. On top of these, there's a bounds check I've missed somewhere in apps/buffering.c which can cause buffer corruption.

Most of the Wavpack decoding methods here were ported from those on http://wavpack.com with minor modifications. These files are under the GPL.

This patch contains commented printf statements as partial documentation and in case someone wishes to trace the flow of execution in the simulator.

In the never ending saga of strnatcmp the fix for 10029 sorts as
001
002
01
02

Attached is yet another attempt to get it right.

Sorry for this article. I am a Chiness boy and my english is poor.But i love rockbox.My MP3 Player is onda vx747.I can’t open any .txt files which larger than 1M on the rockbox system.I don’t know how to solve it and i hope some could send me a message if he could solve the problem.My E-mail:724279694@qq.com.Thanks!

I don't know whenever it happens with other versions or not, all I got is Sansa Clipv1 to test with.
My configuration is Initialize once and auto update working.

It seems like the database items got duplicated for unknown reason. I seem to have up to 7 entry's of the same item inside the database. I am not sure what causes it, but that is what I've noticed.
[At first I thought it's a shuffle bug 'till I was going to debug it only to find the database is full of clones]

Sansa Clip v1. Stable version 3.10 [Tracker didn’t let me choose it?]
After playing the item for some time [varies] Rockbox crash and give this error:
Data abort
at 3001913E
FSR 0×8 (domain 0, fault 8)
address 0x7261702D

Using DFKT Minimum Clip theme.

I upgraded my Sansa Fuze V1 (AMSV1) from the current stable release 3.11.2 to Daily build (ad46064-120710). With Rockbox powered on, any attempt to connect USB to my WinXP fails. The USB icon is displayed briefly, followed immediately by the white screen - Undefined Instruction at 0000003C. This is repeatable. Recovery is via a power down.

Note: the USB connection works fine with the current stable release 3.11.2 and this is the first daily build I have tried,

r28528

This adds a bitmap to be shown as the output of the 3 modes of the calculator, similar to the color-codes on the color targets, except that it is a static image for the greyscale targets. Might as well use the screen space for something.

r28529

This patch adds a new library that creates a calculator-like keyboard for easy number entry as an alternative to the on-screen keyboard. A lot of the code for drawing the buttons was taken from the calculator plugin.

Tested on the e200.

3.7.1, r29372, tested on Sansa e270

The idea is that when connected via USB, devices with button/wheel lights will indicate disk activity using the light, similar to a USB flash drive.

This works, sort of.
One real problem has been encountered:
The calls to buttonlight_on() and _off() seem to override the backlight_timeout_plugged setting, preventing the backlight from shutting off when this is enabled.

Sorry, not sure in which build part of this ceased to function, but I think it was just prior to 3.10

In the Clip Sim's I can no longer access the Lock Screen. "H" used to do this for me, as I recall.

Also, the charge values in the Clip Sim's no longer incrementally increase and decrease. The charge values used to go from 0 to 100 and then back down again.

This applies to the Clip Zip Sim as well. I haven't tried the Fuze Sim.

Thanks.

This patch makes the graphic EQ usable in the absolute mode on touchscreen models.
Additionally I made the following changes:

* Add a menu in the touchscreen settings to select the touchscreen mode in the graphic EQ ( because in menus I prefer the grid mode, in the EQ the absolute mode is much better)

* Always try to use the UI_FONT , make the EQ filling the whole screen and add a little margin on the left and right side. In that way it can even used with fingers on a touchscreen (automatic adaption to fill the whole screen should work for all targets with EQ and LCD).

I tested on my Cowon D2 and Iriver H340 to make sure non touchscreen models stil work, both worked perfect.

External/USB adapters are not correctly detected on my Classic 80Gb, this patch detects it so car mode functionality now works, also the iPod is powered-up when USB cable is inserted.

The function power_input_status() returns USB charger when both external and USB chargers are present. It is possible to detect the external adapter when USB cable is plugged but it is necesary to poll the PMU (not IRQ safe), and i think this information is not currently used at all.

The ARM hardware debugger via JTAG spec (EmbeddedICE) specifies a sideband channel for target↔debugger communication called DCC (Debug Communications Channel). openocd, an open-source debugger compatible with the EmbeddedICE standard, supports using this channel for textual debug messages from the target.

The attached patch implements the target side of this channel. Messages can be enabled in openocd using the “target_request debugmsgs enable” command.

WARNING: If -DDEBUG is enabled and there is no hardware debugger attached to drain the DCC buffer, debug() becomes very slow because it has to wait for the writes to time out. However, this is unlikely to happen because -DDEBUG isn’t typically enabled for target builds.

Player = Sansa ClipZip
Rockbox current build :

This patch adds an option to allow the Fastforward/Rewind buttons to be used to skip tracks entirely.

This is an itch of mine that I scratched and am offering up to others if you are interested.

I’ve been using audio lessons to learn Japanese and ran into issues navigating with the normal FF/RW buttons. The acceleration based on track length left me with no sense of time since I don’t keep track of how far I am into my 30 minute long lessons. Simply backing up 5 seconds to catch something I missed was a problem because I’d have to look at what I was doing to see how far I’d ff/rw. Kinda hard when one tick moves 30 seconds too. This is problematic when driving! The existing skip-length feature is really good for this. However, if I use that to skip 5 second increments then I abandon any way of skipping entire tracks. So I re-purposed the FF/RW buttons for skipping tracks and use skip-length for navigating within a track.

I’ve been using this in r27841 for about a week on my Gigabeat, but it seems like it should work for r27942 as well.

It would be useful to change the configure and voice.pl files in order to allow the user to choose also the Loquendo and ViaVoice TTS

Build 575bd89 2016-12-19

Playing the attached zero-duration WMA '_ length 0.0s WMA.wma' causes crash:

Divide by zero at 6008D274
pc:6008D2&4 sp:600CC7DC
bt end

This WMA file was created by Goldwave and plays without crash in Windows Media Player, GoldWave and MediaMonkey.

Zero-length WAV and MP3 files (examples attached) don't cause a crash.

On the latest development iPod Video and ZEN simulators, MP3 and WAV are reported 'failed' and WMA crashes http://i.imgur.com/k3dKaSN.png http://i.imgur.com/CiYnVuH.png

Creative ZEN device build 8fec364f6-170125

Steps:

1 Clear Running Time
2 Shutdown, to ensure Running Time clear takes effect
3 Launch Rockbox
4 Record wall clock time
5 Leave running for a few hours
6 View Running Time and compare with elapsed time on wall clock

Expected: Running Time equal to elapsed time
Observed: Running Time less than elapsed time by 2%

Note: battery_bench.txt times accord with elapsed time.

Creative ZEN simulator build 9d0c0e3-170115
Creative ZEN device build 8fec364f6-170125

Steps:

(Using attached config.cfg)

1 Ensure Settings > Playback Settings > Shuffle is No
2 In Files, move to a list of tracks and press Select
3 In Files, move to a different list of tracks and do long Select > Current playlist > Insert
4 View the playlist e.g. http://i.imgur.com/xR0WMQm.png 5 Set Shuffle Yes and then Shuffle No
6 View the playlist

Expected e.g. https://archive.is/41khH#selection-1007.0-1007.44 , https://archive.is/nypDH#selection-1079.0-1092.0:
Playlist order restored.

Observed: Playlist changed, but not restored - http://i.imgur.com/DBW9wSI.png

Video at https://www.youtube.com/watch?v=2_s27g_FwXg

Creative ZEN simulator build 9d0c0e3-170115
Creative ZEN device build 8fec364f6-170125

Steps:

(Asing attached config.cfg)

1 Set Settings, Playback Settings > Shuffle to Yes
2 In Files, enter a folder of tracks and press Select to play
3 Go up to the folder itself, press long select > Current playlist > Insert Last
4 Press long select > Current playlist > Insert
5 Press long select > Current playlist > Insert
6 Go to Now Playing > Current playlist > View current playlist

Expected: Four copies of the list, all shuffled

Observed: One copy of the list, shuffled, followed by three not shuffled: http://i.imgur.com/Emldcdt.png

Video at https://www.youtube.com/watch?v=KANEkz0zRZ8

The manual offered by Rockbox Utility is not necessarily the version that accords with the installed (or to-be-installed) program.

E.g. select Release 3.13, and the Manual offered is http://download.rockbox.org/manual/rockbox-sansafuze.pdf not http://download.rockbox.org/release/3.13/rockbox-sansafuze-3.13.pdf .

http://www.rockbox.org/irc/log-20140124#15:41:22 says this is a bug. Since the user does reasonably expect a manual to accord with the program, I too think this is a bug. Whether it is a design bug or code bug, I cannot guess.

Note: this task says Operating System: All players but only because the actual player, Sansa Fuze, is not offered. Though this issue may indeed apply to all players.

I have been using Rockbox for almost 2 years now on my X5L together with the remote and I have frequently updated to the current version, so I am familiar with how it works.

I have noticed that after updating to version 20090221, my X5’s remote’s LCD behaves erratically (strange lines being displayed all over, vertically shaky image) right after booting Rockbox, then the display turns off completely after a few seconds. Strangely though, the controls still work and the blue display light comes on when working the controls, but the display is turned off (there is nothing being displayed, as if the player were turned off). If I unplug and reconnect the remote, the remote’s LCD comes on, but soon turns off again. The X5’s main LCD is working just fine.

I thought that my remote was dying on me, but decided to check if it was somehow related to the development of Rockbox. I reverted back one build after another and found that the last build that works OK for my remote is 20090210. So, in all the builds starting with 20090211 (I have thoroughly checked all from 20090211 to 20090225), the remote is practically unusable. I looked at the changes done on that day (http://www.rockbox.org/daily/changelogs/changes-20090211.html), but could not single out the probable cause.

Great software, anyway!

This patch adds a couple more lines to Track Info for Play Count and Rating.
Currently these don’t seem to show up anywhere else.

Tested against r26427 with Fuze v2 and USim.

I've been working on PictureFlow - WPS Integration. I repeatedly had cases where showing a tracklist or playing for certain albums would cause a segfault. I tracked this down to a bug in the track list indexing. It only occurs under certain memory allocation circumstances that doesn't occur as readily with the std build. I have attached here a patch to fix it.

Explanation: the create_track_index requests memory for building a track index. The variable "tracks" references an array descending from the buffer top end. When a reallocation occurs it currently only moves the "tracks" position when a track count > 0. However, in some cases a reallocation occurs before the first track is stored and in that case the "tracks" position gets left in the middle of the track_names data causing corruption and then segfault. I've moved the (track_count > 0) decision so that it only controls moving tracks struct data. The "tracks" offset must happen even when track_count is 0.

This patch fixes the segfault on my Sansa Fuze v2 and in UISim. Tested against r26114.
I would expect the same result in other platforms.

I've also included this bug fix in my PictureFlow - WPS Integration patch until this bug fix gets accepted.

This is a patch meant for Clip+ that adds a “Reflection” setting to
allows choosing if to show a reflection or not. When no reflection is shown the images are moved to bottom of screen allowing for title at top and keeping them in the blue
will work for other devices. I tested it on Fuze v2 but others may have unknown problems related to screen size differences. For screens > 100 high it doesn’t move the albums
against r26185 in UISim
you want this as a patch against my pictureflow-wps integration patch let me know as I have one

This very small mod changes the tracklist so it doesn't fade lines when on a mono display (bit depth 1). Tested against r26241 in Sim only (because I don't have a mono display device).
Please report back if problems.

Latest version of rockbox installed on both Sansa e200 2GB and Sansa Clip Zip 4GB. (3.13) Sorry, release 3.12 was the only one available in the reported version pulldown.

Windows 7 Pro 16GB RAM, i5-2500K, 3.3GHz/ 3.6 GHz, 64-bit. 7.3 Windows Experience Index. OS is otherwise stable and up-to-date.

Blue Screen of Death only happens when I try to connect first one Sansa Device via USB to Windows, transfer mp3’s or update a theme, unplug it, then connect a second Sansa different device. It doesn’t matter whether I start with the e200 or the Clip Zip or vice versa. Upon immediately connecting via USB with the second device, I get a BSOD. I have two e200 devices. It can happen sometimes even when I connect first one e200, then the other.

I can disconnect and reconnect the starting device (for instance the Clip Zip) as often as necessary, but if I want to connect to the e200 (for instance to update a theme), I have to reboot the computer in order to avoid the BSOD.

While playing doom, I can definitely read the amount of ammo, shield status, and health of my character. However, I cannot read the messages like you need the key first to open this door. Also, if you set the screen size to the maximum and turn on the heads up display the font there is also illegible.

Hi all.

I have found a funny thing, which should get fixed. In set_prescaled_volume there is this call:
audiohw_set_lineout_vol(tenthdb2master(0), tenthdb2master(0));

As far as I can see this call is not needed here. So this patch removes it, but as I own only a sansa e280 I can not test this change. I hope to commit this soon.

If this call is needed… do we need it every time audio changes or only once at init?

Thanks,
AustrianCOder

Here is a path that implements the year day variable in the tm structure. It does leap year checking. It uses a lookup table to find the number of days, the same as the mktime function. It creates another copy of the lookup table, this could be moved outside to conserve space if required.

As I don't have SVN access from behind the firewall its been built against 18563.

Sometimes my Clip Zip gets in a state where I can resume playback after booting it but then it doesn’t let me seek anymore (seek thingy still moves but then jumps back to where it was, playback is totally unaffected which in this case is bad of course). I also can’t pause or skip. I can go back to the main menu but I can’t move the cursor or go back to the WPS. When I go into the playlist by long-pressing down, the list usually appears but is not functional although here I can usually move the cursor up and down (sometimes I only get a kind of frame but rendering freezes at that point). Trying to shut down lets the “shutting down” popup appear but that’s it.

I seem to remember that going via “recent bookmarks” once was a workaround but in the current state this doesn’t work either.

This broken states persists between shutdowns (or well, switch-offs more like since shutting down doesn’t work). I also tried to recreate the playlist but that didn’t help either so I’m currently stuck with a player that will play but I can’t it make change what to play. I will also have to listen to the same podcast over and over again since no new resume position is saved.

The build I use is 42a725f.

Oh and sorry I didn’t choose the right player. Couldn’t find any Sansa Clip in the list in fact :/

Hello, all
There's a problem with viewing files in some circumstances in iPod 5.5G last 3.9 release.

When I:
playing something in /Music/Artist/Track.flac,
pause playback,
connect USB cable.
rename /Music/Artist to /Music/ArtistSOMETHING, then disconnect USB cable

I just cannot turn playback on ("~Do not exist" or something message appears, it's OK, I know),
BUT
when I trying to enter in "Files" menu - there's no reaction at all. Just nothing. I can't play of any other existing track or change to any directory without restarting device, or:

just go to Playlists → VIew catalog → select some playlist, then some music appears. But it's too long imho.

Is "it" bug or not?.. :)

Thanks,
sorry for my english,

When I use the "Wake Up Alarm" with the "Wake Up Screen" set to "Recording." my Nano turns on OK, but the screen starts on the FM screen. This is especially strange as there is no FM radio on this player.

I am expecting the player to turn on and start recording.

This is a 1g Nano running 3.9

Thanks.