Rockbox

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

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#10930 - Playback stuck after selection of broken/non-playable audio file

Attached to Project: Rockbox
Opened by Andree Buschmann (Buschel) - Sunday, 24 January 2010, 17:51 GMT+2
Last edited by Andree Buschmann (Buschel) - Wednesday, 27 April 2011, 22:41 GMT+2
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Player Type All players
Severity Medium
Priority Normal
Reported Version Release 3.4
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

During investigation of  FS#10637  the following error seems to be the root cause.

Preconditions:
Have a folder or playlist with several audio files. Of these one audio file is corrupted (e.g. some file named to .mp3). The corrupted file is recognized in metadata.c and the check of this file will return "false" (e.g. using sv8 mpc or simply save an 6 byte binary file to .mp3).

Usecase:
Playing a non-corrupted file and selecting the corrupted file by hand.

Observed:
The playback stops and will stay blocked until you restart the player. This blocking only happens, if the corrupted file is not the last file in the playlist/folder.

Tested with mp3 and mpc files. For mpc this is bad as we do not support all versions of mpc bitstreams. In this case the check of the file results in "false" (=not playable), and the playback engine is blocked afterwards.
This task depends upon

Closed by  Andree Buschmann (Buschel)
Wednesday, 27 April 2011, 22:41 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  Fixed with playback engine rework (r29785).
Comment by Tom Bauer (littlenick) - Tuesday, 23 February 2010, 18:49 GMT+2
Rockbox version r 24861-100222 gives me a gap in the middle of the song when spinning up the disc to fill the buffer when playing back ogg-files (ca. 220-280 kbps) on my iriver h120.
I am new here and not experienced with tech-stuff. justt managed to get rockbox on the player.
Your help is being appreciated - cheers!
Thomas
Comment by Andree Buschmann (Buschel) - Wednesday, 24 February 2010, 21:16 GMT+2
Please see  FS#10919  for the issue you are describing.
Comment by Andree Buschmann (Buschel) - Saturday, 27 February 2010, 14:12 GMT+2
This fixes the failure. When selecting a non-playable file the next song is played.

Edit: After intensive testing it seems this patch does not fix the issue but reduces the probability that the failure occurs. Also it seems like additionally activating LOGF-messages in codec.c again rises the probability.... To me this sounds like timing...
   playback_v01.patch (0.5 KiB) 
 apps/playback.c |    4 ----
 1 file changed, 4 deletions(-)

Comment by Andree Buschmann (Buschel) - Monday, 04 October 2010, 08:30 GMT+2
With r28205 this error is still occuring. The attached patch fixes this with a workaround (not zero'ing the mp3struct for this file). I am not sure though what the impact of my patch to the buffering will be. Someone with more knowledge of the buffering code is needed.

For reproduction just create a folder with 3 files:
Track01.mp3
Track02.mp3
Track03.mp3
whereas Track02.mp3 is just a renamed small text file (e.g. version.h from the build-folder).

To reproduce the error first play Track01.mp3 and then select Track02.mp3 from the filebrowser. From now on the playback is totally blocked and you will need to restart your player/simulation.
   playback_v02.patch (0.5 KiB) 
 apps/buffering.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comment by Jonathan Gordon (jdgordon) - Monday, 04 October 2010, 10:12 GMT+2
If that actually works that is rather disturbing...
Comment by Andree Buschmann (Buschel) - Monday, 04 October 2010, 20:48 GMT+2
It works, it is just shortly displaying the broken title and then switches to the next.
Comment by Andree Buschmann (Buschel) - Monday, 04 October 2010, 23:20 GMT+2
The attached patch moves the zero'ing of the mp3entry-struct from "buffering.c" to "metadata.c" where it belongs to (in terms of error handling). I have added an error handling in two variants at the end of "metadata.c" (lines 538-549).

1) zero'ing the full mp3entry-struct
-> shows the failure with the blocked playback engine
2) zero'ing the mp3entry except 2 contents => filename and codectype
-> works fine
-> if you additionally set filename or codectype to zero, the same as in 1) happens

So, there is something wrong in the playback engine when handling empty filenames and/or codectype==AFMT_UNKNOWN.

   playback_v03.patch (8.1 KiB) 
 apps/metadata.c  |  113 ++++++++++++++++++++++++++++++++++---------------------
 apps/buffering.c |    4 -
 2 files changed, 72 insertions(+), 45 deletions(-)

Comment by Thomas Jarosch (thomasjfox) - Friday, 18 February 2011, 10:06 GMT+2
Buschel, I also get valgrind errors about uninitialized vars when I press rew/ff really fast.
Should I try the playback_v3 patch?
Comment by Andree Buschmann (Buschel) - Friday, 18 February 2011, 10:40 GMT+2
No, the rew/ff issues will most likely not be connected to this one.
Comment by Michael Sevakis (MikeS) - Wednesday, 27 April 2011, 02:47 GMT+2
If/when I commit the (much pheared) engine rework, this kind of undefined nonsense should drop off the radar.

Loading...