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

Okay, thanks. If the userbase ever becomes significant (more than 2?), then perhaps we could just have Hijack modify the DHCP packets as they pass through.

Cheers

This bug is also present in the regular car2-v3alpha11 load as well, so now I *really* want to squash it.

I suppose I'll have to have Hijack replace the CID on outgoing DHCP packets -- and probably put the old CID back again on incoming ones that match, right ?

Here's the wireshark trace. First, a short summary for those with good eyesight, and then an attached binary blob that can be reloaded back into wireshark for viewing/interpretation.

A more readable copy of the image below is available here.

One problem seems to be that the empeg's bootp request has the "broadcast bootp flag" set, so the server must use broadcast when replying.. and that reply then gets picked up by all other empegs on the subnet.

Most of the other DHCP clients here do not set that bit, so the server sends a targeted response to them.

I could try having Hijack clear that bit on the outgoing packet, and see if the empeg copes with it.

-ml

Mmm.. I suppose that trace is not quite complete -- used a switch during the capture. It still illustrates the problem (two players claim the same IP address, even though they were assigned different IP addresses by DHCP), but not the complete sequence.

So for completeness, I'll later hook up a shared hub and run Wireshark from there to get all of the packets.

Cheers

Hmmm... I do remember now that we set that bit for a reason -- we found a situation (perhaps it was a particular server) where it didn't work without the "broadcast replies" bit set. Still, that was the last remaining bit of the puzzle. You'll notice that your captured packets 3 and 8 (OFFER replies from the server aimed at the two clients) have the same xid in (Wireshark: "Transaction ID"), but different chaddr (Wireshark: "Client MAC address"). The Empeg, utterly incorrectly, matches on the former but not the latter.

So I suspect that checking incoming UDP to port 68 (bootpc) and dropping on the floor (or scrambling the xid of) packets whose chaddr isn't ours, would fix the problem.

Peter

Yes, that certainly does seem to fix things.
Hijack v501 is now released, with this workaround incorporated.

Thanks, Peter!

Of course, I have hardcoded the packet offset for the client MAC address -- to match where my own DHCP server puts the data.

But I have no idea if it is *always* at that exact offset, or whether more intelligent parsing of the packet is necessary to ensure it works everywhere (?).

EDIT: A consequence of which, is that DHCP might not work for anyone but me.

Cheers

According to RFCs 951 & 2131, the offset is constant, so no worries.

But just in case someone wants to run a DHCP *server* on the empeg, it might be slightly safer to also check the bootp message type field as well.. as is now done in Hijack v502.

Cheers