Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Codecs
  • Assigned To
    Buschel
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Rbutil git
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by sssUSER - 2010-06-18
Last edited by pondlife - 2010-06-22

FS#11416 - MPC/Musepack

Using Build 26685 with Sansa Fuze v1 but seems to affect my nano 1G as well, so other players are probably affected:

*while playing, sometimes it will skip to the next track while in the middle of playing a musepack song. The track will appear to end abruptly and it does this every so often, it is VERY annoying.
*sometimes it will leap out of the current folder and play another without cause
*sometimes it will just crash, especially when skipping tracks (not often but often enough to be an annoyance) and I need to force reboot
*resuming NEVER works now, it will actually skip one or two tracks ahead when turned back on and start at the beginning there. Sometimes it will crash there and not play.

I did not notice this until I encoded a lot of music into musepack format (my encoder is SV7) and THEN the behavior really became apparent. It looks like this new musepack code is no good as is. Maybe we should go back to the old code. It was fast and stable, and it suited my needs.

Closed by  pondlife
2010-06-22 11:59
Reason for closing:  Fixed

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?

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing