Bugs? *What* bugs?

Posted by: peter

Bugs? *What* bugs? - 25/03/2003 12:54

If anyone out there is "sitting on" good, solid bugs in 2.0 beta 13, or, for the alpha team, 2.0 RC2, and wondering whether to bother reporting them, then now would be a really good time.

It makes our lives easier if bugs are easily repeatable, and if they are verified to exist on freshly-upgraded beta 13 or RC2 without any third-party software[1]. (It also makes our lives easier if bugs are easy to fix, but that's less under your control.)

Many thanks,

Peter


[1] That's not meant to disparage all the fine third-party software out there. But if every bug we work on were reported on a player with a different combination of Hijack, Emptris, GPS stuff, whatever, then it would make our verification job a nightmare.
Posted by: tfabris

Re: Bugs? *What* bugs? - 25/03/2003 13:09

To anyone responding to this thread:

Let's assume, hypothetically , that the Cambridge guys were going to have a pizza night to work on a select few remaining bugs before 2.0 goes final...

Knowing that they have a limited time to work on it (i.e., not any time to try to try to track down intermittent hard-to-reproduce bugs), what are the top ones on your list? I'm guessing that they aren't going to have time to fix everything, just the biggest remaining show-stoppers. And I mean: "this is definitely a bug, it's not a feature change, it is easy to reproduce, and I haven't seen it reported as being fixed in the current internal build yet."

Here is an example of the kind of bug I'm talking about:

"If you press the search button more than once in Tuner mode, it will lock up the player software". (That's a real one that's on the internal bug list.)

That's the sort of thing they'd be able to work on during this hypothetical pizza-and-bugfix session.
Posted by: peter

Re: Bugs? *What* bugs? - 25/03/2003 13:26

what are the top ones on your list? I'm guessing that they aren't going to have time to fix everything

That'd be useful information, but what I'm really after right now is flushing out any new bugs that haven't yet made it into the bug database at all -- which, thanks to Tony's continued efforts, means bugs which haven't been reported here in the Bugs forum (or to the bugs@empeg.com address). With the somewhat slow pace of releases recently, I can imagine people feeling that there's no particular hurry to report a bug. It'd be good to get such bugs reported now, please!

If you reported a bug against a really old version (say, before beta 10) and it's still not fixed in beta 13 or RC2, that might also be worth mentioning here, as such old bugs can sometimes disappear over my horizon.

Peter
Posted by: wfaulk

Re: Bugs? *What* bugs? - 25/03/2003 13:29

The only outstanding bug that really bothers me is the poor volume ramp-up on start.
Posted by: tonyc

Re: Bugs? *What* bugs? - 25/03/2003 13:30

The biggest bug I've seen is that the cross-fading feature doesn't work.
Posted by: tfabris

Re: Bugs? *What* bugs? - 25/03/2003 13:31

The biggest bug I've seen is that the cross-fading feature doesn't work.
/me thwaps _ynot.
Posted by: loren

Re: Bugs? *What* bugs? - 25/03/2003 14:30

I second Bitt's most annoying bug report.

That and the fact that if you turn off the ignition, keep the player playing, then restart the car, the empeg reboots but won't play any sound.... that's an oldie and i can't recall the reason behind it... was it an amp thing??

Sorry, i know that's not a new one...
Posted by: SE_Sport_Driver

Re: Bugs? *What* bugs? - 25/03/2003 16:00

In reply to:

and I haven't seen it reported as being fixed in the current internal build yet."




This list of reported bugs isn't public correct?
Posted by: mlord

Re: Bugs? *What* bugs? - 25/03/2003 16:07

Not a show stopper, but I really wish the volume control could be restored to it's former "spunkiness", from it's current plodding state.

Pre beta13, it (using remote) used to ramp the volume up/down quickly, but nowadays it takes *forever* to perform a substantial increase/decrease in listening level.

Like I say, not a show stopper, but if you happen to know what to fix..

Cheers
Posted by: SE_Sport_Driver

Re: Bugs? *What* bugs? - 25/03/2003 16:38

Would be a nice comprimise if the remote made the volume change quickly but the knob allowed fine tuning.
Posted by: tonyc

Re: Bugs? *What* bugs? - 25/03/2003 17:05

Pre beta13, it (using remote) used to ramp the volume up/down quickly, but nowadays it takes *forever* to perform a substantial increase/decrease in listening level.
Hmm, I've found that using the trusty old irtrans trick of assigning the volume up button to Vol+,Vol+,Vol+,Vol+,Vol+ seems to make it fast enough for me.
Posted by: tfabris

Re: Bugs? *What* bugs? - 25/03/2003 21:04

That and the fact that if you turn off the ignition, keep the player playing, then restart the car, the empeg reboots but won't play any sound....
They were never able to reproduce that particular problem. They've said they think that's fixed in the current internal build. But before this fix went in, I stopped being able to reproduce it with my car, so I have no way of being able to reliably test it for the alpha team. So I can't independently verify the fix.

.... that's an oldie and i can't recall the reason behind it... was it an amp thing??
No, it was the DSP's "mute" flag getting opposite-toggled and desynchronized from the "pause" function.
Posted by: StigOE

Re: Bugs? *What* bugs? - 25/03/2003 22:24

Could this also be the problem when using a handsfree set for the phone (when pausing the player after answering the phone and forgetting to unpause before hanging up makes mute and pause out of sync)? This is 100% reproducible on my Mk IIa with 2.0B13/Hijack 300 (no extras...yet...)

Stig
Posted by: xanatos

Re: Bugs? *What* bugs? - 25/03/2003 22:25

Here are the "Quirks" / "Bugs" I have noticed and I'm not sure if they have been mentioned or fixed.

2.0b13

When shutting off the car, the player will occasionally keep playing for 5 to 60 seconds and then shut off. I don't know if I pulled out the key to fast and It didn't notice the car was off or?

When the disk is spun up or there is a higher load (usually when I'm switching songs or after boot up), Volume does not respond immediately and can end up blowing my ears out because it will say a -30 while I'm turning and then Jump up to 0db.

Also, during suspected times of high load, it will not register clicks to the controls to advance (or decrement) the song. It can take 2 or 3 clicks before it registers.

But hey, these are prolly things that can't be worked out, and I pretty much have leared to live with them. Except I have this horible ringing in my years.
Posted by: tfabris

Re: Bugs? *What* bugs? - 25/03/2003 22:30

Those are good ones, Xanatos. I think they are all already fixed in the current internal build, but hey, it's the kind of thing we're looking for.

Anyone else ?
Posted by: tfabris

Re: Bugs? *What* bugs? - 25/03/2003 22:32

Could this also be the problem when using a handsfree set for the phone (when pausing the player after answering the phone and forgetting to unpause before hanging up makes mute and pause out of sync)?
Ooo, good question! ... Cambridge guys?
Posted by: peter

Re: Bugs? *What* bugs? - 26/03/2003 01:35

They were never able to reproduce that particular problem. They've said they think that's fixed in the current internal build.
Specifically, we weren't able to reproduce what we suspect is a race condition during player startup whereby mute and pause got out of sync. What we've fixed, and this should solve Stig's problem too, is that once mute and pause were out of sync, they used to stay out of sync. Now, pausing and unpausing forces the mute to the correct state (rather than blindly toggling it).

Peter
Posted by: Shonky

Re: Bugs? *What* bugs? - 26/03/2003 04:09

My tuner bug report earlier

Particularly number two in terms of real annoying. The others I can live with.

And I too would like a speedier volume control back. Perhaps a config option?
Posted by: Shonky

Re: Bugs? *What* bugs? - 26/03/2003 04:21

Ooh, ooh. Poor form I know to reply to my own post.

Sound dropouts while using the search function even on MP3s (i.e. not WAVs) as the unit searches. I think I may have narrowed it down to the fact that the drives spin down so quickly (like 5 seconds or something) - the spin up seems to cause the whole thing to pause momentarily

Alternatively, if someone can tell me how to disable the spindown stuff (I believe it's in the player code though), I will happily do that. I have no problem leaving the drives running and it will also help me when I skip to the next track and have to wait for the drives to spinup...
Posted by: justinlarsen

Re: Bugs? *What* bugs? - 26/03/2003 13:52

A bug I seem to have, and only comes about when i have 2 harddrives in the player, and a LARGE database is when i adjust the volume, it takes 3 or 4 seconds to responde, you can see tyhe problem with this is you keep turning it becuase u dont see it display the on the screen then it ends up going to full voume and when you try to turn it down its still delayed.

One other Problem is adjusting the EQ settings makes the music Jitter.

Im not sure if either of these is on the big list since i dont know where to look at it. but there something to think about.

Edit: sorry about the so called seemed typos, i really need to get new batterys in my keyboard it dosnt seem to respond like it used to . Please dont hit me Bitt.
Posted by: AndrewT

Re: Bugs? *What* bugs? - 26/03/2003 15:34

A bugi eem to have, and only comes about when i have 2 harddrives in the player, and a LARGE database is when i adjust the volume, it takes 3 or 4 seconds to responde, you can see tyhe problem with this is you keep turning it becuase u dont see it display the on the screen then it ends up going to full voume and when you try to turn it down its still delayed.

I have had similar problems with my 2-drive player when skipping tracks;

• Press 'next' while approaching the end of a song
The display immediately shows the next song in the playlist.
• Press 'next' a second time without delay
No change on the display.
• Press 'next' a few more times in order to get the player to respond
<10 seconds from the start of the whole process the player 'catches up' and skips a song for every 'next' button press
Posted by: loren

Re: Bugs? *What* bugs? - 26/03/2003 18:25

No, it was the DSP's "mute" flag getting opposite-toggled and desynchronized from the "pause" function.

ahhh... so after the car is started the DSP is muted, and if you hit the pause button, it unmutes, but it's paused, so no sound, and hit it again and it's unpaused but muted? Interesting.

This has happened since day one with me and i thought a bunch of people had reported it. no?
Posted by: StigOE

Re: Bugs? *What* bugs? - 26/03/2003 18:59

Sounds good...but even better would be if the player would, like other head-units I belive, pause the player instead of just muting it. Then I wouldn't even have had this problem in the first place....

Stig
Posted by: tfabris

Re: Bugs? *What* bugs? - 26/03/2003 19:38

ahhh... so after the car is started the DSP is muted, and if you hit the pause button, it unmutes, but it's paused, so no sound, and hit it again and it's unpaused but muted? Interesting.
Yes, exactly. If you listened carefully, you could hear a brief burst of music between the two states, for the brief instant it took between the unmuting and the pausing.

This has happened since day one with me and i thought a bunch of people had reported it. no?
A few people did report it, yes, but the guys in Cambridge couldn't reproduce that specific instance of it (happening on car starting). It seemed to have something to do with the way the voltage behaved on the ignition wire during an engine start. I could reproduce it for a while, then I did some rewiring work and suddenly couldn't reproduce it any more.

Like the man said, the pause/mute toggle won't get de-synched any more, but you might (not sure) have to press the pause key once to clear the situation if it does happen. At least that's better than having to power cycle...

Anyway, if you can reproduce the on-ignition-start version of the problem reliably now, I'd be curious to see if you can reproduce it after the next 2.0 version hits the street.
Posted by: loren

Re: Bugs? *What* bugs? - 27/03/2003 00:23

Anyway, if you can reproduce the on-ignition-start version of the problem reliably now, I'd be curious to see if you can reproduce it after the next 2.0 version hits the street.

as soon as it does, i will give it a shot. =]
Posted by: rob

Re: Bugs? *What* bugs? - 27/03/2003 08:49

So we fixed about a dozen bugs, and I'd say that about does it for 2.0. If RC3 checks out OK then there will be a public release soon.

Rob
Posted by: Ezekiel

Re: Bugs? *What* bugs? - 27/03/2003 09:04

WOOHOOO!

-Zeke
Posted by: peter

Re: Bugs? *What* bugs? - 27/03/2003 09:19

Sounds good...but even better would be if the player would, like other head-units I belive, pause the player [on cellphone activity] instead of just muting it.
In Emplode, File menu, Configure player, switch to Mute tab.

Peter
Posted by: SE_Sport_Driver

Re: Bugs? *What* bugs? - 27/03/2003 15:39

In reply to:

I think I may have narrowed it down to the fact that the drives spin down so quickly (like 5 seconds or something) - the spin up seems to cause the whole thing to pause momentarily

Alternatively, if someone can tell me how to disable the spindown stuff (I believe it's in the player code though), I will happily do that. I have no problem leaving the drives running and it will also help me when I skip to the next track and have to wait for the drives to spinup...




When I DJ, sometimes (depending on whether or not the song buffer is full or not) inserting or appending the playlist will cause the music to pause for a moment. It is WAY better than the last beta release, but is there a work-around I can use to keep the drives spun up? Maybe I could tell HiJack that I'm on DC but not at home to toggle this on? (Looks like I popped in too late for 2.00 final. )
Posted by: Roger

Re: Bugs? *What* bugs? - 27/03/2003 16:11

In config.ini:

[options]
spindown=0

Disables spinning the disk down. You don't need Hijack to do this.
Posted by: tfabris

Re: Bugs? *What* bugs? - 27/03/2003 16:14

The Developer Info Section Gnomes need to see this one...

Ooooo.... I'll bet you could put an ;@AC in front of that (if using hijack) and have it only happen on AC power... cool...

Question: Does it completely prevent spindown, or do the drive still spin down when it goes into standby?
Posted by: Roger

Re: Bugs? *What* bugs? - 27/03/2003 16:30

Dunno.
Posted by: tfabris

Re: Bugs? *What* bugs? - 27/03/2003 16:48

Easy enough to find out, I suppose. Let us know how it goes, Brad.
Posted by: SE_Sport_Driver

Re: Bugs? *What* bugs? - 27/03/2003 17:36

Will do. (I never used the @Home thing, so I'm reading up on that now.) Thanks Roger and Tony.

- VERY excited for 2.00final!
Posted by: mlord

Re: Bugs? *What* bugs? - 27/03/2003 17:48

And if you ARE using hijack, you must also add this:

[hijack]
spindown_seconds=0

Posted by: SE_Sport_Driver

Re: Bugs? *What* bugs? - 27/03/2003 18:09

How does this look? (Going for the drives to always spindown, except for @WORK)

[Options]
Name=Brad's empeg
;@HOME spindown=1
;@WORK spindown=0
spindown=1

[hijack]
;@WORK spindown_seconds=0
spindown_seconds=30
Posted by: mlord

Re: Bugs? *What* bugs? - 27/03/2003 18:12

Simplify it a bit:

EDIT: FIXED An ERROR!!

[Options]
Name=Brad's empeg
;@WORK spindown=0

[hijack]
;@WORK spindown_seconds=0

--------------------

OF course, there's also ;@AC and ;@DC, which may or may not be more appropriate than ;@WORK in your case.

Cheers
Posted by: SE_Sport_Driver

Re: Bugs? *What* bugs? - 27/03/2003 18:15

So if the player isn't set "@WORK" when it boots, it will skip my entries and go for the defaults (1 for spindown and 30 for timeout)?
Posted by: mlord

Re: Bugs? *What* bugs? - 27/03/2003 19:06

That's the idea!
Posted by: StigOE

Re: Bugs? *What* bugs? - 27/03/2003 20:35

Ah, have to check this out when I get home next week...Thanks.

Stig
Posted by: wfaulk

Re: Bugs? *What* bugs? - 27/03/2003 20:46

OF course, there's also ;@AC and ;@DC, which may or may not be more appropriate than ;@WORK in your case.
I've found, and I don't know if this is a feature or a misbug, that you can successfully combine the AC/DC qualifiers with the WORK/HOME qualifiers.
Posted by: mlord

Re: Bugs? *What* bugs? - 27/03/2003 20:57

That would be a documented feature, but it only works in one order: the AC/DC must be to the left of the HOME/WORK.
Posted by: wfaulk

Re: Bugs? *What* bugs? - 27/03/2003 21:06

So it is. I got lucky when I tried it, I guess.
Posted by: JrFaust

Re: Bugs? *What* bugs? - 27/03/2003 22:11

So we fixed about a dozen bugs, and I'd say that about does it for 2.0. If RC3 checks out OK then there will be a public release soon.


Your player has gotten better at playing MP3's! (2)

/shout WOOT!!!

/em does a dance of joy!!!
Posted by: Shonky

Re: Bugs? *What* bugs? - 27/03/2003 23:33

In config.ini:

[options]
spindown=0


I searched and only found this mentioned in one other post other than this one. Perhaps one for the FAQ? Is there a list of non-Hijack config.ini options anywhere? I can't seem to find one.
Posted by: Shonky

Re: Bugs? *What* bugs? - 27/03/2003 23:36

OK, replying to my own post again. But I did find a list of options in the Developer section on Riocar.org.

But no mention of the spindown=0 option

Perhaps this developer info could be integrated into the FAQ in a separate section? Tony?
Posted by: tfabris

Re: Bugs? *What* bugs? - 28/03/2003 05:01

But I did find a list of options in the Developer section on Riocar.org.
Right. Hence my earlier comment about the Developer Info Section Gnomes.

Perhaps this developer info could be integrated into the FAQ in a separate section? Tony?
The FAQ entry about config.ini provides a direct link to the section in Developer Info. I don't see how it could get any more clear than that?
Posted by: peter

Re: Bugs? *What* bugs? - 28/03/2003 05:09

From that FAQ entry:
Finally, note that the player software has a 4096-byte limit. This means that if your config.ini is longer than 4096 bytes, it will not be read correctly (actually it will only read the bytes after the 4096 mark). So keep your config.ini as small as possible.
There's no such limitation. The only limit is that individual lines can be no longer than 1,023 bytes.

Peter
Posted by: Shonky

Re: Bugs? *What* bugs? - 28/03/2003 05:11

Mmmmkay missed the gnomes bit. Also when you've read the FAQ a fair bit already you tend to gloss over some things.

Not trying to argue or be difficult, but the developer section isn't searchable. i.e. I have actually searched the FAQ for spindown before but even if it was in the developer section, it still wouldn't have shown up.

Wouldn't it be better to have it all in one? Apart from the extra work for the FAQ guy though
Posted by: tfabris

Re: Bugs? *What* bugs? - 28/03/2003 05:14

There's no such limitation. The only limit is that individual lines can be no longer than 1,023 bytes.
Okay, I'm editing the entry.

Mark Lord seemed pretty certain about the modulo-4096 thing when he reported it. So I'm going to let you two fight it out.

Question: Then why does the player software start screwing up really bad after a bunch of entries get added because of the beta-11 favorite-visuals-doubling bug? None of those have a single line longer than 1024.

Unless by "line" you mean "section"...
Posted by: peter

Re: Bugs? *What* bugs? - 28/03/2003 05:28

Mark Lord seemed pretty certain about the modulo-4096 thing when he reported it. So I'm going to let you two fight it out.
Well, I think we all agree that the bug is no longer there. I think Mark Lord and I have agreed to disagree on whether it was ever there...

Peter
Posted by: mlord

Re: Bugs? *What* bugs? - 28/03/2003 06:43

Which release of player software fixed the documented and observed 4096 byte limitation?

Thanks
Posted by: mlord

Re: Bugs? *What* bugs? - 28/03/2003 06:49

21/02/02 12:31 PM

Hijack v201 Released
...
This version features:

# Hijack now correctly handles LARGE config.ini files.
But please note that the player software does not handle them well:
it will read only the tail end of the file, modulo 4096. This means that
if your config.ini file is 4097 bytes long, the player software will read
only the final byte. This happens whether or not you have Hijack
installed. I suppose I might try to add code to nuke all of the non-player
stuff from the file to help out the player, but even that would not be
simple because the player checks the filesize before computing how much to
read. Ugly bug.
Posted by: peter

Re: Bugs? *What* bugs? - 28/03/2003 07:45

Which release of player software fixed the documented and observed 4096 byte limitation?
The oldest "v2" version I can find is 1.10-alpha3, which does not exhibit the bug. The CVS history on that file goes back to car v1 beta 8, and shows no significant changes. If this bug ever existed, it was fixed before v1.00 beta 8, which was probably released in early 2000, although that was before the Announcements forum was invented, so it's difficult to tell.

Peter
Posted by: mlord

Re: Bugs? *What* bugs? - 28/03/2003 14:51

Mmm.. I'll have to retest. Might've been something in Hijack, but at the time I believe I tried it with a stock Empeg kernel as well. More when I know more..

Thanks
Posted by: loren

Re: Bugs? *What* bugs? - 28/03/2003 18:38

i noticed a bug... you spelled "synchronising" wrong
Posted by: tonyc

Re: Bugs? *What* bugs? - 28/03/2003 21:04

i noticed a bug... you spelled "synchronising" wrong
Ah, that joke keeps getting better with age!
Posted by: mlord

Re: Bugs? *What* bugs? - 29/03/2003 09:04

Mm.. Okay, here is the file access pattern when the player reads config.ini at startup:

HIJACK: read(config.ini): PID=9(player), pos=8192/8268, count=76
HIJACK: read(config.ini): PID=9(player), pos=0/8268, count=4096
HIJACK: read(config.ini): PID=9(player), pos=4096/8268, count=4096
HIJACK: read(config.ini): PID=9(player), pos=8192/8268, count=4096
HIJACK: read(config.ini): PID=9(player), pos=8268/8268, count=4096

The filesize in this case is 8268, "pos" is the starting offset for the read, and count is how many bytes were requested. I didn't trace lseek(), but it looks like something has done an lseek(filesize modulo 4096) before doing the first read.

It's that first read of (filesize modulo 4096) that is confusing Hijack into thinking that only the end of the file was being read. Why is the player doing that? Or is it some quirk in libc, trying to trigger a readahead of the whole file or something?

I suppose I'll have to make hijack more clever or something on this. Tricky..
Posted by: mlord

Re: Bugs? *What* bugs? - 29/03/2003 09:26

Okay, based on this info, I've modified Hijack to cope with the strange access pattern, and v322 will be out shortly.

Cheers
Posted by: peter

Re: Bugs? *What* bugs? - 29/03/2003 10:25

Why is the player doing that? Or is it some quirk in libc, trying to trigger a readahead of the whole file or something?
I agree, that's certainly very odd. The player, though, just opens the file fully buffered with fopen and reads it with fgets: it must be glibc's buffering that's doing something strange with the underlying fd.

Peter
Posted by: smu

Re: Bugs? *What* bugs? - 29/03/2003 14:04

I just added information for the "spindown" config.ini option of the player app to the appropriat developer info section on riocar.org and also modified the info on the HiJack spindown_seconds option to show that a value of 0 disables automatic spindown.

cu,
sven