Rockbox

I can confirm that this problem persists.


In the meantime, my personal build of SVN is using the old SV7 code which works great except it doesn't play SV8 mpcs and it has a problem sometimes starting over in the current song after a shutdown instead of resuming at the correct position. I think I saw a patch for something about resume behavior somewhere although this was after the SV8 update was integrated into rockbox.

Might just be me but my battery life also seems longer playing mpcs with the old SV7 code

Hi John, I am also using mpc (sv7, only very few mp3's) and did not experience this problems with the new decoder. I also ran several battery benchmarks without any problem. Some more questions:
- Are your sure this problem came in with the new decoder or was there some change afterwards that caused the failures you see?
- Do you build the old mpc decoder into current svn?
- Do you have similar problems with other audio formats?
- Can you share (at least a portion) of a problem file?
- Battery life will not be affected by the new decoder. It was only minor slower (<0.5 MHz), which will not even have measurable impact to runtime on PP-targets (which battery lifetime scale a lot with the efficiency).

Another possible reason might be read errors. I cannot say whether the new code is less resistant against data errors in the bitstream. Skipping while playback is either a buffering problem or a codec error (most probably caused by either broken stream/file or read errors). The decoder does not handle folders. So, if a folder is left this can only be decode driven if there is no playable file found in the folder and you have activated the playback setting to play folder by folder. Also resume not working is strange. This definately works for me and sounds like parsing the headers fails on your player. This can also be caused by read errors or damaged files.

Edit 1: Just saw  FS#11419 . This reports a similar failure with flac and ape on clipv2. Maybe there is something generally broken?

Edit 2: Have to acknowledge the resume failure. Broken resume was caised by r26032 which solved the laggy first mpc seek.

Resume is fixed with r26990. Silly me, dumb error :/

Nevertheless the stopping playback is not solved. It may be connected to  FS#11419  which describes similar behaviour...

Like I said, I went back to the old decoder (using musepack code from release 3.5.1) and integrated that into the latest SVN build and that works. I am not sure if all of these problems all came in with the introduction of the first new decoder code or if some of them came up after with later changes to it. I don't think I have these problems with other formats, but I've only extensively tried MPC, MP3, OGG and to some extent, FLAC.

I don't have an example MPC file with me, but all of them seem to do this. I don't think battery life is a big issue although I was wondering if the older code was more efficient or not. --I just read your point about the battery life and CPU.

I will try 26990 and see if the resume problems are fixed or not.

John,

some more questions:

- EABI or non-EABI compilation?
- Do you have further information about the crashes (e.g. the address and a map file)?
- Are the failures the same on your nano 1G and your Fiuze v1? If not, what are the failures on each of the devices?

thanks for your support,
Andree

Non-EABI before, I recently confirmed some of the same problems with a new EABI build (it takes a while to see all of the behaviors, it works best if you have an hour or two to listen for a while and skip through a music collection). I will have to try my new eabi build a while longer to see exactly what the differences are. The crashes were more like freezes really; playback would stop, usually when skipping to a new track, and I couldn't get it to do anything. It usually required a hard reboot. This crash thing would only happen once in a while.

I haven't had a lot of time to play with the nano 1G much, I've been using the fuze a lot more ( fast 16GB SD+2GB internal fuze flash vs slow 4GB nano flash). I know for a fact that when I was running MPCs on my nano I had a lot of the same problems with the new musepack that I'm having with the fuze, but I cannot confirm at this time that the nano is having all of the same issues. I have not tried the EABI build on my nano 1g yet, maybe later today I can test the two players a little more.

Ok, it would be great to have the results for your nano 1G as this one uses the same processor type as my iPod Video and is a stable platform with few driver changes. The as3525 code changes a lot these days...
When the freeze happens: Is this a freeze of the playback engine (gui is active, but no other title will play)? Or is it a total freeze including the gui?

I was getting the track skipping a lot yesterday on both the nano and the fuze (now using EABI),
Today I did not experience any problems.
The freeze I mentioned was a total freeze, it did not happen very often though and I can only confirm the freeze on the fuze and not the nano. As I said, I did not experience any trouble with my 26997 build today (same one I was using yesterday afternoon), although I did not listen to nearly as much music.

So now of the potential problems left, it looks like 1. a mid-track skipping problem and 2. a much less common freezing issue. The folder jumping thing might have been related to the first issue but the jumping only happened twice so I don't know if it is something repeatable or not.

I will post again the next time I experience one of the above issues.

Ok, the folder jumping thing just happened again.
It looks like skipping several tracks forward and backward rapidly without the player keeping up did something to trigger it. ???

I think a page refresh made the last comment come up twice.
I don't want to close this bug but I would like to say that now my players are working better with the sv8 codec for now (getting tolerable listening continuity now). I know I will regret saying that since it'll probably act up again sooner or later...

I deleted you double post, I hope you don't mind. It is good to hear the behaviour seems more stable now. But I am still a bit concerned as I am not sure what you really experience.

Folder jumping: The use case you are describing (intensive skipping in the playlists) does not seem to be influenced by the decoder itself and I cannot see
anything special in mpc's codec state machine. Maybe this is really an issue that is connected to the playback/playlist engine?

Freeze: Is it totally freezing or is it not possible to play back any other track (gui still responsive)?

Mid track skip:
1) Any special track where this is happening? In trunk (since r26953/26954) we have such behaviour with as3525 (e.g. your fuze, but not your nano) where it is not a fault of the codecs.
2) As you can build rockbox, please try the following: In libmusepack/internal.h there is a define "#define MAX_FRAME_SIZE 4352". Please try to use a smaller value (half or quarter) and check whether this effect happens more often. And as a second approach enlarge this value (double) it and check whether this mid-track-skip disappears. I am not sure, if this will have an effect, but it _might_ if you are using very high bitrate files.

Is the "folder jumping" due to the directory skip function being used?

From http://download.rockbox.org/daily/manual/rockbox-sansafuzev2/rockbox-buildch4.html#x7-500004.3.1 -

Short Right + Long Right = skip to the next directory
Short Left + Long Left = skip to the previous directory

Thank you Mr. Buschmann and Mr. Bavin. I would now like to close this bug. I recently noticed while playing through a collection of MP3s on the fuze, the skipping DOES indeed affect other codecs although the likelihood of skipping on any particular track has been reduced now for some reason unknown to me. The freezing does not seem to happen anymore and I'm not sure if it was connected to what I was experiencing before or not. Thanks for maintaining the codec.

I was not aware of the directory skip function. Is there a way to turn it off or disable it?