|
11863 | Bugs | Music playback | Low | Playback / buffer freezes | 2011-01-06 | Andree Buschmann | 2011-04-06 | 15 |
Task Description
Extracted from FS#11830 . Since the issues described below also occur when FS#11830 is not applied this bug report is generated.
On iPod nano 1G and iPod Video’s the following were issues observed:
1) Device does not fully start (no menu visible, background image loaded)
2) Playback stopps or does not start (WPS playtime is 0:00)
3) “data abort” on white screen
Except (1) and (3) the iPod’s UI responds. In situation (2) loading mpegplayer or shut down via longpress Play/Pause is not possible. In general plugins (tested with test_fps and test_mem) can be loaded and performed normally.
On iPod Video this happened with builds which based on r28915, r28940 and r28960. So, before the ATA but after some kernel/thread/priority changes.
I could provoke this failure twice when generating the DB during playback. But these failure also happened randomly during standard playback (mp3 and mpc in my case).
As long as we do not know what is happening I will assume this is not specific for PP502x processors.
|
|
11476 | Bugs | Music playback | Very Low | Fast Forward makes Musepack (SV8) "data abort" | 2010-07-13 | Leo Witt | 2010-10-02 | 12 |
Task Description
1. Player: Sansa Clip+ 8gb
2. Player Sansa Fuze V1 2gb
Version: 27409-100713
microSD: 8gb
Hello,
this is my first bugreport.
I have some strange behaviours when I want to play Musepack (SV8).
Sometimes, when I fast-forward (even a little) a .mpc-track, my Clip+ & Fuze V1 goes “data abort”.
For example my Clip+ says this:
Data abort
at 30006638
(domain 0, fault 8)
address 0xFBFAF60C
And my Fuze V1 says this:
Prefetch abort
at BB06574
FSR 0xFF
(domain 15, fault 15)
I’ve also tried the official 3.6 release for Fuve V1, but this is what happened too:
Data abort
at 30801020
FSR 0×8 (domain 0, fault 8)
adress 0xD106D033
or:
Data abort
at 30801020
FSR 0×8 (domain 0, fault 8)
adress 0ACFC87EF
And this is what I get sometimes with the 3.6 release, when I just wanted to start a .mpc :
Undefined instruction
at 2F900000
Hopefully, you guys can fix this.
Greetings
|
|
8459 | Bugs | Music playback | Very Low | Playing a VBR mp3 from the current playlist browser cra ... | 2008-01-14 | Jim Billy | 2008-02-10 | 8 |
Task Description
Playing a VBR mp3 from the current playlist browser crashes iaudio X5 when the WPS has the next track info. (also crashes the latest X5 simulator)
To reproduce
1) select a WPS with the next track info statically on the screen(not flipped in)
2) create a playlist with VBR encoded mp3 files in it
3) from the WPS, long select, playlist, view current playlist
4) browse to a known VBR mp3 and play it
5) attempt to return to the WPS screen (BOOM! at least for me)
I have had to work around this issue by flipping to the next track info from a 1 sec static text in the WPS.
moderator, please delete duplicate entry for this, I forgot to include the summary.
|
|
9949 | Bugs | Music playback | Very Low | r20096 - Song not playing, noise instead | 2009-02-24 | Hector Izquierdo | 2009-03-07 | 8 |
Task Description
Hi. I’ve just updated to revision r20096. My last revision was prior to r20093. Now, sometimes when the tracks change, the playback won’t start, and strange noises are reproduced instead. The time counter stays at 00:00. Pausing and resuming playback fixes it.
|
|
11650 | Bugs | Music playback | Very Low | "Garbage sounds" on Musepack (.mpc) | 2010-10-02 | Leo Witt | 2010-10-02 | 6 |
Task Description
Hello again!
I've got another (  ) complaint about Musepack:
On some tracks I hear annoying clink (It appears particularly after/with heavy basses).
This clink doesn't appear with other codecs on rockbox or with musepack+foobar2000.
I attached examples, where this clink very often appears.
I created these (of course) from my lossless source.
If you need a nother one, please let me know.
Tested with Clip+ & Fuze V1 & e260 v1
Greetings,
Leo
|
|
5495 | Bugs | Music playback | Very Low | audio_set_track_changed_event() skips first track in pl ... | 2006-06-04 | Robert Keevil | 2007-06-24 | 5 |
Task Description
The audio_set_track_changed_event() skips the first track in a playlist on SWCODEC devices since the playback code was reworked. A CVS checkout from April 1st works fine.
Attached is a cutdown version of patch 5166 that writes a couple of lines per event (diff file was slightly hand crafted, hopefully will patch cleanly to 1st April CVS).
|
|
8077 | Bugs | Music playback | Very Low | MP3 playbacks stops sometimes when usefl nears 0 | 2007-11-03 | Bertrik Sikken | 2007-11-04 | 5 |
Task Description
MP3 playbacks sometimes stops, at that point the usefl value in the buffering thread debug menu is close to 0. Tested using SVN 15412.
Reproduction recipe:
* Use the database to start playback of an album full of mp3s
* Enter the buffering thread debug menu
* Use the scroll wheel to skip forward. This causes the usefl bar to diminish. Continue skipping until it is almost at zero, then let it play down to zero.
* About every other time, the playback completely stops at this point. During playback, the pcm, alloc and real bars were nearly full. When the problem occurs, the real bar is suddenly empty and the pcm quickly drops down to 0, then playback stops. Usefl shows a low number (not 0), like 16k or 18k.
* The Sansa is in a confused state now, stopping the song causes a hang, shutting down shows the ‘shutting down…’ splash but takes very long (15 sec or so).
This may be related to FS#8037 , FS#8073 , FS#8074 because symptoms appear to be similar.
Attached are two logf’s (logf enabled in playback.c and buffering.c).
|
|
8206 | Bugs | Music playback | Very Low | Resuming playback from end of song after power on confu ... | 2007-11-21 | Richard Sweeney | 2011-04-06 | 5 |
Task Description
Resuming playback of a song that is a few seconds from ending after the player has been powered on confuses the playback.
The simplest way to reproduce this behaviour is to do the following (this works in the simulator too).
Select a song to play and let it play almost to the very end, make sure that another song is in the playlist to be played afterwards.
A few seconds before the end of the song, stop the playback and then shutdown Rockbox.
Start up Rockbox and resume playback. The playback will continue from half to three quarters of the way through the following song on the playlist.
This appears to be buffer related as fast forwarding to the end of the song, shutting down and resuming will not produce this behaviour.
|
|
8836 | Bugs | Music playback | Very Low | Short pcmbuf_beep() (AKA Keyclick) doesn't work properl ... | 2008-04-01 | Steve Bavin | 2008-12-11 | 5 |
Task Description
The attached patch revises pcmbuf_beep() in an attempt to kill the beeeeep of death that occurs on PortalPlayer targets when keyclick is enabled.
With this patch, on c200, the unpleasent beep seems to have gone, but the keyclick isn’t very reliable:
- Before playback is started, the keyclick has an extra click (probably when pcm playback begins)
- While playback is in progress, the keyclick sounds correct, but is delayed (could the 1/8th second delay be removed?)
- After playback then STOP, the very first keyclick works, but subsequent ones are almost inaudible.
I’ve no idea why, but if the un-needed “memset(bufstart, 0, samples * 4);” is removed, then the keyclick after playback rarely sounds at all. I guess it’s something to do with memory caching, but am not a low-level expert.
Also, it would be good if the pcmbuf static variable audiobuffer could be renamed, to avoid potential confusion with the audiobuffer declared in buffer.c.
|
|
10377 | Bugs | Music playback | Very Low | PCM buffer remainder is played under too many condition ... | 2009-06-24 | Jeffrey Goode | 2009-06-29 | 5 |
Task Description
The pcmbuf_play_remainder() routine in pcmbuf.c was intended to ensure that the last samples were played out of the buffer at the end of the playlist. This was done from a call in playback.c, but the placement of that call causes pcmbuf_play_remainder() to be called for all stops. This caused a subtle bug in another patch that could crash the player under certain conditions.
This patch changes the placement of the call so that it’s only invoked at the end of the playlist as intended.
|
|
11817 | Bugs | Music playback | Very Low | M:Robe 500: Kinetic-scrolling influences music plaback | 2010-12-20 | Leo Witt | 2011-06-05 | 5 |
Task Description
Version: r28861
Hello,
when I hold the touchscreen on a kinetic-scroll for some seconds (2-3), the music playback gets interrupted.
This is very annoying on big lists and you're still selecting …
Thanks in advance!
|
|
12093 | Bugs | Music playback | Very Low | Playback hanging after codec/playback rework | 2011-05-03 | Andree Buschmann | 2011-05-09 | 4 |
Task Description
I experienced several hangups during playback in the middle of tracks. Those hangups appeared nearly each 1h of playback. Seek fwd/rwd or play/pause does not solve the issue. Skipping forward lets the next track play normally. The track that formerly hung up can be played normally after a skip.
Player: iPod nano 2G
Tracks: mpc / mp3
Hangups occured with mpc only, but that might just be an effect of my music collection which mostly consists of mpc.
Thread states:
codec *R 16 16 11% (⇒ always *R, not alternating *R/T)
audio T 15 15 57%
buffering T 15 15 25%
I will attach the .config file later.
|
|
13127 | Bugs | Music playback | Very Low | PANIC error "playlist_resume() at any random moment whi ... | 2017-08-27 | Diego | 2019-08-04 | 4 |
Task Description
I have never had this kind of error in years, but since a few days ago I am getting this problem randomly. The screen on attachment 20170827_003451_b.jpg shows up, the device is frozen, i have to reset, then every time I reset it the process of Committing database (attachment 20170827_003523_b.jpg) is done. This can happen after 10 minutes while playing files, after 1 hour or after one minute. I updated to 3.14 not long ago but I have been still using 3.14 for a while without issues. I could be also related with the files I play lately (Game of Thrones audiobook, I attach files info), it doesn’t seem to happen with other files. Please let me know if I can provide more info.
|
|
5200 | Bugs | Music playback | Very Low | gapless play fails after seeking within track | 2006-04-21 | PY | 2006-05-20 | 4 |
Task Description
First of all, thanks Rockbox for bringing gapless mp3 to the iPod mini 2g.
Album made of LAME VBR mp3 with gapless tags, playing great when not seeking. However, if seeking is performed in a track, the next transition will always fail.
Rockbox version 20060419.
|
|
6213 | Bugs | Music playback | Very Low | Audioscrobbler incorrectly submits last song | 2006-10-20 | Reza | 2007-06-24 | 4 |
Task Description
This is very easy to reproduce. Listen to a song; do not go past the 50% point (listen for a few seconds or so). Now, while playing, turn off the player (in my case the iAudio X5). This also works even if you stop music playback then turn off(hold play/pause for a few seconds on the X5). When you submit the .log file, it counts this song as played even though you didn’t go past the 50% point. I use LogScrobbler 0.8 to submit my songs BTW.
|
|
8066 | Bugs | Music playback | Very Low | End of voice clips are cut off when playback stopped | 2007-11-01 | Stephane Doyon | 2011-06-30 | 4 |
Task Description
Some .talk clips are not played until the end. It’s pretty noticeable: I
have “boo” instead of “books”, “musi” instead of “music”, and on .ogg
files the end sounds like “dot aw” instead of “dot o g g”… I have one
directory named “baba” (for tests obviously). I hear just “ba”. some are
fine though. Names that do get clipped get clipped every time, and always
at the same point, at least so long as I don’t change to a different svn
rev.
This happens consistently on my X5, and never on my e200.
It does not happen while music is playing.
The commit that introduced this problem is:
r15006 | jethead71 | 2007-10-06
Something about PCM interface unification.
A hint: reverting this part of the commit:
/* There may be more data waiting to flush, try to use it */
if (pcmbuf_flush_fillpos())
goto process_new_buffer;
makes the symptom go away. jhMikeS warns this is unsafe (and I do believe
it may cause strange UI unresponsiveness), but anyway it’s a hint.
Another observation: talk.c enqueues a short (0.3s) clip of silence at
the end of an utterance. Contrary to what I said on IRC, the silence clip
is added only when the final clip is from the voice file, and not after a
.talk clip. If I disable the addition of silence, then every voice
utterance is cut off before the end, including menu entries. OTOH if I
remove the “&& p_lastclip != p_thumbnail” condition to enable adding
silence for .talk clips also, then my file names are spoken
properly.
|
|
8999 | Bugs | Music playback | Very Low | CPU stays boosted when skipping to the next track while ... | 2008-05-16 | Martin Ritter | 2009-06-10 | 4 |
Task Description
- start playing an album of mp3 files
- quickly skip to the 2nd track
- go to the view buffering thread screen
Buffering will stop prematurely and CPU remains boosted.
This doesn’t seem to happen with VBR encoded mp3 files, though.
|
|
9827 | Bugs | Music playback | Very Low | Rockbox data Abort at 000090D0 (0) | 2009-01-25 | Gareth | 2009-02-22 | 4 |
Task Description
rockbox aborts at the address 000090D0 (0) with build 19852 while playing any music file, the buffers all fill synchronously and the abort happens after they all fill.
|
|
6317 | Bugs | Music playback | Very Low | Lockup if stopping while still seeking to resume point | 2006-11-11 | Peter D'Hoye | 2007-07-31 | 3 |
Task Description
Hitting stop while still reading the file to reach the resume point causes a lockup.
1) Play a fairly large WAV and seek quite far into
stop
start playback using ‘play’ to resume where left
press stop again before playback resumes (= while reading the file to rewach the resume point)
backlight thread still running but paperclip required to get a usable player again.
Observed on h340 but probably an issue on al SWCODEC
|
|
10930 | Bugs | Music playback | Very Low | Playback stuck after selection of broken/non-playable a ... | 2010-01-24 | Andree Buschmann | 2011-04-27 | 3 |
Task Description
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.
|
|
6668 | Bugs | Music playback | Very Low | mp3 vbr gapless is broken | 2007-02-17 | Akio Idehara | 2007-02-18 | 3 |
Task Description
I updated svn revision-12323.
And mp3 vbr (LAME encoded) file couldn’t play with gapless at ipod 5g.
I think SW_CODEC definition is the cause.
|
|
8208 | Bugs | Music playback | Very Low | Distortion on some tracks | 2007-11-21 | Bertrik Sikken | 2010-10-10 | 3 |
Task Description
I’m experiencing some kind of crackling effect on some tracks.
The same track sounds clean on the PC and on the OF (on the same headphones).
Things I already tried:
* turn down the volume → still crackles at -40 dB
* convert track from mp3 to wav, no effect
* various settings in the AS3514, like enabling/disabling ZCU, HPCM, AGC, bias current reduction with no positive effect. I also tried to set the AS3514 to as-default-as-possible settings and that didn’t work either.
* reversing the roles of headphone volume and DAC volume (which of the two is increased first when increasing total volume), no help either.
The current SVN version (15741) still has it. I tried going back to find out which revision caused it, but even version 15000 already had it. I tried going back to even older versions, but I’m having some trouble compiling them.
Attached is a small clip in which I experience the distortion, it’s noticeable between second 2 and 3 and at second 7 (compressed with flac for file size reasons).
|
|
8260 | Bugs | Music playback | Very Low | Audio skips when buffer usefl empties | 2007-12-01 | Andrea | 2008-05-09 | 3 |
Task Description
My iPod mini 2G has a problem with MP3s playback (I’ve only tried MP3s). After about 4-5 tracks, audio skips for about a quarter of second (sounds like a glitch), doesn’t matter where the playback is arrived. However in the buffer debug menu I found that the skip occurs when the bar “usefl” is near to zero and it’s going to refill with new data of next songs in playlist. I’ve tested the r15857, but it’s from about the r15840 that the problem occurs.
One more thing, sometimes audio skips even when I add some songs in the current playlist while playing other files.
|
|
8386 | Bugs | Music playback | Very Low | Problem when fast forwarding and then quickly changing ... | 2007-12-30 | Kankkis | 2009-09-20 | 3 |
Task Description
I just installed Rockbox to an 80GB iPod (5.5 gen)
I noticed a small bug when I was fast forwarding a track; if you fast forward and shortly afterwards change the track to the next one, the new track doesn’t play. In other words push and keep pushing the “next” button, release and press it again, Rockbox changes the song, but doesn’t play it.
Pressing play/pause doesn’t do anything, neither does changing the track (the track changes, but doesn’t play)
Only when you fast forward a few seconds, playback starts again.
|
|
8455 | Bugs | Music playback | Very Low | Some songs do not get played in whole. | 2008-01-13 | Ian D. | 2008-03-09 | 3 |
Task Description
I have had this problem with most if not all of the more recent rockbox builds (last couple of months). Right now I am using version r16053 from the 11th of January, 2008. The problem I am having is that sometimes, for no reason the first 5 seconds of a song play and then rockbox skips to the next track. The other day I had this happen for a whole album (Sublime - 40 oz. to Freedom). I have had this problem on OGG, MP3, AAC, and FLAC coded songs, and so it seems the type of file doesn’t make a difference. I have an 80GB iPod video, but this problem may or may not happen on other platforms, see if it happens to you. Attatched is a copy of my settings.
|
|
8526 | Bugs | Music playback | Very Low | Track 1 in folder is reported as track 2 | 2008-01-28 | Mark | 2008-02-25 | 3 |
Task Description
Rockbox reports the first track in a folder as track 2.
Happens after a folder or playlist finishes.
|
|
8601 | Bugs | Music playback | Very Low | Disk spinup after every single song if dircache is disa ... | 2008-02-12 | Sascha Wolf | 2008-04-02 | 3 |
Task Description
just today I noticed, that my Ipod 5.5G (80GB) spins up the disk after every song from a playist. Songs are MP3 VBR and are aprox 5MB each. Last.FM log is disabled, as is runtime gathering. I tried the latest SVN (16290) as well (the build i noticed this one was 2 days old). I have only my Ipod to test this on, so I do not know wether or not other HD based players suffer the same issue.
|
|
8651 | Bugs | Music playback | Very Low | Screeching, High-Pitched Noise after Crossfade | 2008-02-26 | Humberto Santana | 2008-03-30 | 3 |
Task Description
THIS IS A DIFFICULT ONE!
First, I must say that I’ve found this bug VERY difficult to report, because although quite frequent, it is VERY “slippery” (maybe attempted to be described in the past many times (see [*] below) - from what I found in the flyspray & forums) I kind of feel like a ghostbuster here!. I’ve been “coexisting” with it since I installed Rockbox in November/07. It is related to crossfading, which I use all the time (main reason for coming to Rockbox!). I will do my best to give the relevant information I’ve found, and also, I kindly request experts’ help/ideas on what to check/try in order to find the causes with more accuracy, if that’s necessary in addition to the information I present, in order to solve the bug (please notice that this is NOT a support request!).
- iPod video 80GB 5.5G
- rockbox r16422 (but also happened in previous versions, at least from November/07 to this version)
- mp3 format (both in variable and constant bitrates)
*Description*
Eventually, shortly after crossfading (or right during the crossfading process), playback stops advancing and a screeching, high-pitched, almost hurting, repeating noise begins. I’ve attached a recording of the problem so that you can actually hear it (sorry about the sound quality, I didn’t find a better way than a mic).
Other functions seem to keep on working normally during this noise problem (wps info, menu browsing, etc). To stop the noise, I’ve used the Prev on the clickwheel, and the current song re-starts ok. If I attempt a forward skip, the noise continues. If I pause, and then resume, the noise continues. If I reboot, when going back to “now playing”, it resumes OK but in the previous song to the bug, close to the end of that song.
*To Reproduce*
Now THIS is the main difficulty with this bug, I haven’t found a way to reproduce it precisely (I’ve invested a lot of time in this, but all I’ve got is what’s describe here). I just use crossfading continuously, and sooner or later, the bug appears. In order to give more information about this, I took two actions. 1. I checked the view options in the “debug menu”, and 2. I’ve tried different setting combinations, discarding possible causes.
1. In the debug menus, I’ve noticed the following:
- In the “View buffering thread” option, the pcm bar/values rise almost to the top and stay there during the noise. In normal operation, it goes down after the crossfading process. Also, the CPU freq is 30Mhz during the problem.
Typical values on this screen during the problem are (values vary slightly from bug to bug):
pcm: 3170592/3175200
alloc: 56297688/60322272
real: 54987063/60322272
userfl: 394555113/60322272
data_rem:4567692
track count: 6 (has happened with values 0 to 7, so far)
handle count: 21 (has happened also with i.e values of 18)
cpu freq: 30Mhz (always ends with that value when the bug occurs)
boost ratio: begins with 100% when the problem starts, goes down gradually to 0%. Is the THIS IS THE ONLY VALUE ON THIS SCREEN THAT CHANGES DURING THE PROBLEM, THE OTHERS REMAIL STATIC.
pcmbufdesc: 92/129
- In the CPU Frequency option (debug menu), the values during the bug are: (ALWAYS)
Frequency: 30000000
boost_counter: 0
2. Discarded possible causes
Given that crossfading is enabled (different fade-in and fade-out durations, fade-in delay set to 0, fade-out delay set in tests to a value > 0, fade-out mode set to crossfade), I’ve tried different combinations for the following settings, but since the bug occurs with or without these settings, I guess they can be discarded as possible causes:
- Equalizer enabled or disabled, different specific values.
- All the other “sound settings” were always in their default values.
- Replaygain enabled or disabled, any mode, clipping enabled or disabled, pre-amp any value.
- Any mp3 bitrates (different kbps and/or variable-constant rates in songs involved during crossfading)
- Shuffle enabled or disabled, any mode.
- Repeat enabled or disabled, any mode.
- All the other “playback settings” were always in their default values.
- Any wps loaded (just in case the theme .cfg could have some effect)
[Also in the attachment a typical .cfg]
3. Additional information
Because I can’t be 100% sure that the following information relates to the bug, and because this doesn’t happen ALL the times the problem occurs, I just put it here in case it gives someone a clue:
After the problem occurs:
- Sometimes after normal playback is restored, crossfade doesn’t work anymore. At the end of the song it sort of begins the crossfading process, but the songs are not mixed finally.
- Sometimes the iPod crushes when operating it after the bug restore, the screen is the theme’s wps .bmp, the text displayed “Undefined Instruction at 00069DC4 (0) [code’s last 3 digits vary]
- Sometimes browsing and normal menu operation becomes very, very slow
Thanks in advance! And if there is something else that I can do to help, please just let me know.
[*]
THESE SEEM TO REFLECT THE SAME PROBLEM:
http://forums.rockbox.org/index.php?topic=3860.0 http://forums.rockbox.org/index.php?topic=15406.0 http://forums.rockbox.org/index.php?topic=8946.0 http://forums.rockbox.org/index.php?topic=6281.0
Similar reports (but most probably not the same?):
FS#7214 FS#8597 FS#6117 FS#7635 FS#8498 FS#8600
http://forums.rockbox.org/index.php?topic=8335.0
|
|
9489 | Bugs | Music playback | Very Low | nonlinear frequency response for all codecs | 2008-10-14 | Przemysław Hołubowski | 2008-10-18 | 3 |
Task Description
Recent builds degrade frequency response. It is not flat any longer.
Take a look at my measurements. I have prepared a 10 second long white noise wave, aac and mp3 files and playback it on an old build and a recent one (from 14.10). Results are showing that current build applies some low-pass filtering in a whole audible frequency range and especially in 2-10kHz range.
I think it was introduced a week or more ago.
|
|
10102 | Bugs | Music playback | Very Low | progress doesnt get updated on the first track of a roc ... | 2009-04-06 | Jonathan Gordon | 2009-04-21 | 3 |
Task Description
seems FS#9795 caused the first track of a rockbox session to sometimes not update the track position. and it didnt get caught in testing :/
Index: apps/gui/gwps-common.c
— apps/gui/gwps-common.c (revision 20633)
+++ apps/gui/gwps-common.c (working copy)
-361,6 +361,9 @@
cue_find_current_track(curr_cue, id3->elapsed);
cue_spoof_id3(curr_cue, id3);
}
+
+ if (wps_state.id3→elapsed == 0)
+ wps_state.id3 = audio_current_track();
retval = gui_wps_redraw(gwps, 0,
gwps->state->do_full_update ?
I’ve done some debugging and the correct id3 struct is getting passed to the wps, and it is getting updated in playback.c… so im a bit baffled… (also its midnight so im asleep)
crap… added some %p printfing and even though audio_current_track() is returning thistrack_id3 (as it should).. that is apparently pointing to the wrong thing for the first track!
should be a simple fix in the morning… untill then, use the above bandaid if you cant wait that long
|
|
10335 | Bugs | Music playback | Very Low | End of file not played at end of playlist | 2009-06-15 | Jeffrey Goode | 2009-06-17 | 3 |
Task Description
The last thousand or so samples of a file are not output when played as the last file in the playlist.
To duplicate, play the attached file with another file following it in the playlist, even itself using repeat. There is a distinct chirp at the very end that will be played if another file follows, which is correct. However, if the file is played at the end of the playlist, the chirp is not played. The last samples are omitted from playback.
This behavior occurs on the Sansa e200 target and in the Sansa e200 simulator build. It also occurs on other simulator builds: iriver H120/H140, Creative Zen Vision, and iPod Nano. I didn’t try to build others.
|
|
11608 | Bugs | Music playback | Very Low | Fuze v1 playback issues | 2010-09-06 | Orbidia | 2010-12-07 | 3 |
Task Description
Sansa Fuze v1
Build r27996 r28001 and r28016
A few days ago, I installed the new 2.0 rockbox firmware on the fuze so that I could use the USB mode and not go into the official firmware anymore. The USB mode seems to work well enough.
But in build r27996 the thermometer indicating the playback position in the song did not work when using many of the themes (XL Fuzed for example).
So then I tried r28001 and r28016 the next couple days. Now, not only does the playback bar not work, but a lot of the time, the 320 mp3 files don’t play back at all.
If I first turn on the player, and try to play a song, it works okay. But if I stop the song and try playing another song, often it will just show 0:00 for elapsed and 0:00 for remaining and nothing happens. One time, the song did play but the numer for time elapsed remaining kept jumping to random numbers.
Also, the battery gauge would jump between 98% to strange random numbers above 10000%
It crashed once just trying to playback. I’ve tried the last could builds on 3 different fuze v1 and they all had similar problems.
I’m back to r27996 because at least it plays the music.
It seems something generally broke in the last few builds and I was just trying to report the specific problems in case no one was aware of them.
|
|
12607 | Bugs | Music playback | Very Low | Pausing/fast-forwarding/skipping Ogg Vorbis files with ... | 2012-03-05 | Rudo | 2012-11-30 | 3 |
Task Description
Pausing/fast-forwarding/skipping Ogg Vorbis files with EQ on produces clicking sounds on Clip+.
Please see attached recording oggEQon.flac, in which you can hear the clicks that happen when: starting playback, pausing, unpausing, starting fast-forward, releasing the button, and skipping a track – in this order. I had a playlist with Vorbis files with silence (also attached).
Any non-zero equalizer setting does this. Precut and Replaygain don’t seem to change anything. Turning EQ off or setting it to all zeroes makes the clicking sounds go away (see oggEQoff.flac).
Note that this is specific to OGG Vorbis files. The FLAC and MP3 ones I tried worked fine.
This bug first appeared in the 3.10 release, and is still present it today’s daily build (d18a5ca).
Please let me know if I should provide any more info. I have built Rockbox in the past (even though it was a long time ago), so I should be able to test patches :)
Thanks.
|
|
12642 | Bugs | Music playback | Very Low | This is actually a message for Alex Parker (BigBambi). ... | 2012-04-10 | Terry Layton | 2012-04-10 | 3 |
Task Description
Note: this actually applies to the Sansa Fuze v2 but it is not listed in the Playter Type menu so I made the next closest selection
THIS IS THE MESSAGE YOU SENT ME:
The following task has a new comment added:
FS#12393 - Annoying “click” before track restarts
User who did this - Alex Parker (BigBambi)
Is this still a problem?
In one word: YES!
In fact both release 3.11 and the current build exhibit this problem and now it also occurs whenever the user manually skips back to the previous track or forward to the next. It is so noticeable that I can’t see how the new users can get a favorable impression of Rockbox when its firmware displays such behavior. Even worse, they can review the bug reports on your website and see that this problem has been around for some time. Please listen to the attached files (both MP3 and WMA) and notice that it occurs with both codec types. Always play an individual track for more than 3 seconds before taking any action. When you repeatedly skip forward and backward a track the “click” seems to get louder after the first skips. Next use the original manufacturer’s firmware to do the same thing. I find that the Sansa firmware does not make any noise when the user performs the same actions.
It is surprising for me that you sent this message at this time and after such a long delay, especially as this problem was going to be the subject of my next bug report. Previously the reply I got was that it did not occur in the daily builds after release 3.10 (which was true) and so I was under the impression that this bug had been fixed. Now it has resurfaced with the 3.11 release. Actually, this is not surprising since I and a number of other users have found that the 3.11 release has numerous bugs (it is such a dog). Already there has been a release 3.11.1 issued to replace it.
The first part of my strategy to get the Rockbox team to pay enough attention to this bug was to draw their attention to the worst part of the problem. Therefore I issued bug report FS#12633 about the very loud “clunk” heard when a WMA file is skipped back to the start of the track. This was fixed last week by MichaelGiacomelli (saratoga) but the problem with the “click” remains. I have sent a message informing him of this and I hope he pays lots of attention to this problem since he is someone who repairs numerous bugs. I hope that you also will give a high priority to fixing this bug. If you do not inform me of your intentions on this matter within one week I will issue another bug report for the new users to read.
|
|
12643 | Bugs | Music playback | Very Low | This is actually a message for MichaelGiacomelli (sarat ... | 2012-04-10 | Terry Layton | 2012-04-10 | 3 |
Task Description
Reply to your repair of FS#12633
THIS IS THE MESSAGE YOU SENT ME:
The following task has a new comment added:
FS#12633 - Loud “clunk” when the user manually skips back to the start of a WMA file
User who did this - MichaelGiacomelli (saratoga)
Should be fixed in bc41926. Confirm and I’ll close it.
The “clunk” has disappeared but this appears to have unmasked a similar problem originally reported in FS#12393 . Coincidently, the same day I was sent a message from Alex Parker (BigBambi) about this problem. Here is a copy of the message I sent him that I urge you to read:
The following task has a new comment added:
FS#12393 - Annoying “click” before track restarts
User who did this - Alex Parker (BigBambi)
Is this still a problem?
In one word: YES!
In fact both release 3.11 and the current build exhibit this problem and now it also occurs whenever the user manually skips back to the previous track or forward to the next. It is so noticeable that I can’t see how the new users can get a favorable impression of Rockbox when its firmware displays such behavior. Even worse, they can review the bug reports on your website and see that this problem has been around for some time. Please listen to the attached files (both MP3 and WMA) and notice that it occurs with both codec types. Always play an individual track for more than 3 seconds before taking any action. When I repeatedly skip forward and backward a track the “click” seems to get louder after the first skips. Next use the original manufacturer’s firmware to do the same thing. I find that the Sansa firmware does not make any noise when the user performs the same actions.
It is surprising for me that you sent this message at this time and after such a long delay, especially as this problem was going to be the subject of my next bug report. Previously the reply I got was that it did not occur in the daily builds after release 3.10 (which was true) and so I was under the impression that this bug had been fixed. Now it has resurfaced with the 3.11 release. Actually, this is not surprising since I and a number of other users have found that the 3.11 release has numerous bugs (it is such a dog). Already there has been a release 3.11.1 issued to replace it.
The first part of my strategy to get the Rockbox team to pay enough attention to this bug was to draw their attention to the worst part of the problem. Therefore I issued bug report FS#12633 about the very loud “clunk” heard when a WMA file is skipped back to the start of the track. This was fixed last week by MichaelGiacomelli (saratoga) but the problem with the “click” remains. I have sent a message informing him of this and I hope he pays lots of attention to this problem since he is someone who repairs numerous bugs. I hope that you also will give a high priority to fixing this bug. If you do not inform me of your intentions on this matter within one week I will issue another bug report for the new users to read.
|
|
12648 | Bugs | Music playback | Very Low | When a track is manually skipped back to its beginning, ... | 2012-04-19 | Terry Layton | 2012-04-19 | 3 |
Task Description
Hardware device(s): Sansa® Fuze™ v2 (this exact same problem has also been heard on the Fuze+)
Original manufacturer’s firmware version: 02.03.33
Rockbox version: 3.11.2 (the current release), bc41926 and the current build
The problem described in the title is the same as that reported in FS#12393 . Prematurely, Alex Parker (BigBambi) determined FS#12393 fixed as reported in this message:
From: Rockbox(tracker@rockbox.org)
Sent: April-13-12 12:13:14 PM
To: terrythegreat-1@hotmail.com
The following task is now closed:
FS#12393 - Annoying “click” before track restarts
User who did this - Alex Parker (BigBambi)
Reason for closing: Fixed
Additional comments about closing: Fixed in current build (bc41926, 13 April 2012)
More information can be found at the following URL:
http://www.rockbox.org/tracker/task/12393
*
This task was closed without giving me an opportunity to provide my feedback on whether the repair he did had been successful, which in this case it was not. This is an example of how MichaelGiacomelli (saratoga) did this properly with another bug fix:
FS#12633 - Loud “clunk” when the user manually skips back to the start of a WMA file
User who did this - MichaelGiacomelli (saratoga)
———-
Should be fixed in bc41926. Confirm and I’ll close it.
———-
More information can be found at the following URL:
http://www.rockbox.org/tracker/task/12633#comment42559
I was given the chance to review the changes and comment. As a result this bug is now fixed (the loud “clunk” no longer occurs) and this task is properly closed.
As indicated above, FS#12393 was not successfully fixed and this task is being submitted to replace it. At least some tests were conducted on the MP3 files I included and the problem confirmed (as reported in this earlier message to me):
From: Rockbox(tracker@rockbox.org)
Sent: April-13-12 12:06:49 PM
To: terrythegreat-1@hotmail.com
FS#12393 - Annoying “click” before track restarts
User who did this - Alex Parker (BigBambi)
———-
Curiously I can reproduce this on Fuze v2, but only with the track attached to this bug report and not with any others that I tried. I don’t have any wma to try. I haven’t tried on any other targets.
**
Firstly, I have conducted tests using bc41926, release 3.11.2 and the current build on this track and many others downloaded randomly from the internet, including MP3s and WMAs. The results are always the same as described in FS#12393 . The attached tracks were produced on a friend’s computer using Windows Media Player 12 to rip them from a CD and then transferred to the player. However, I find that these tracks behave exactly the same as those produced on my computer and additionally that of the local university’s machines after a full virus scan. As reported in FS#12393 , when the user skips back to the start of a track after a few seconds of play, there is an annoying “click” before the music restarts. Also this “click” now occurs whenever the user skips forward a track or back to the previous one. Admittedly, what Alex Parker (BigBambi) may have missed is that occasionally when the WPS playback is activated immediately after powering up the player the “click” may have a much lower volume until after this function is activated a few times. That is why a number of tests lasting a few minutes with a few tracks should always be run to determine whether this bug still occurs after a fix is applied. There may also have been some confusion because BigBambi and saratoga were working on fixing similar problems and their repairs were both included in daily release bc41926.
Secondly, the same problem also occurs on the Sansa Fuze+. It is true that this is classified as an unstable port but since the “click” occurs in the same manner and has exactly the same sound as on the Fuze v2, I can’t help but conclude that this is a problem with the firmware and not with the player or the tracks used.
I would be happy to review your new changes designed to fix this problem and provide constructive feedback. Your goal should be to make the Rockbox firmware as silent as the Sansa firmware during these transitions using the files attached to this report.
|
|
12850 | Bugs | Music playback | Very Low | WMA Pro skips to a next track while playing | 2013-04-05 | Mateusz | 2013-04-05 | 3 |
Task Description
Hi,
I’m experiencing an issue with WMA Pro playback on my Clip Zip.
I’ve got the lastest stable build of Rockbox 3.13. Files were encoded with dbpoweramp.
Some files playback normally, but majority of tracks skips. Always at the same point if not forwarding or rewinding.
Here’s a sample. The track skips at 2.15.
|
|
13094 | Bugs | Music playback | Very Low | Playing a zero-duration WMA causes crash | 2016-12-20 | Chris Jordan | 2016-12-20 | 3 |
Task Description
Build 575bd89 2016-12-19
Playing the attached zero-duration WMA '_ length 0.0s WMA.wma' causes crash:
Divide by zero at 6008D274
pc:6008D2&4 sp:600CC7DC
bt end
This WMA file was created by Goldwave and plays without crash in Windows Media Player, GoldWave and MediaMonkey.
Zero-length WAV and MP3 files (examples attached) don't cause a crash.
On the latest development iPod Video and ZEN simulators, MP3 and WAV are reported 'failed' and WMA crashes http://i.imgur.com/k3dKaSN.png http://i.imgur.com/CiYnVuH.png
|
|
5292 | Bugs | Music playback | Very Low | Player keeps getting stuck in the directory view with c ... | 2006-05-04 | Douglas Valentine | 2006-05-08 | 2 |
Task Description
The summary pretty much says it all I keep getting stuck in the directory view with the current build on my h140 if I try to use it to change which directory I am currently playing files from when playback of the current file is paused.
I pause the current song enter directory view, change into the new directory I wish to listen too and press select on the first file.
My player then no longer responds to key presses to move the curser up and down or even shutdown, but when you press a key the back light comes on and after a few seconds the back light goes back out again.
The only way shutdown the player or exit the directory view at this point is to press the reset button.
I don't know if which codec I am using is important but I am using ogg files at the moment.
|
|
5415 | Bugs | Music playback | Very Low | Auto change directory, playback stops | 2006-05-22 | | 2006-06-03 | 2 |
Task Description
standard settings + “Auto-change directory = on”, “Repeat = off”.
(cvs 2006-05-22 06:57) http://www.rockbox.org/dist/build-iaudiox5/ says “rockbox.zip 22-May-2006 09:00”
when playing the last file in a folder it jumps nicely to the first file of the next folder, but only plays like 2 min of that song then playback stops (for flac files, mp3s seems to play longer, sometimes even a few songs, but also eventually stops).
to continue you can either skip to the next track or select a track from the filebrowser, but you can’t skip back to the beginning of the track it stops on.
to me it seems like the codec-bar in “Info→Debug (Keep Out!)→View audio thread” ends up empty to early, also the “boost ratio” falls down and ends on 0% at the same time as the codec-bar turns empty and playback stops.
|
|
5536 | Bugs | Music playback | Very Low | Playback stops or freezes in the middle of a track | 2006-06-12 | Deb | 2006-10-06 | 2 |
Task Description
ok, it’s happening everytime. The playback stops or freezes when finished playing tracks from one directory and then starts playing tracks on the next directory and freezes somewhere between 4-6min mark on the 1st track of the 2nd directory.
I’m using the latest build with the following settings changes:
Repeat > Off
Resume On startup > Yes
Auto Change Directory > Yes
Backlit While Plugged In > On
Car Adapter Mode > Yes
Anti-Skip set to 15 sec
‘Clean’ theme from here http://www.rockbox.org/twiki/bin/view/Main/WpsIriverH100
Playing only FLAC.
|
|
13133 | Bugs | Music playback | Very Low | Opus files with embedded artwork 45.8KiB or larger skip ... | 2017-10-29 | Eli Bildirici | 2019-08-04 | 2 |
Task Description
Opus files that contain album artwork ~45.8KiB or larger skip near the beginning.
This issue has been observed using the latest stable 3.14 build for the Sansa Clip Zip, as well as on xvortex’s fork for the XDuoo X3. This happens with files encoded both with and without the –vbr flag, on Opus versions going back to opustools 0.1.5/libopus 1.0.1 through the current 0.1.10/1.2.1, with files of arbitrary bitrate, size, or length.
How much skipping occurs appears to relate to bitrate - the lower the bitrate, the greater the skip. This manifests itself as follows: the first second, 00:00-00:01, plays back fine. Then, playback skips to 00:04, for files of middling bitrate (128-180 kbps or so. On lower bitrate files, the first second is skipped, then 00:01-00:02 is played back, and then we skip forward again to 00:05 or 00:06.
The files playback fine in foobar2000 on Windows and Android, as well as GoneMAD on Android. One stripped of artwork, or replaced with artwork of the correct size, the files playback fine on Rockbox, too.
At first I thought this behavior was limited to files encoded with opustools 0.1.10/libopus 1.2.1, or if it did happen with older encodes, it only occurred at low bitrates. Subsequent testing has confounded this when I found some old files that had album artwork that were encoded with an older version of opustools but which didn’t have problem playing back. I noticed that the artwork was abnormally small, at just 20KiB, and set out to test. That is how I came up with the 45.8KiB boundary. The largest JPEG I generated that worked was 45.6KiB, and the smallest that failed was 45.8KiB. I wanted to get more granular but quickly learned that generating JPEGs of such an exact file size is not trivial.
Attached are files bearing all this out, as well as the source flac, with the original album artwork. All files here were encoded using these parameters: “–quiet –bitrate 96 –vbr –ignorelength”. I also did initial tests without –vbr and at higher bitrates, but got the same results, so I dropped them. There are two sets - turkish_march.7z, which got encoded at higher bitrates typical of music, and verse_of_the_rings.7z, which got encoded at lower bitrates typical of voice (but not in speex mode; we’re still at ~50-60kbps or so). These are just excerpts of the complete files, but the complete files exhibit the same behavior.
Forum thread can be found here (though there’s not much there…)
http://forums.rockbox.org/index.php/topic,52043.0.html And note that yes, I understand that attaching large jpegs to puny opus files is a bit silly. But that doesn’t mean the option shouldn’t be there, particularly if one wished to encode at larger bitrates, for whatever reason.
|
|
6068 | Bugs | Music playback | Very Low | Position display resets (0:00) on resume | 2006-09-26 | Mikkel Bernhof Jakobsen | 2007-12-01 | 2 |
Task Description
When I stop playback (not pause) and resume thereafter, the position sometimes resets to 0:00. I noticed that this occurs when I’m listening to a large file (e.g. a live set) and I’ve passed a certain point in the file. I tried stopping and resuming playback within the first 5-10 minutes, and this works just fine. But I tried again at around 14 minutes, and this time it reset the position to 0:00. At this point, if I try seeking, it starts playback at the actual position which is shown.
|
|
8069 | Bugs | Music playback | Very Low | mp3 vbr gapless is broken with r15306 | 2007-11-02 | Akio Idehara | 2007-11-28 | 2 |
Task Description
I updated ipod-video simulator with r15306.
And I found that mp3 vbr gapless was broken with default configuration.
So I downgraded r15305.
Then mp3 vbr gapless was successfully.
I think that new metadata on buffer is the cause.
|
|
8675 | Bugs | Music playback | Very Low | Last song in playlist ends prematurely | 2008-03-03 | Richard Sweeney | 2008-03-04 | 2 |
Task Description
The last song in the playlist ends a few seconds before it should do. This bug doesn’t appear to be related to a player or codec.
Steps to reproduce
Reproduction is quite simple, find a track that has music up the the last second of the track. Highlight the song in Rockbox and do Context Menu → Playlist → Insert. You can fast forward to the last 20 seconds or so of the song to avoid having to listen to the entire thing.
You’ll notice that the time remaining will say 2 seconds (roughly) and then the song will abruptly stop.
|
|
9306 | Bugs | Music playback | Very Low | resume for m4a isn't consistent | 2008-08-20 | Kim Harbroe | 2011-01-31 | 2 |
Task Description
I use a sansa e200 to play m4a files. In the latest version of rockbox r18323M-080820, the bug still exists. I have a version that I use that does not exhibit this behaviour. it is: r17907-080701. Looking back at the daily builds, this lack of resume is still happening in r18043-080715. Steps to duplicate this problem. I have lengthy files. A test file can be found at http://www.sendspace.com/file/9s5x0l I have found that it doesn’t matter whether I am at the beginning of a file or in the middle. It will sometimes resume perfectly when I press stop, power the play off, and then start it up and press play, while at others, it jumps to earlier in the file, or to another file altogether. Bookmarking that is created separately from resume playback’s list works fine. This faulty resume will also work if the player is stopped, and then play is pressed.
|
|
10157 | Bugs | Music playback | Very Low | inaccurate seeking while paused | 2009-04-22 | Michael Chicoine | 2009-06-30 | 2 |
Task Description
r20769 and prior
Fails on device and simulator. Does not fail with flac, wma, ogg, wav
Steps to duplicate failure:
1) start playback of mp3 file (vbr and cbr both fail)
2) pause playback
3) seek forward and stop - this first seek after pausing will always stop where you release the seek button
4) seek forward again and stop - from this point, when you release the seek button, the track will back up 3 seconds from where it was when seek stopped
5) the same happens if you seek backward
This behavior is also causes problems with cuesheet support. If you pause an mp3 file that has a cuesheet and use the skip forward or reverse, it leaves you 3 seconds prior to where it should. Subsequent skip forwards are ineffective. Apparently, it skips to the next track in the cuesheet which is 3 seconds forward and then goes back 3 seconds, leaving you where you started.
|
|
10446 | Bugs | Music playback | Very Low | Prevent potential problems in dsp.c by allowing for 0 c ... | 2009-07-18 | Jeffrey Goode | 2009-08-12 | 2 |
Task Description
There are a number of functions in dsp.c that operate with a do-while loop. Most of these are contingent upon the count argument being greater than zero. While this should always be true, these functions are not fault tolerant and will exhibit unwanted results if called with a count of zero. So I’ve changed these do-while loops to equivalent while loops.
I’ve also changed an unrelated comment mistake describing the nature of a replaygain variable.
|
|
11077 | Bugs | Music playback | Very Low | WAV file playback does not resume | 2010-03-05 | Jeffrey Goode | 2010-03-22 | 2 |
Task Description
WAV files do not resume from “Resume Playback” or from bookmarks. Instead, they start from the beginning. This is a recent bug, I suspect dating from the wav codec update a couple of weeks ago. Current build is r25028.
|
|
11719 | Bugs | Music playback | Very Low | 48Khz FLAC and ALAC playing slow | 2010-11-04 | Thomas Brunoli | 2011-02-03 | 2 |
Task Description
When playing any lossless track that has a 48Khz sampling rate, rockbox incorrectly shows the song time longer than it actually is, and plays it slowly. E.G. Hurt by Nine Inch Nails is shown to be and plays for 6 minutes and 50 seconds, but it is actually 6 minutes 17 seconds
|
