hi guys is there a total idiot guide for getting gps app going on the empeg as i got an empeg and i got a garmin e-map so i want to see if i can get it going

running windows 2000 if it matters and got zero knowledge about linux

I pulled the README from the tarball and formatted it a bit. It should be around the top of the gpsapp page (link in my signature). I'm not sure how 'total idiot' these instructions are, but they do not even mention Linux once

Okay bringing this back up since it has changed any chance of an idiot guide that is close to blow by blow but i know how to FTP and rough idea how to get the inint file thingy

I had no clue it was this easy to get this thing setup. I need a GPS Receiver now.

Does anyone have any recommendations? Cheaper the better ;P

I have no knowledge of any GPS equipment or how it works. Also, how are you getting everything plugged into the Serial Port on the empeg when it is plugging in?

Okay bringing this back up since it has changed any chance of an idiot guide that is close to blow by blow but i know how to FTP and rough idea how to get the inint file thingy

It just got a lot easier with the new Hijack. You don't need to do the init file thingy any more, Hijack handles it. You don't need preinit, or hack init, or anything.

Since you already know how to FTP, here's how you do it:

- Install Hijack 309 or later.
- Create a folder somewhere on /drive0 for GPSapp. I use /drive0/var/gpsapp/.
- Put the single file "gpsapp" in the folder
- Tag that file as being readable and executable.
- Create a folder for the route data. I use /drive0/var/gpsapp/routes.
- Add the following to config.ini:

[gpsapp]
routedir=drive0/var/gpsapp/routes

[hijack]
;@DC ;@EXEC_ONCE /drive0/var/gpsapp/gpsapp

Provided your GPS receiver is connected properly, GPSapp will appear in the Hijack menu and work, the next time you're on DC (car) power.

Of course, you need to populate the ROUTES subdirectory with actual map data, you'll need to go by the GPSApp instructions for that one. If you run into trouble, post questions here.

Yeah, the new hijack makes life very easy. No more hacking the init binary, trivial to install and run a new app. I've merged all of dbrashear's patches, and a couple of my own fixes that were lingering around on my laptop and wrapped it all up as gpsapp-0.15, follow the link in my signature.

I put it up this afternoon, but hadn't tried whether it worked for me.Well, iIt worked just peachy during my drive home. I haven't tried the new ;@DC ;@EXEC_ONCE, but from everything I've seen it should work right out of the box.

Question: the Coldstart option... by default, it prevents coldstart on the GPS, right (so my unit locks satellites fast instead of taking forever)? Just wanted to make sure I didn't have to add anything to config.ini with this new version?

Looking forward to seeing the speed readout , but not sure I want to give up my distance-to-next-waypoint on that screen for it.

Hmm, it's just what I got from Derrick, didn't really look at it that precisely.

From the looks of it, the default value is actually 'false', or '0' and in that setting it sends 'disable coldstart' and sets the tracking mode to 'car'. So the description in the README is a bit off and your interpretation is right.

These initialization sequences should get dropped by GPS's that don't understand them, the coldstart= option really only exists to allow a possibly broken gps to work. I personally wouldn't have even added that option until someone complained

The distance-to-next-waypoint is now part of the (popup) description that scrolls on the bottom of the map display. I haven't had a time to really play with it much as my car was in the garage for a couple of weeks. Just got it back last friday.

So the description in the README is a bit off and your interpretation is right.

Ah, cool, thanks.

The distance-to-next-waypoint is now part of the (popup) description that scrolls on the bottom of the map display.

See, that's the thing... I love knowing the distance to the next waypoint even when the next waypoint isn't immediately imminent. For instance, if it's 50 miles to the next waypoint, I want to see it count down. (Since I don't have the scrolling text up all the time, it just appears whenever a waypoint is imminent.)

These initialization sequences should get dropped by GPS's that don't understand them, the coldstart= option really only exists to allow a possibly broken gps to work. I personally wouldn't have even added that option until someone complained

Well, he complained.

So the description in the README is a bit off and your interpretation is right.

The interpretation in the README is what I intended to write originally, then changed my mind and not the docs, I guess.

thanks tony will try in morning it damn late now

If we start putting user apps in /drive0/... instead of in /programs0/... as we did when we were using preinit, will they get overwritten by a software update and have to be reinstalled. If not that's great, if so then does Jan's suggestion at the end of his readme look like it will work?

;@EXEC_ONCE /sbin/mount -oro -text2 /mnt/hda2 /programs0

I realize that user app installation is getting lots simpler now but it would still be advantageous to have some areas for these files that would survive an update.

Lynn

I don't see why mounting a /programs directory is necessary. Perhaps someone could explain the logic to me.

AFAIK, mounting doesn't survive a software upgrade without extra user interaction. I was thinking this through for a user application installer and it seems to me that /drive0/programs and /drive1/programs is a much better solution. That way (i think) you could upgrade your software without affecting your installed applications, except the need to reapply hijack. (I'm 90% sure your config.ini changes persist, yes?)

(EDIT: of course config.ini changes persist, they're on drive0...)

In any case, it'd be sort of nice to have a standard place to put things, if not just for the sake of writing easier to follow documentation.

John

Standard empeg software updates will destroy whatever is on the ``normal'' filesystems, from the standard software to anything else you might have added. However, new filesystems will be untouched. So the tradeoff is changing the empeg after software upgrades to mount the nonstandard filesystems or reuploading all of your programs (and their data) after software upgrades.

I just tried this myself and it seems to work like a charm. I moved /sbin/hijack to /sbin/empeg-preinit and added that mount line at the beginning of my [hijack] section in config.ini. Both /programs0/telnetd and /programs0/gpsapp started like a charm.

I just hope hijack isn't running /sbin/empeg-preinit as an alternative to /sbin/hijack, as I would then be making an ass of myself with these observations

If we start putting user apps in /drive0/... instead of in /programs0/... as we did when we were using preinit, will they get overwritten by a software update and have to be reinstalled.

BZZZZZZT, wrong answer!

/Drive0/ is the MUSIC partion, it's not touched by a software upgrade. That's why it's GOOD to put things there. I now have GPSapp, empacman, and Emptris installed on my player on /drive0/ and they do not disappear after a software upgrade. All I need to do to make them reappear on the hijack menu is to install Hijack.

The other option was to create the /programs0/ partition, and yes, that works. BUT.... it has drawbacks:

- /Programs0/ is not there by default like /Drive0/ is.
- /Programs0/ requires a complex system of scripts and init-hacking to make it work, and even once you've done that, you STILL need to recreate the mount-points to access it after a software upgrade. Not for the faint of heart (and not something the novice user would do). Still more complicated than just putting stuff on /drive0/ and using the new Hijack.
- /Programs0/ is size-limited. Currently we don't have any userland apps that exceed its size, but someday we might. For instance, if we ever get some "real" mapping data for a GPS application, you might want that stored on the hard disk, and that might need the kind of unlimited play-space that /Drive0/ provides.

Seeing the advantages yet...?

Sure have.. Yesterday I took your lead and converted to a /drive0/var based install (needed to reinstall empeg image/hijack/etc to get rid of all of the hacks made to get things working before). It's not very hard to do from a base install, so it's a pretty good way of doing things. Anyone who already went through the trouble of setting up /programs0 should be able to move to /drive0 with no trouble...

My only issue is that I still haven't gotten GPSApp working, but I'm not sure if it'll show routes even if no GPS is connected.

Kewl. Now go tell ellweber.

Note that the only reason I chose to specifically use "drive0/var" is because that's where config.ini lives and I always seem to be in there messing with that file so that kind of ended up being my catch-all folder for stuff that I don't want to disappear with software upgrades. Truthfully, you can put things anywhere on drive0, doesn't have to be in var. It's probably better if we make some kind of a standard that involves creating a "programs" folder off of the root of drive0 instead. That's probably cleaner.

...and that might need the kind of unlimited play-space that /Drive0/ provides


Well....assuming your name isn't Pgrzelak...

I'm keen on migrating to /drive0 (and/or /drive1) though. It does make the whole sysadmin thing easier, and will also facilitate Point&Click (tm) installation via JEmplode in the future. Now I've just got to decide what to do with those two 32MB paritions.

Yeah.

Ideally, any directory called "var" is for "Var-iable" data, stuff that is written/rewritten fairly often. Program files and other semi-permanent entities are generally better off elsewhere -- less danger of losing them in the even of a filesystem update error/crash when writing the "var" directories.

But then, this IS linux, so you're highly unlikely to ever lose data from a filesystem crash..

/drive0/Program Files/... :P

I think in this case, /drive0/bin is probably what I'll end up doing.

Standard empeg software updates will destroy whatever is on the ``normal'' filesystems, from the standard software to anything else you might have added. However, new filesystems will be untouched. So the tradeoff is changing the empeg after software upgrades to mount the nonstandard filesystems or reuploading all of your programs (and their data) after software upgrades.

yes, but i was asking what the advantage of not using the drive0 and drive1 partitions in the first place. updates don't touch what's there. the only tradeoff that i can see is the negligible amount of music space lost.

EDIT: See my post below for my response to another small trade off. (Locking the music drives for syncs.)

Currently we don't have any userland apps that exceed its size

i believe emptriv does.

Ok, as touched on by my Jemplode issue, how can I go abouts installing applications on /drive0 without interfereing with syncs? Right now I'm only running gpsapp and telnetd, which necessitates going in over serial and killing the telnetd task whenever I want to sync.

...which necessitates going in over serial and killing the telnetd task whenever I want to sync.


It does? I sync with telnetd running, so I can't see what the problem is.
Besides, you could telnet in to kill telnetd. Your telnet client should be able to deal with a dropped connection gracefully. (I say 'should' because although all telnet clients are equal, some clients are more equal than others)

Yea, I can telnet in and kill telnet and then reset power to get telnet back up after a resync. Emplode fails when checking media, and none of the changes to config.ini are ever applied when I have telnetd running off of /drive0/bin. I'm sure I could put it in /bin and not have a problem, but the point of putting it on /drive0 is to prevent the need of doing anything after an upgrade. It seems as if applications should be run from /programs0, and data should be located on /drive0.

I had forgotten about the disadvantage of not being able to sync while a program is running on the music partition. However, this is not a serious one in most cases if you set up your empeg properly. I still think that for the majority of applications /drive0 or /drive1 is the better place.

The majority of apps should be started from the player (for now using launcher, but very soon using code built into hijack) because if they are only occasionally used and you do not want them eating up RAM that you normally want available for the player to use to cache songs. Almost all user apps fall into this category of "occasional use" apps that do not need to be started on every boot, but only when selected from the hijack menu. So those already won't be running during a sync (because they only start if you select them).

Now you may want to start an app like GPSApp on every boot, but 99% of users can use a ;@DC "macro" so that it only starts in the car. So that's not running during a sync either.

Now we come to the final category of apps that you want started on every boot, even on AC power. I have my telnetd set to start from the menu because I don't use it very much, but so that we have an example, let's say I use telnetd every day and want it to start at every boot because it doesn't take up much memory anyway. If you sync frequently, this could be a situation where it's preferable to keep just telnetd on a different partition, however, I think I would just go prevent telnetd from starting on bootup by commenting out the line in the config.ini.

In short, keeping your programs on the "music" drives is still pretty slick because you don't have to reinstall anything when you upgrade. If you set up everything correctly such that you only start your apps from hijack (use launcher for the time being) and use ;@DC macros for the things you want booted every time, then you won't run into this problem. (I have ~6 things installed this way on my backup empeg and it seems to work fine without any sync errors.)

Once you introduce anything on the main drive (even a mount point) then you lose the ability to do a software upgrade without breaking things. (Note you'd still need to reinstall hijack.) I think that's a pretty cool concept and it certain makes things easier on those users who are hesitant to muck around at the shell, and faster and more streamlined for those who aren't.

EDIT: I just realized that I had to move launcher off the music drives for just this reason and I'd forgotten about it. For now, you can either leave only launcher on the main partition or comment out the ;@EXEC_ONCE launcher line and reboot before syncing. Note that this problem goes away 100% completely when mark finishes the launcher-style functionality in hijack (which is where it should be, because it's 90% the same as starting an app at boot). I believe mark is working on this now.

John

Yeah, now you mention it, that may have been a driving factor for using /programs0.

I run telnetd out of /bin anyway - earlier versions of preinit had some mounting 'quirks', and I was also testing the 'mkprgpt' script at around that time, so I needed telnetd to be up before preinit had completed and drives had been mounted.

This does raise a very important issue -

[bold]Nothing can be running from /drive0 or /drive1 during sync - or sync will fail. It could possibly result in an fsck.[/bold]

That means that any EXEC lines should probably be ;@DC EXEC to avoid starting in AC mode. Anything that needs to be run in AC mode still needs to live in /bin or /programs0, at least for the time being.

How to get around this....I'm guessing that we'd need a kill script that gets called before remounting the music partitions. Somehow we'd need to keep track of the PIDs of userland apps. If they were all started from hijack, then I guess that the PIDs could be easily isolated and exposed somewhere in /proc. A problem might still remain if launcher was used to launch a true daemon though - killing launcher wouldn't kill the daemon.

More thought required.

How to get around this....

If you can't get around it by not starting anything (by default) on AC power (that is, using, hijack to launch "occasional use" things), I'd recomend just commenting out the offending ;@EXECs and rebooting before syncing.

Really, though, if we disregard launcher because that functionality will be in hijack shortly, there are extremely few situations where one really needs to have an app start on an AC boot.

So basicly: commenting out telnetd from running/killing the task every sync takes less time/effort than reinstalling everything every upgrade.

And how many upgrades have you had to do in the life of your empeg? Compared to how many syncs?