I just wanted to mention that the bug I originally found in 2.0b11, and posted here is still active in 2.0b13. Easy to reproduce, just press the "search" button in tuner mode twice. On my empeg, once I do this, visuals slow down and I can't play MP3's, among other quirky behavior.

Any notes on this bug in the internal bug database?

It's still in the bug database as number 1817 and has not been touched yet.

Okay, I've just given Santa's elves a nudge regarding this one.

Hip-hip hooray!

Hey, don't horray for me. All I did was nudge one of the elves. If they're busy making toys for all the other good boys and girls, it doesn't really make a difference, does it?

Besides, I may have nudged the wrong elf anyway. I'm told the tuner elf is on holiday.

Yeah well a nudge is a nudge, I'll take what I can get. I know this isn't the biggest bug in the world but it gets me from time to time.

Toby can probably fix it up, but he is indeed on holiday. He implemented correct RDS AF and TA support recently, which we can release when we iron out a few bugs.

Rob

Can you nudge someone about that "using the clock makes the player software crash"? I'm tired of my wife snagging me

Is that confirmed to be a software bug?

Tell me how to confirm it. I have 2 units. Both exhibit the behavior. The player software resets but the player does not reboot, in both cases. This sort of limits what I can do.

Since no one commented on what "confirmation" means, well, I can't very well do that. I did however have some fun with strace. Started the player and enabled "clock". This is with HiJack but I tried it last night with a stock 2.0b13 as well.

Anyhow, strace offers:
rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
rt_sigsuspend([]player(142): memory violation at pc=0x0207b538, lr=0x02073a94 ()
pc : [<0207b538>] lr : [<02073a94>]
sp : bdfffc08 ip : bdfffc18 fp : bdfffc14
r10: 00000020 r9 : 00000000 r8 : 0214fdb0
r7 : 021b9aa8 r6 : 00000000 r5 : 02169108 r4 : bdfffc64
r3 : 021d10f8 r2 : 00000000 r1 : 021d0f48 r0 : bdfffc64
Flags: nzCv IRQs on FIQs on Mode USER_32 Segment user
Control: C0E5117D Table: C0E5117D DAC: 00000015
Function entered at [<0207b520>] from [<02073a94>]
Function entered at [<02073a48>] from [<0201a678>]
r4 = 02118BC4
Function entered at [<0201a1d8>] from [<02067804>]
r10 = 0214FC04 r9 = BDFFFD0C r8 = BDFFFD20 r7 = 0214FDB0
r6 = 02167BA4 r5 = 00000001 r4 = 02167B00
Function entered at [<02067774>] from [<020647c8>]
r7 = BDFFFD1C r6 = 0214FB28 r5 = 0214FDB0 r4 = 0214FB28
Function entered at [<0206476c>] from [<02064f50>]
r5 = 0214FC04 r4 = 0214FB28
Function entered at [<02064f24>] from [<0206526c>]
r4 = 00000000
Function entered at [<02065030>] from [<02064f88>]
r10 = 020AAF94 r9 = 0214FB28 r8 = 0000340E r7 = 00000080
r6 = 0000000E r5 = 0214FB28 r4 = BDFFFD64
Function entered at [<02064f78>] from [<020ab04c>]
Function entered at [<020aaf94>] from [<020b18b0>]
r5 = 0214FB40 r4 = BDFFFE40
Function entered at [<020b17e8>] from [<020e6c4c>]
r4 = 00000000
Function entered at [<020e53c0>] from [<020b162c>]
r8 = 021530D4 r7 = 021530C0 r6 = 020AAF94 r5 = 00000007
r4 = 00000000
Function entered at [<020b157c>] from [<020e6c4c>]
r5 = 00000000 r4 = 00000000
Function entered at [<021c9f14>] from [<00000003>]
<unfinished ...>
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

I'm sure you've said elsewhere, but refresh our memories. Exactly how do you reproduce this?

(Regardless, a segmentation fault is pretty damning.)

Actually I guess this is a good time to delve into kernel source and see if I can figure out what's going on.

Guessing, purely based on function pcs, it looks like it has absolutely nothing to do with the kernel. But I could be wrong.

Use the "1" button on the remote to set the time field to "(clock)". Wait for the player software to die.

Guessing, purely based on function pcs, it looks like it has absolutely nothing to do with the kernel. But I could be wrong.

Well, I didn't think it had anything to do with the kernel, particularly, but i do want to figure out what was going on. If I can do something evil to work around the problem in the kernel, I'm not averse to that.

Well, I didn't think it had anything to do with the kernel, particularly, but i do want to figure out what was going on.

According to that backtrace it's falling over in std::string::terminate(). There's nothing you could do in the kernel to fix that. I'll look into it.

Peter