Bugzilla – Bug 14489
Touch/Baby reboots sporadically, in relation to WMAs
Last modified: 2010-04-08 17:24:31 UTC
For the last few weeks and up to 7790, The fab4 reboots sporatically towards the end of songs (WMA are the only I have tested, I don't have MP3s in my library). I cannot get through more than 3-6 songs before a reboot. If a reboot occurs, it goes into a reboot loop and requires a factory reset with the remote. Curiously, after the last factory reset, I experienced a reboot while browsing the menus before playing music- but this was the only time this has happened to me. As far as I can tell, I did not have issues listening to Soma.FM (MP3 stream I believe). I have been told the WMA logging bug from last month is resolved, so Andy requested I file a new bug. Let me know if you need anything else. I am uploading a zip with an album that replicates the problem for me, will post back with a link.
This zip has WMAs that should reproduce this, put it on repeat. I can't replicate it on command, it seems more related to how long you've played WMAs for. http://fiveninesmusic.com/music/testing.zip
== Auto-comment from SVN commit #6467 to the player repo by richard == == https://svn.slimdevices.com/player?view=revision&revision=6467 == Bug #14489 Fix handling of wma metadata. Reviewed by andy.
Should this have fixed the problem on BABY pb1 as well? I'll test tonight.
On the touch 7832 I am still having this issue. What version should I see this issue resolved?
Also still having issues with Baby PB1 7790 and WMAs
Fred please retest on 7.4.1 firmware and reopen if you still have the crash.
Tested with SP r7847, SBS r28848 have not had any issues yet
Got through just about 4 WMA songs before it rebooted. Now it's in a reboot loop. Using firmware 7861 on the fab4. Will locate MP3s and see if this is also a problem. Any ideas?
Mp3s, Rhapsody and Sirius do not cause this problem. Only WMAs.
Fred, is it the same wma files that cause the crash? Can you post new examples, thanks.
Richard, it isn't consistent, it doesn't seem to follow any rules, it just happens while playing any of my WMA files. The ones above have definitely replicated it before. I just went through the steps again, started playing an album. I got through almost 9 songs (crashed at the end of song 9 [Staring at the sun]). I have included the song it crashed on, and the one it was about to play. It was going from: Staring at the Sun to Horsey Horse Remix FYI, I do have crossfade on at the moment, but it hasn't made a difference, the bug from what I can see still happens with crossfade off. http://fiveninesmusic.com/music/testing3.zip It doesn't happen in the same place each time.. it's almost as if it's filling up an error log or something in the background, until it runs out of room and then crashes. After a few reboots it may come back, but the interface is VERY VERY slow until I do a factory reset.
Actually, now that I've tested this again, it looks like it's very consistent with the last 9 seconds of Staring at the Sun, I can always replicate it on this track. Just tested this track with the Duet, no problems on there. This track does in fact crash the SB Radio too.
== Auto-comment from SVN commit #6513 to the player repo by richard == == https://svn.slimdevices.com/player?view=revision&revision=6513 == Bug #14489 Fix WMA to not crash for large clock objects in the metadata.
== Auto-comment from SVN commit #6515 to the player repo by richard == == https://svn.slimdevices.com/player?view=revision&revision=6515 == Bug #14489 Fix wma decoder buffer size (optimization).
The decoder was choking on 'Horsey Horse Remix'. We start decoding the track about 10 seconds before the previous one ends, so any problems around that time is usually with the next track. The bug with these tracks is with the meta data handling. Fred where did you get this tracks and have you used any meta data editors with them? This case is fixed, but I can't be sure there is another bug lurking.
(In reply to comment #15) > The decoder was choking on 'Horsey Horse Remix'. We start decoding the track > about 10 seconds before the previous one ends, so any problems around that time > is usually with the next track. > > The bug with these tracks is with the meta data handling. Fred where did you > get this tracks and have you used any meta data editors with them? > > This case is fixed, but I can't be sure there is another bug lurking. I believe I ripped these tracks with windows media player, and some are from my brother (so I'm not sure his source), but at one point I did run a tag "fixer" which I got limited results with. I've also used audioshell in windows xp to embed cover art.. http://www.softpointer.com/AudioShell.htm I'll download the latest firmware and keep testing! What firmware revision am I looking for? Also- I have to add, that I haven't edited the tags or embedded art (I believe) in a long time, and I've never had this issue with the fab until around august.. Although now that I think about it, some programs silently change my tags, I can't guarantee that MusicIP mixer or Windows Media Player on my PC haven't messed with the tags either.
I just spoke with my brother, he did get most of his WMAs from the Rhapsody Music store before they sold MP3s. (He may have used a certain software to utilize his fairuse for his legally purchased WM). I don't know if these files were mine or his.
Fred: can you try build 7.4.1 r28948 to see if it resolves the issues you are having? I have tested here with a bunch of WMA's (the above version) and that appears to resolve the issue for me
So Far it appears this bug is fixed on the fab (Haven't been able to get my baby to update successfully, although it wants to). I tried the song in question and also played a random assortment. I will keep testing. Out of curiousity, what part of the meta data was causing the crash?
This bug has been marked as fixed in the 7.4.1 release version of SqueezeBox Server! Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
I'm still seeing this on my Touch, most often with BBC and Napster WMA feeds.
(In reply to comment #21) > I'm still seeing this on my Touch, most often with BBC and Napster WMA feeds. Sorry, forgot to mention i am on 7929.
Created attachment 6229 [details] File that makes it crash It appears the bug is still around for the baby and fab on the following sources: WMA files (not the same ones as before) The attached WMA does the trick Sirius Radio (at times, not always): I only listen to 90's on 9. Don't know if other channels do the same
Also- a dupe here: https://bugs-archive.lyrion.org/show_bug.cgi?id=14949
*** Bug 14949 has been marked as a duplicate of this bug. ***
Just to add, i see and immediate crash with every WMA source i have tried - local files, Napster, WMA internet radio feeds etc. Still seeing this as of r7956
Just to add: I'm seeing this, too, when streaming Napster. Paul Weller at the BBC in this case, unfortunately I can't tell you which track, the playlist now stands at #9 (Out of the sinking, Lunchtime show 1.11.94) but may have skipped a few times.
While testing another bug, I ran into this issue. Serial Log shows the following: --------------- Program terminated with signal SIGTRAP, Trace/breakpoint trap. The program no longer exists. Full log to be attached
Created attachment 6326 [details] serial log
One more data point for failure -------------------------------- Program received signal SIGSEGV, Segmentation fault. luaS_newlstr (L=0x498008, str=0xbee96438 "¼\200I", l=1) at lstring.c:86 86 lstring.c: No such file or directory. in lstring.c
Can you take a look, Alan?
This may be fixed in the latest firmware I'm testing for Rhapsody issue. So far my Touch has not rebooted with this firmware. Felix: do you think the rhapsody fix may address this issue too?
James: were you playing WMA or just Rhapsody?
(In reply to comment #32) > This may be fixed in the latest firmware I'm testing for Rhapsody issue. So > far my Touch has not rebooted with this firmware. > > Felix: do you think the rhapsody fix may address this issue too? I don't work here, so I'm the least qualified to make this statement, but I was under the impression that Rhapsody used MP3 now. I can say my touch & Baby work almost perfectly with rhapsody, whereas my WMA library is riddled with crashes.
Andy/Fred: your right, I forgot Rhapsody is MP3 now. Ignore my statment
*** Bug 15216 has been marked as a duplicate of this bug. ***
revise estimate
Update hours
Probably caused by 15152. Not sure if there are other causes.
r8337, which is the fix for bug 15152 is in the latest nightlies. There is a good chance that this will fix most of the problems with WMA too.
(In reply to comment #41) > r8337, which is the fix for bug 15152 is in the latest nightlies. There is a > good chance that this will fix most of the problems with WMA too. Not so much luck. Although it appears to maybe be better (that is I can sync the touch and radio and play WMAs without it completely failing altogether), I definitely still have an issue. I just played a 40 track Music IP mix, All WMA. It rebooted at track 1 half way through. What was weird was right before the reboot, I saw a screen distortion, a bit of colored pixels right behind the artist name on the now playing screen. Then it froze, and rebooted. The radio did not reboot at that point (synced). I tried replaying the song but no issues at that same point. This is the first reboot in over a month (all I normally play is rhapsody).
void prvFFT4DCT(Void *ptrNotUsed, CoefType data[], Int nLog2np, FftDirection fftDirection) { I32 np = (1<<nLog2np); np derived from parameter nLog2np (passed in r2) and stored in s20 as part of following code: 00094404 <prvFFT4DCT>: 94404: e92d4ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, lr} 94408: ed2d8b06 vstmdb sp!, {d8-d10} 9440c: e352000f cmp r2, #15 ; 0xf 94410: e1a00002 mov r0, r2 94414: e24dd07c sub sp, sp, #124 ; 0x7c 94418: e58d1038 str r1, [sp, #56] 9441c: e3a01001 mov r1, #1 ; 0x1 // r1 <- 1 94420: e58d3034 str r3, [sp, #52] 94424: e1a03211 lsl r3, r1, r2 // r3 <- np = 1 << nLog2np 94428: ee0a3a10 fmsr s20, r3 // s20 <- np Crash occurs in fft.c:prvFFT4DCT() line 545: Observations from inspection with gdb: r6 = i = 508 r4 = j = 1016 r8 = n2 = 512 // should be np/2 r10(sl) = 4100 = n21 * 4 // n21 should be np + 1 // these both imply np == 1024 // np derived from parameter as (1<<nLog2np) and held in temporary s20 // but cannot inspect s20 because gdb not capable // which => nLog2np == 10 [sp, #56] = CoefType data[] = address of block of size 0x1000B (4096B) == 0x42038020 [sp, #52] = 0 = fftDirection Current return address is 0x940a0 Looking up call stack, fft.c:prvFFT4DCT() was called from fft.c:auDctIV() line 1540 pfnFFT(pFFTInfo, rgiCoef, (fPowerOfTwo ? nLog2SB - 1 : iFFTSize), FFT_FORWARD); 94068: e59de05c ldr lr, [sp, #92] 9406c: e35e0008 cmp lr, #8 ; 0x8 94070: 0a00008a beq 942a0 <auDctIV+0x520> 94074: e59d2034 ldr r2, [sp, #52] // fPowerOfTwo == 1 94078: e59d00b4 ldr r0, [sp, #180] // pFFTInfo 9407c: e3520000 cmp r2, #0 ; 0x0 // fPowerOfTwo <=> 0 94080: e59d1030 ldr r1, [sp, #48] // r1 <- rgiCoef 94084: 159d305c ldrne r3, [sp, #92] // if (fPowerOfTwo != 0) {r3 <- nLog2SB == 9} 94088: e59dc0b0 ldr ip, [sp, #176] 9408c: 12433001 subne r3, r3, #1 // if (fPowerOfTwo != 0) {r3 <- r1 -1} 94090: 158d3044 strne r3, [sp, #68] 94094: e3a03000 mov r3, #0 ; 0x0 // r3 <- FFT_FORWARD == 0 94098: e59d2044 ldr r2, [sp, #68] // == 8 9409c: e12fff3c blx ip [sp, #92] = nLog2SB == 9 parameter rgiCoef passed in r1 from [sp, #48] == 0x42038020 parameter 3 (fPowerOfTwo ? nLog2SB - 1 : iFFTSize) passed in r2 via [sp, #68] == 8 All this says that nLog2np parameter of fft.c:prvFFT4DCT() should be 8 but evidence of values derived from np (n2, n21), and that loop counter i has value 508, suggest that it was 10. Somehow it must have been corrupted before the start of the loops at fft.c line 525. I have been unable to find any way that s20 (or d10) could have been corrupted.
== Auto-comment from SVN commit #6671 to the player repo by ayoung == == https://svn.slimdevices.com/player?view=revision&revision=6671 == bug 14489: work around: use -O0 for WMA fft.c module
== Auto-comment from SVN commit #6672 to the player repo by ayoung == == https://svn.slimdevices.com/player?view=revision&revision=6672 == bug 14489: work around: use -O0 for WMA fft.c module
== Auto-comment from SVN commit #8451 to the jive repo by ayoung == == https://svn.slimdevices.com/jive?view=revision&revision=8451 == bug 14489: work around: use -O0 for WMA fft.c module
Downgrading to P3 on the basis that the workaround is sufficient.
Marking fixed. Bug 15607 can be used to track any remaining issues.
This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release. If you are still seeing this issue, please let us know!