Cool. I used the -s- switch in N20Mount right at the end to load the player... now all the programs seem to play nice. I am testing it more now... im sure something will come up.. hehe

[edit]: Now the only problems seem to be that the programs unbind themselves from hijack after they are run and another program is run after them.. hrmmm....

Thanks,
Greg

It actually runs /sbin/init as its last function.

I don't know that that default init only starts the player. In fact, I'm pretty sure that it also mounts filesystems. It might do other things, as well. I don't want to bypass it by default. That doesn't make it any more difficult to create a script that does, though. Maybe I should just point that out in some docs somewhere.

I always thought Frank van Gestel's modified init was pretty cool. It's the one I use. It calls a shell script (/sbin/userinit I believe) to do init type stuff. You manually call the player when you want to in that script rather than being at the mercy of how init handles it. It lets you get pretty fancy with how you set things up, and if it can't find /sbin/userinit, it just calls the stock init, or if something fails, it drops to a shell so you can fix things.

Too bad it's not on the Empeg distribution. That'd be nice.

I am having trouble with this program. I have it loaded and running on the serial port. At home it runs fine from the Hijack menu but in my car it gets all funky. It switches from Aux to Player back and forth making it impossible to play. I tried switching to Aux mode then playing from hijack menu but same results. Any ideas?

I configured empeg-preinit v3 etc. manually and also had this problem in-car so it's probably not a problem with genixia's shell script as such. FWIW, at the time I would have been running 2.0b11, pre-init v3 & Hijack 276.

It only occured during one 'sitting'. Pulling the player from the sled didn't make any difference and (AFAICR) I had to select Player as the music source to get rid of it.

That was earlier this week and was the first (and last) time it happened.

I pulled mine from the car. Deleted empacan. Put it back on player and it is working fine now. Must have been an freaky thing. Oh well, all is good now.

Okay. I'll give it a go tommorow when I've got some spare time

- Trevor

I got exactly the same thing with my GPS code, it runs fine when plugged in at home but when it's in the car, it just goes apesh*t and the only way to stop it is by pulling the player out of the dash and popping it back in. I've so far not been able to fix this problem.

I've been trying out running the player from a preinit script but I can't seem to get it working! The script I made basically calls /empeg/bin/player -s-

The error I get looks like this (on the serial port):

! empeg_id.cpp : 49:Unable to open /proc/empeg_id
player.cpp : 385:empeg-car 2.00-beta13 2002/07/24.
! player.cpp : 291:MainThread::Init failed!
bin dev drive0 drive1 empeg etc lib lost+found mnt proc sbin swapfile tmp usr va
r

dunno if that last line is relavent! but it seems to me that /proc isn't mounted yet. Does this get mounted by the stock init? If so, what's everyone doing to get round this?

Another thing that I can't get my head round is if it doesn't return, doesn't pre-init time out, quit and carry on anyway, running the stock init?

Cheers.

Another thing that I can't get my head round is if it doesn't return, doesn't pre-init time out, quit and carry on anyway, running the stock init?

Ummm. Yeah. I forgot I put that in there. In v5, I plan to put in the facility for there to be a single `B' script that will prevent that from happening.

And I imagine that the stock init mounts pretty much everything except the root filesystem (already mounted) and the /drive0 and /drive1 filesystems (as it remounts them during syncs, so I figure it just retains control over them altogether). Just place a ``mount /proc'' in your script somewhere before it blocks. Of course, you'll need to wait for v5 before it'll be useful, huh?

Ah, that's ok then! Roll on v5!

Does the stock init just mount /proc before running the player? or is there more to it than that? Just a thought: perhaps there could be a sample 'B' script that includes stuff that the stock init does - if it's more than just mounting /proc!

I'll give it a try later, mounting /proc first and see if it complains any more. Just gotta knock together a power supply - i'll see what I can rob around work!

Cheers.

I don't honestly know. I'm just making assumptions.

I have sshd running for quite a while now (~01/2001),
but the disk with the toolchain on it died.

Since the crosscompile was super simple (just follow the manual) I never bothered with writing a howto.

One drawback:
If you log in via pub/priv-key while playing a tune, it can take a while to have that key calculated

Since the crosscompile was super simple (just follow the manual) I never bothered with writing a howto.

Hmm, Looks like I missed that manual somehow. zlib and openssl have compiled easily, but openssh is being a PITA.
/me goes off a hunting.

Did you compile statically? Do you still have the binaries? That is all we really need

Maybe he compiled up the non-open ssh.... It is more monolithic, at least....

I've got OpenSSH 3.4p1 working on the empeg but the install instructions are a little long so I need to write a nice simple install script for it. I'll do it tommorow because I'm really sleepy at the moment.

Oh yeah. Key generation on the empeg takes AGES...

- Trevor

hmmm ... looks my self compiled ssh is gone,
but:
# dpkg -l|grep ssh
ii ssh 3.4p1-1 Secure rlogin/rsh/rcp replacement (OpenSSH)

I guess installing debian might solve your problem ... as usual.

I'll skim through my old backups anyway, maybe I find the static binary somewhere.

Mounting /proc and /drive0 seems ok but I still get this error after the player starts:

! mp3_decoder.cpp :1049:Failed to find valid sync after seeking to offset 3471
990, error=0xc0044000

When pre-init times out and runs the stock init, I don't get that error.

Oh well, anyone know where I can get the modified init by Frank van Gestel's mentioned earlier on?

Edit: Found it: http://empeg.comms.net/php/showthreaded.php?Cat=&Board=empeg_tech&Number=20407&Search=true&Forum=All_Forums&Words=modified%20init%20%2Fsbin%2Fuserinit&Match=And&Searchpage=0&Limit=25&Old=allposts&Main=18016

>>! mp3_decoder.cpp :1049:Failed to find valid sync after seeking to offset 3471
990, error=0xc0044000

I can't remember which thread it was discussed in, but isn't that error merely caused by the player starting mid song?? And as such, pretty much a non-error.

Yeah. It definitely happens occasionally to very often, with or without any additional software. IIRC, it has something to do with the player not quite jumping to the right spot in VBR files, but I could easily not be RC.

Sigh. I guess I'll spend the ten minutes and hack up a blocking version. Gimme a few.

Okay, for those of you that want to block the normal init sequence, I've put out an empeg-preinit.v5-beta. It's just the binary. It's not been tested. But you should be able to create scripts that start with a `B' and expect them to be run in order after the `N' scripts, but the timeout has been defeated while they run. The idea is to just have one `B' script, but you can have multiple ones if you want, for some reason.

Make absolutely sure that your `B' script works properly. Otherwise you'll have to reflash the whole system to get it back to a working state. I'd suggest not putting it in a loop to begin with, so that if it fails it can exit and go back to the normal init.

Lemme know how it turns out.

Still messing about trying to get this to run with reasonable speed. It's excruciatingly slow at the moment...

- Trevor

Make absolutely sure that your `B' script works properly. Otherwise you'll have to reflash the whole system to get it back to a working state.

Couldn't you nuke a bad B script via ftp?

IIRC, Hijack's FTP server is not running at that point in the startup process.

Hmm, Hadn't thought about that - you might be right though. It's a good idea to install telnetd to /bin then

Now that's a good idea.

In reply to:

---

Make absolutely sure that your `B' script works properly. Otherwise you'll have to reflash the whole system to get it back to a working state.

---

Is kftpd not active by then? I thought it was possible to (re)move your B scripts by FTP, then reboot.

See above.

Thanks for the script and the instructions, worked great for getting me set up with telnetd and getting empacman bound to the hijack menu. One question though.... And I think this was mentioned somewhere (maybe in another thread) dealing with empacman and emptriv I think..

I had empacman working great, it would bind everytime I started up and be in the hijack menu and work fine. I decided to add empsoko, but found out that it would not bind automatically (just by putting it in the /programs0 directory, I figured that out, you just dont have an empsoko entry in the preinit.d directory ).. Well I *thought* I had it figured out, I would just need to add it as something like M70empsoko and put the necessery lines in the file..

Sure enough, after I made that file and rebooted, they were both in the Hijack menu. I started up empsoko, and it worked great. But unfortunately, now the empacman menu entry *also* loads empsoko.. So.. where do I go from here?

There is a bug in Hijack which for some reason prevents you from having two user apps. I'll have a look at the kernel code later on but I can't guarantee anything because I'm quite busy. So if anybody else wants to fix it in the mean time...

- Trevor