I think we should start a new thread with alpha11 bugs. Peter, is there a chance we see a new alpha soon?

Let's start:
AF does not work for predefined stations (it does not search for AF at all), but works perfect if you search by the left / right buttons.

Selecting a frequency by remote control (search button) still crashes my player in two of three cases. (sigkill)

I had a reboot (sigkill) on my short 10 minute trip today (in tuner mode)

Here is the tracedump for the sigkill event (changing frequency by remote control). Just in case someone can do something useful with it:

player(79): user memory violation at pc=0x02002d08, lr=0x02002d0c (bad address=0x00000029, code 2)
pc : [<02002d08>] lr : [<02002d0c>]
sp : bd3ffcb0 ip : bd3ffcc0 fp : bd3ffcbc
r10: bd3ffcf8 r9 : bd3ffd08 r8 : bffffe38
r7 : bd3ffd0c r6 : 021e0a08 r5 : 021f43a8 r4 : 021f43a8
r3 : 00000001 r2 : 00000000 r1 : 00000001 r0 : 0225a6b0
Flags: nzCv IRQs on FIQs on Mode USER_32 Segment user
Control: D8E7517D Table: D8E7517D DAC: 00000015
Function entered at [<02002cf4>] from [<02052eac>]
Function entered at [<02052e68>] from [<0206d248>]
r5 = BD3FFCF0 r4 = 021E0A08
Function entered at [<0206d22c>] from [<0206d548>]
r4 = BD3FFD08
Function entered at [<0206d380>] from [<0206d2a4>]
r10 = 020DEA00 r9 = 021E0A08 r8 = 00004C14 r7 = 00000080
r6 = 00000014 r5 = BD3FFD4C r4 = 021E0A08
Function entered at [<0206d294>] from [<020dead4>]
Function entered at [<020dea9c>] from [<020dea8c>]
r5 = 021D40FC r4 = 021E0A08
Function entered at [<020dea00>] from [<0211c970>]
r5 = 021E0A20 r4 = BD3FFE40
Function entered at [<0211c8a8>] from [<0215334c>]
r4 = 00000000
Function entered at [<02151ac0>] from [<0211c6ec>]
r8 = 021E9224 r7 = 021E9210 r6 = 020DEA00 r5 = 00000005
r4 = 00000000
Function entered at [<0211c63c>] from [<0215334c>]
r5 = 00000000 r4 = 00000000
Function entered at [<00000074>] from [<021d1a28>]
Function entered at [<e39ffff4>] from [<eb000a3f>]
Function entered at [<2a00fef4>] from [<2a00ff00>]
Unable to handle kernel paging request at virtual address 2a00fef8
memmap = D8E74000, pgd = c3e74000
*pgd = 00000000, *pmd = 00000000
Internal error: Oops: 2
CPU: 0
pc : [<c00e3d90>] lr : [<c00198f0>]
sp : c2887f44 ip : c2887f00 fp : c2887f90
r10: 00000002 r9 : c3ecd0e0 r8 : 0000000c
r7 : 00000000 r6 : 2a00fef4 r5 : 2a00ff00 r4 : ea000030
r3 : 60000013 r2 : c0104284 r1 : 00000001 r0 : ea000020
Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment user
Control: D8E7517D Table: D8E7517D DAC: 00000015
Process player (pid: 79, stackpage=c2887000)
Stack:
c2887f20: c00198f0 c00e3d90 60000013
c2887f40: ffffffff c3ecd0f8 c3ecc560 c2886000 c2887fb8 00000029 c0011b88 02002d0c
c2887f60: 00000029 00000002 c2887fb8 0000000f 00000029 00000000 00000002 bd3ffd08
c2887f80: bd3ffcf8 c2887fb4 c2887f94 c00120e4 c0011928 c010297c 021f43a8 021e0a08
c2887fa0: bd3ffd0c bffffe38 00000000 c2887fb8 c000a0c8 c001200c 0225a6b0 00000001
c2887fc0: 00000000 00000001 021f43a8 021f43a8 021e0a08 bd3ffd0c bffffe38 bd3ffd08
c2887fe0: bd3ffcf8 bd3ffcbc bd3ffcc0 bd3ffcb0 02002d0c 02002d08 20000010 ffffffff
Backtrace:
Function entered at [<c001191c>] from [<c00120e4>]
r10 = BD3FFCF8 r9 = BD3FFD08 r8 = 00000002 r7 = 00000000
r6 = 00000029 r5 = 0000000F r4 = C2887FB8
Function entered at [<c0012000>] from [<c000a0c8>]
r8 = BFFFFE38 r7 = BD3FFD0C r6 = 021E0A08 r5 = 021F43A8
r4 = C010297C
Code: ebfcd653 e2440010 (e5961004) e1a035a1 e59f20cc

After the upgrade, I've had trouble connecting to both players from emplode 2.10 via serial. I can connect fine through hyperterminal. Can anyone else verify this?

I was able to wedge the player twice by fast-forwarding in a song too long last night. When I go out again in a bit I will try again over more songs.

Said song was encoded with lame, uniform bitrate.

RTFRN:

Quote:

* Known Issues

Long bursts of fast-forwarding or rewinding can cause a lockup.

I'm now running A11 on my main unit, and I'm not positive if this audio glitch was in the previous alphas, but when toggling the pause mode on a mp3, I hear a faint pop in the audio playback. Can anyone else confirm this?

I've got crossfade on 0.5s, that's really the only 3.0 unique setting I've enabled.

The long down press in the playlist menu functionality seems to be borked in A11 (the "go back to last playlist menu" option).

The normal behavior is that when I'm at the playlists menu, a long downpress brings me to the last place I originally was browsing in the playlist (the last album, artist or song I select. From there, you can then select a new song/artist/album/whatever and then go into the enqueue/append/replace menu.

The behavior now skips the last playlist entirely and drags me straight to the enqueue menu, and in fact auto selects enqueue, resulting in a duplicated playlist. Looks like the intermediate keypresses are just "assumed"

-- Gary F.

how come i can use my emplode. It gives me a database error when trying to sync database of mkII.

I was just on my way into work, and I was listening to Del Tha Funkee Homosapien (Both Sides Of The Brain), and track 14 (Catch all This) came to an end and all I heard was some really nasty noise. I looked at the Seek Tool, and noticed it was about 5 seconds past the end of the track and still playing. So I skipped ahead, and the next track started to play. So I rewound back to the end of the previous track and it did the same thing again.

So I just skipped ahead to track 15 again, and was listening to that. However, at the end of that track the player completely froze (except hijack, did the reboot machine, I did check the Vital Signs before rebooting, and the player was at about 3.5, 3, 2 for the load averages) and played that track again. Same thing at the end of track 15 (Phoney Phranchise).

After I get home to my empeg power brick. I'll grab those songs off my empeg. What programs should I use to analyze these tracks? Or should I just upload them so the empeg guys can download them?

I've noticed a couple of problems since switching to v3a11.

1. When listening to the Tuner in the car the audio muting (for car phone etc) dosn;t work. It works perfectly when in player mode. I've note yet tried the tuner with any other versions of the software so can't really say if this is a bug specific to v3a11 or more of a "feature"

2. Some times the player randomly moves on to the next track part way through the current one. Going back to the skipped track normally results in it playing to completion

ISTR that there's a setting for what mute does while in Tuner mode. Maybe that got reset? Or I could just be making stuff up.

Had an interesting bug I have not managed to pin down yet - doesn't appear to be connected to a particular track or playlist, and isn't repeatable deliberately, but sometimes when the end of the track is reached, something seems to hang.

Functionality appears perfect, except nothing plays - the song remains at the end, and the timestamp is the last second of the song. If it is at the end of a 3 minute 25 song, and I skip forward or back, it goes to 3:25 in the next song and does nothing. I have not yet managed to get a log as it has never done it when I have it hooked up at home (although in the dock it does think it is in the car)

Only solution is reboot through hijack which works every time.

First time I have seen this bug(for A11), so I figured I better mention it. Yesterday I had the infamous source switching happen. First time with A11, which I've been running since it was released. It happened the same as when the bug was in previous alphas. Revoving, and reinserting the player fixed it.

Long down press on 'Playlists' (to take you to the last selected playlist) seems to go too far (and select 'Replace') on my empeg with 3a11. Anyone else confirm this?

Yup. Although mine seems to Append rather than Replace. This isn't new in v3a11 though. I think it has existed in all the v3 alphas.

It doesn't always do it though. Sometimes it works OK. It seems to work better if the drives are already spun up.

When the player is caching (small dark hdd icon in upper right), if I try to set a bookmark, it is not saved properly. When I try to go to that bookmark, I come up with an empty playlist. If I wait for the hdd icon to dissapear and then save the bookmark, it works every time.

Changing volume while empeg is caching for the first time after startup often produces a sigkill.

3.0a11 mk2a 32M 2x30G Hijack v440

I've been running a11for a couple of months I guess. Today it all went wrong. All was well when I went to work. On coming home the unit just kept rebooting. It would boot to showing the track playing (but not actually, and duration not changing, buttons unresponsive) and after a variable amount of time reboot. This it continued to do until pulled from the sled. The unit was very hot at this point. This behavior contued even fter the unit had been reinserted when cold. Same thing when plugged into the mains. V2 final now installed and all is well.

Running A11, has the same as the last poster, no big problem, just re-booted and fine.

Randomly the software hung at the end a track, manual reboot(read as taking out of sled live, and re-inserting), unit went through the boot sequence, then instantly hung on the track again. Manual reboots, and from within hijack do nothing. Had to bring it indoors and as soon as it booted up Pause it, then re-boot, then hold to standby, then pic another play list on resume. Unit was playing a 20 song mp3 playlist on shuffle.

Unfortunately there is a bug in 3.00 alpha 11, Receiver Edition only, such that it doesn't do this -- it doesn't adequately randomise the xid on boot, so two Receiver Edition car-players on the same network both get the same xid, and thus any attempt by the DHCP server to assign an IP address to either one of them, is actioned by both, so both get the same IP address. Which is bad.

There are some workarounds:

• Give static IP addresses to Receiver Edition car-players. Note that you can't switch a car-player from DHCP to static while Receiver Edition is on it; you need to temporarily reinstate the Standard Edition.
• Partition the network somehow, so that broadcast packets don't reach both players; this is likely to need features that domestic switches don't have.
• Whenever you're powering-on a Receiver Edition car-player, temporarily unplug the others from the network.
• Using the serial port, Ctrl-C and restart the player on all the units (or, technically, all but one). When the player restarts, it will pick a new random xid and thenceforth[1] be capable of obtaining a unique address.

This bug was probably my fault, sorry

Peter

[1] Tanstaafl is right, using a word that the BBS hasn't seen before is harder than you'd think.

Even by editing config.ini directly?

Also: What impact would this have on a network that contains both Rio/Dell Recievers, *and* one or more car players running Receiver Edition?

That would work fine. I just meant that the "normal" car-player method of changing it, using Emplode, doesn't apply.


Receiver Edition only interferes with other Receiver Editions, not with real Receivers of either variety. And multiple real Receivers all DHCP'ing on the same network is extremely well-(at)tested.

Peter

Thanks for those clarifications. :-)

Can this be patched (one or two bytes) in the binary ?

I can't foresee so, no. Some extra code would need adding, there's no patch-one-instruction fix I can think of. And of course I don't have access to the source any more (it's not even clear who does -- probably Freescale), so even if I could figure out somewhere to logically patch, it'd be hard to convert that idea into an actual patch. For now (and there aren't AFAICT all that many users of Receiver Edition) it'll have to be the workarounds.

Peter