Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#6274 - Playback weirdness with resume and talk clips

Attached to Project: Rockbox
Opened by Mike Holden (mikeholden) - Wednesday, 01 November 2006, 16:52 GMT+2
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Player Type Iriver H300 series
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

I usually have dir and file clips spoken, but menus not spoken. I have been seeing some playback weirdness in this mode on my 340.

I am unable to provide a definitive test case, but will report my observations.

If I resume playback of a .m3u playlist and let the playlist play through to the end, and then play another playlist, playback of that second playlist only completes the first song, and then stops and goes back to the filebrowser. The WPS during this first song would indicate that it thinks there are more songs to play (playlist song count is correct for the album).

If I play the playlist again, it resumes at the beginning of the playlist again with song 1. At some point further on, it starts to get even weirder, with songs stopping partway through and starting over, or playing bits of other songs in the middle and then resuming the other song and so on.

This is not totally predictable, but since I stopped using file/dir clips, playback has (so far) been normal again, with no weirdness.
This task depends upon

Closed by  Steve Bavin (pondlife)
Wednesday, 21 March 2007, 14:33 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  Should be fixed, advise me if it needs reopening.
Comment by Mark Arigo (lowlight) - Wednesday, 01 November 2006, 18:17 GMT+2
I thought I just fixed this. Are you using a daily or cvs build?
Comment by Mike Holden (mikeholden) - Wednesday, 01 November 2006, 18:41 GMT+2
I've just loaded todays daily on. I was using one from a few days ago. Should have done this BEFORE reporting - sorry!

I'll give it a go for a few days, and I will report back whether the weirdness has gone or not.
Comment by Mike Holden (mikeholden) - Tuesday, 07 November 2006, 17:32 GMT+2
I have now been using recent builds for a few days now, and didn't see any issues. However I loaded up today's build (061107) and have seen some playback corruption. I can't say for definite that this is due to today's build or not.

I haven't seen playback stop after the first song, but I have seen the random playback problem, where songs skip from one to another, show the wrong id3 information etc.
Comment by Steve Bavin (pondlife) - Wednesday, 21 March 2007, 13:25 GMT+2
Hi Mike,

There's been some more fixes in playback (and voice support) recently. Have you seen signs of this bug or do you think it can be closed?
Comment by Michael Sevakis (MikeS) - Wednesday, 21 March 2007, 14:20 GMT+2
I committed recording updated on 6 Nov, 2006 with some buffer management bug fixes and more followed after that. The reason resume caused playback misbehavior with voice is that the playlist resume code uses the audio buffer for scratch space on resuming and would trash memory areas that voice used. Much of what RB was doing with memory was based on hardware codec and totally wrong on SWCODEC. The playlist code for awhile has used the buffer management API and should no longer have any problems. IMO this task should be closed.

Loading...