- Status Closed
- Percent Complete
- 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
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.
2011-04-27 20:41
Reason for closing: Fixed
Additional comments about closing: Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407
Fixed with playback engine rework
(r29785).
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
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
Please see
FS#10919for the issue you are describing.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…
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.
If that actually works that is rather disturbing…
It works, it is just shortly displaying the broken title and then switches to the next.
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
2) zero'ing the mp3entry except 2 contents ⇒ filename and codectype
So, there is something wrong in the playback engine when handling empty filenames and/or codectype==AFMT_UNKNOWN.
Buschel, I also get valgrind errors about uninitialized vars when I press rew/ff really fast.
Should I try the playback_v3 patch?
No, the rew/ff issues will most likely not be connected to this one.
If/when I commit the (much pheared) engine rework, this kind of undefined nonsense should drop off the radar.