Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System All players
  • Severity Medium
  • Priority Very Low
  • Reported Version Release 3.4
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Andree Buschmann - 2010-01-24
Last edited by Andree Buschmann - 2011-04-27

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

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.

Closed by  Andree Buschmann
2011-04-27 20:41
Reason for closing:  Fixed
Additional comments about closing:  

Fixed with playback engine rework (r29785).

Tom Bauer commented on 2010-02-23 17:49

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

Andree Buschmann commented on 2010-02-24 20:16

Please see  FS#10919  for the issue you are describing.

Andree Buschmann commented on 2010-02-27 13:12

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…

Andree Buschmann commented on 2010-10-04 06:30

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.

Jonathan Gordon commented on 2010-10-04 08:12

If that actually works that is rather disturbing…

Andree Buschmann commented on 2010-10-04 18:48

It works, it is just shortly displaying the broken title and then switches to the next.

Andree Buschmann commented on 2010-10-04 21:20

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

  1. > shows the failure with the blocked playback engine

2) zero'ing the mp3entry except 2 contents ⇒ filename and codectype

  1. > works fine
  2. > 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.

Thomas Jarosch commented on 2011-02-18 09:06

Buschel, I also get valgrind errors about uninitialized vars when I press rew/ff really fast.
Should I try the playback_v3 patch?

Andree Buschmann commented on 2011-02-18 09:40

No, the rew/ff issues will most likely not be connected to this one.

Michael Sevakis commented on 2011-04-27 00:47

If/when I commit the (much pheared) engine rework, this kind of undefined nonsense should drop off the radar.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing