>It's basically "screen scraping" the top 3 rows and looking for what the player menu...

Slightly complicated by the fact that the player menu appears slightly buggy, in that if you go more than two levels deep, the entire display shifts down by two pixels. Ugh. But we handle it.

>Can we get one more option added to the list of alternate uses?
>The detailed info screen ...

Ahh. Thank-you. I really disliked the "Repeat" option that I placed on the menu as filler, since hitting PREV-TRACK will repeat it anyway.

But "Detail" is a difficult one, since it replaces a "short" press with a completely different "long" press. Especially since the player may go berserk if the "button release" gets lost due to subsequent activity. Very, very tricky. Some may fail to perservere. Some would despair at the though. Some might even say "impossible". Some could do Real Work instead. Some may have/get a life. Some may even (gasp!) ham it up a bit much. But.. v36 seems to handle it all nicely.

Okay, now that we've got the "knob-press" and "menu" buttons working well, how about some nominations for what to provide as "replacement" functions for "press-and-hold-DOWN-BUTTON" on the front panel? I seem to recall some discussion (elsewhere?) as to various dislikes of the current functionality of that button.

I seem to recall some discussion (elsewhere?) as to various dislikes of the current functionality of that button.

The only problem is that once you've used it to do the "user accepts responsibility" thing at the after-boot-full-screen-info-screen, it always toggles to "Off" after that.

For instance, Let's say I boot it in the car. It's fullscreen info:Track. I press and hold the bottom button and it goes to the screen it was on when I powered down last time, which was Transient. All well and good. But now that it's in Transient, it would be nice if it would toggle back to Track. But it doesn't, it toggles back to OFF.

Now, as much as I'd like to see you actually do something about this in your kernel hacks, I would like to warn you that I think the empeg guys might be working on changing this behavior and you might not want to mess around with that button's behavior until their work has settled down (after beta).

Wish list item: The ability to provide a text color for the EMPEG_HIJACK_DISPTEXT ioctl.

BTW signal handling is working great.

But.. v36 seems to handle it all nicely.

Heh, cool.

Hey, how is the inactivity blanker supposed to work? I set it to 30 seconds, and after 30 seconds the screen doesn't go blank.

Oh hey, and Mark...

I noticed at your web site that you have both a Rio remote and a Kenwood remote.

Did you buy a Kenwood remote just so you could play with kernel hacks that supported it? Or did you already have one lying around?

v36 seems to handle it all nicely

Cool! But, now I am two versions out of date again. The things that happen while I am driving home from work!

-Mike

I though it was only supposed to work on the end of playlist screen. If you have a visual or anything else on the screen it wouldnt work, right?

Smu,

Have you managed to split the 2.00beta3 upgrade...? I get an error:

upgraderversion=0x02
info=Upgrade file
what=empegcar developer image
2001/10/17 16:03
release=empegcar player software - developer release v2.00-beta3
version=empegcar player software - developer release v2.00-beta3
ERROR: Unknown chunk type 0x04 found

Same with the consumer image...

Cheers

Kim

I have had a bit of a play with your splitter and got it to compile under Linux and stopped it from just dying when it meets an Unknown chunk but rather it now assumes it is a string and prints it out before continuing...

the resulting unknown string seems to be:

7
9

but I managed to get the partition image out so will have a play and try and get your builder working and changed to upgrade to hda2

Cheers

Kim

(I'll clean up the fixes I have made and give you a patch when I get it working... )

Ahh... I see I should have unpacked the SplitterBuilder zip first... :)

that one compiles find under Linux... :)

Cheers

Kim

It is supposed to kick in (and it does, AFAI can see) when the screen does not change for selected period of time. So, it will work when the player is paused with info-only screen or, say, 'scope visual, but won't with, say, stardust.

It worked!!!

Well done Smu... I had to hack the code to allow for the unknown chunk I found which I duely copied to the new upgrade image I build (am slightly worried about not knowing what this is but it seemed to work just being copied)... but I managed to end up with an upgrade image that puts on a new kernel that looks for hda2 and pumps hda2 with a root image...

Takes far longer to upgrade as the partition is twice the size... Also for some reason my gzip of the 32Mb partition came out to be ~27Mb whereas empeg's gzip of a 16Mb partition came out to be 3Mb... Need to work out how to get that size down as my current upgrade file is over 28Mb compared to the usual ~3-4Mb... and I am not including the image of hda5...

I have put the image up off my personal page at work (too big for my home server/connection)... If anyone wants to try it... it is Mark Lord's v36 kernel with the hda2 patch and the hda2 partition is just a copy of hda5 with a new init that I have been toying with to test out the idea...

Now need to spend some time and build a more useful hda2 image and start work on an installer program... :)

My thoughts are that we should make it so that /dev/hda2 is wipeable with an image like this and that actual 3rd party software (rather than infrastructure stuff like this) is stored on the music partitions...

Cheers

Kim

PS no guarantees on the upgrade image and I would definitely like to know the meaning of the 0x04 chunk I copied over... but if anyone feels like giving it a test I would love to hear how it goes...

and Smu, I will try and get together a patch of the changes I had to make to your Splitter and Builder code to split the 2.00beta3 upgrade

That's not a bug, it's a feature :)

ISTR it's that previous menus "stack up" below the active (lowest one) with a fixed vertical offset between them. This may mean that the top row is not always the top of a menu.

Hugo

OK worked out how to cut the size of my partition image down... start with a zeroed out image... :)

now have a upgrade that just pumps hda2 at 3.8Mb and one that pumps both hda2 and hda5 at 6.6Mb... will test them both out and add them to the same page I put the first one...

Cheers

Kim

Hi,

It seems there is a spare partition which we could use.

This leaves the problem of mounting rw a partition and yanking the power.

Hasn't the new kernel support for a journaling file system? If we make a "settings" partition, this could be a journaling FS, and it doesn't matter if we yank the power.

The spinning up/down problem could probably be fixed in the kernel, as mlord knows both kernel and IDE pretty well.

Just a quick thought ....

>how is the inactivity blanker supposed to work?

When the screen is inactive (not changing at all) for the specified interval, it blanks (still "on", just cleared). If you have a clock or music timer incrementing, it will not blank. If a LONG title is scrolling back and forth sideways, it will not blank.

>Did you buy a Kenwood remote just so you could play with kernel hacks .. ?

Actually, I've had my unit (s/n080000316) for more than a year, and back then it came with a Kenwood remote and an amber screen. So, when I heard of all the nifty new v200b3 stuff that works only/better with a Rio remote, I plunked down the cash for a new one. Of course, the accountant / taxman believe that my company purchased it so we could write software for it as part of our global marketing plan, just like the original player purchase.

>If you have a visual or anything else on the screen it wouldnt work, right?

It's an "screen inactivity" blanker: it watches the screen for periods of 100% stagnancy, and then blanks the screen after the user-specified period of stagnancy. This means it WILL operate even when the player is running, but only if the screen never changes (no timers, counters, visuals, scrolling titles, etc..).

The easiest way to see a demo, is to start a tune playing, go into my menus, set the timeout to 30sec, and then select the Font Display item from the menu -- wait 30 seconds, and poof.. music still playing, but screen is blank.

Actually, forget the "font display part", just sit looking at the 30 second setting screen for 30 secs.

Any chance of adding a new option in the quick knob press list. I want to be able to toggle between the current voladj setting and "off" with a single press of the knob.

If it briefly displayed the voladj state (i.e. off/low/mid/high) at the same time then that would be even better...

As noted previously, you shouldn't be distributing the hda5 image; this is copyright, etc. You don't need to though, if you do clever stuff with the kernel and hda2...

Hugo

>I want to be able to toggle between the current voladj setting and "off" with a single press of the knob.

No, this won't happen. But in v37, I've "prefixed" the usual Volume / Loudness / Balance / Beep rotation with a VolAdj setting overlay. So, one press of the knob brings up VolAdj, and then a twist of the knob alters the settings. Another press of the knob cycles to the next adjustment (Volume / Loudness / .. ).

Close enough?

Hi,

AWE ..... some.

Close, but I might look into installing a cross-compiler, as I guess it wouldn't now be hard for me to tweak your patch to do exactly what I want rather than very nearly what I want...

Now if only the player was open source !

(and yes I know why it is not open source and realise it will remain so)

Now I have actually downloaded and install v37 I realise that the latest changes do give me pretty much want I want, although I now don't have a single front panel button press to toggle shuffle...

This thing just doesn't have enough buttons !

> The thermometer is still flakey in my unit -- without the continuous inittherm() calls, it sometimes stops updating. Unplug / replug the power, and the temperature then "corrects" by 20C over 3 seconds.

I'm going to put the inittherm() calls back into the code, maybe once a minute or so.

-ml

It's an "screen inactivity" blanker: it watches the screen for periods of 100% stagnancy, and then blanks the screen after the user-specified period of stagnancy. This means it WILL operate even when the player is running, but only if the screen never changes (no timers, counters, visuals, scrolling titles, etc..).

May I suggest that the screen blanker be made into one which is based on the last keypress (from front panel or remote) instead of based on the screen-scrape?

I could go into a long discussion about why I think it's important, but I thought I'd just try rubbing the lamp first.

Also: The number of seconds of inactivity selector: Could it be in MM:SS format instead of SSSS format?

But in v37, I've "prefixed" the usual Volume / Loudness / Balance / Beep rotation with a VolAdj setting overlay.

This is amazing the way you've done this. Quite impressive.

>May I suggest that the screen blanker be made into one which is based on the last keypress
>(from front panel or remote) instead of based on the screen-scrape

Even better: I'll take both times (last keypress, last screenchange) into account in the next version.

>seconds of inactivity selector: Could it be in MM:SS format instead of SSSS format?

I'll pass; I like the seconds display, and doing mm:ss is unnecessary bloat.