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?

I guess that makes the 'Edit config.ini' option in Jemplode/Emplode kinda useless, as that only works if you have the ability to sync. (Chicken/Egg)

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.

I need to stop posting when I'm tired....

Point taken.

However, after the laucher functionality goes into hijack 90% of users won't have the need for an application to boot on every AC powerup.

But yes, you are probably right that if for some reason you did need to start something on every AC boot, the main partion is the better place for it. Are there any other examples people can think of besides someone who wants to have telnetd running on AC power on every boot?

I suppose if I were clever enough to ensure all user apps are started in a common process group or something, then Hijack could kill them all on request.. But many daemons fork and then drop their groups IDs, so that wouldn't work..

What exactly is the problem, anyway?

I don't use third party apps myself (anything I need, I build into Hijack.. that's why it exists!), so perhaps somebody else could explain exactly how an app that was started from /drive0/ prevents sync from working..?

-ml

IIRC, it's because the process' working directory is in a filesystem that being (re)mounted, and mount doesn't like that. If you make sure that it starts up with a pwd of /, then that won't happen.

No, I don't believe that. CWD is '/' for programs started by Hijack.

Here, collect some info for us: run a third-party app from Hijack, and then surf to /proc/nnnn/, where nnnn is the PID of the app. Collect everything from there and show us what you find for CWD et al.

Thanks

My fault. That was (often) the problem before. I haven't even installed Hijack v30<whatever> yet, as I don't honestly run any additional programs on the empeg.

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.


Messy - manual commenting out on every sync is going to be as (if not more) painful than reconfiguring apps after an occasional upgrade. Automagically commenting them out is going to require careful coding in JEmplode to ensure that it handles already commented out EXEC lines correctly afterwards.

And it would be a delaying factor anyway - we'd need to reboot after disabling apps, which would then need JEmplode to re-read the database.

To do this right, we need to have a cohesive strategy that utilises JEmplode, hijack and on-player utilities when appropriate.

I'd suggest that the specs for this strategy should include as a base. I apologize in advance for being presumptious about changes needed to other peoples' work.

1) Initial setup (from a hijacked but otherwise 'vanilla' Official release) should be a one button click operation in JEmplode. (I'll accept 2 buttons if you count 'Sync' )
1.1) This setup should be repeatable without loss of any existing data after an official upgrade.
1.2) The setup should include on the empeg any binaries or shell scripts that JEmplode needs to manipulate and install packages.

2) The strategy should allow for (non-application related) syncs to occur from the Empeg-offical Emplode;
2.1) without any modification of config.ini
2.2) without any changes to Emplode itself
2.3) without adding any reboots.

I think that if we can get those first specs well understood, and a strategy to implement them, then it makes the other specs much easier to implement;

3) Suitable package system facilitating;
3.1) Point and click application install.
3.2) Point and click application upgrades, including intelligent handling of application config files.
3.3) Removal of packages... (allow config files to remain? Make that optional?)
3.4) config.ini EXEC lines. (e.g, provide a list of selectable options)
3.5) Package must include a simple method of versioning that JEmplode can read.

4) JEmplode should interact with the package and associated on-empeg utilities to perform the install, configuration or uninstall.
4.1) Should be capable of locating the package on the local filesystem.
4.2) Should be able to parse the package for version and configuration information.
4.3) Should be able to present user with selectable config.ini options based upon package recommendations. User should be able to define their own selection if desired.
4.4) JEmplode should be capable of (optionally?) displaying installed apps, and associated config files in the tree.
4.5) Should interact with the on-empeg utilities to install, (intelligently) upgrade or remove packages, including config.ini changes.
4.6) Should be able to temporarily disable application (through config.ini change) without removing it.


As I said, I think that this needs to be a 3 pronged approach to be really successful - and will require co-operation between efforts would be required.

I don't have any good info either, as I haven't experienced the sync lockup in a long while, but then again perhaps that's because I've actively tried to avoiding it. It does exist though, but I've just assumed it had something to do with running any programs from the music drives during a sync. It might only be those that have open files though, that would make more sense. If that were the case it'd be even less of a problem.

I'll leave this to someone who has has the problem to play with further.

John

That took a while to type up.... I hope it wasn't made redundant..

wow, that looks like one of my long winded posts!

I'm still not convinced that we can't avoid the sync problem altogether. I wish I had an empeg nearby, as no one seems to know what the cause of these lock ups is and I have not gotten one in several months.

These are good ideas, yes. But it be really nice to avoid any commenting business at all. That part of my comment earlier was incredibly poorly thought out. Let's first see if we can't eliminate the situation that causes the lockups in a direct way before involving Emplode or comenting or anything like that.

So can anyone give actual evidence of what causes a lock up? I'm betting that it's only when a running app has a resource (file) open on the music partition, in which case it seems we could just eliminate that situation from occuring by default on AC boots.

If I’m following the topic correctly, my 2 cents would be not to include the functions for setup 3rd party programs in Jemplode. I would rather a separate package manager. Wasn’t smu working on this before? His idea, maybe modified a little bit, would be great. I never sync my music database with jemplode, nothing against the java version of emplode, but I just don’t trust it with my music database. I’ll use it for the animation editor, and downloading tracks, and that’s about it. I’m actually fine with ae? (crappy vi like empeg text editor)

I had forgotten about the disadvantage of not being able to sync while a program is running on the music partition.

So had I. Sticky problem.

For me, it's fine to run all my apps in DC mode only, but what about the folks who sync with the player in their car (wirelessly or via a laptop)?

I wonder if there's any way to code the apps so that they just don't have this problem. Or perhaps there's a way for Hijack to know when it gets a reboot-request from synching software and Do The Right Thing with regard to mounting the drives.

Heck, I'd like to see Hijack do that anyway... If I set RW while a program is running, the subsequent RO fails (without an error message by Hijack, I might add ). It would be neat if Hijack could Do The Right Thing in that situation, too.

The theoretical package manager referenced in this thread and discussed here is functionally completely separate from JEmplode syncs. It changes nothing whether it would be packaged with JEmplode or not. (In fact, it would be trivial to separate if you really wanted it so.)

As for this sync lockup business, pay little attention yet. I'm not sure we (I?) know what we're talking about anymore...

Can anyone confirm that a program running from the music drive, but that does not have any files on the music drive open still blocks a sync?

That's the question of the hour...

...I can't handle the suspense anymore. I'm seriously *walking* one mile to get an empeg to try this out. Not kidding...

I wonder if there's any way to code the apps so that they just don't have this problem.


Well there is, but any solution that we implement shouldn't really rely on a 3rd party app being correctly coded in order to avoid an fsck. (If we can possibly avoid it).

Mmm.. "open files" (for WRITE or READ/WRITE would do it. To prevent this, GPSapp and friends should ensure that their files are only open with RD_ONLY access. But then, that should be the case already, since the filesystem is read-only to begin with.

The info in /proc/nn/ will tell the true story..

Ofcourse I'm running from /programs0, but here is the relevant proc/nn info. My guess is that at the end of a sync, the software actually does "umount /drive0 ; mount -oro /drive0" instead of "mount -oremount,ro /drive0" and the umount fails because the executable image still has a reference on the filesystem.
(btw. I was logged in with telnet, which explains the two sockets and /dev/ptyp0)

sh-2.03# ls -lR /proc/12 

/proc/12:

lrwx------    1 0        0               0 Jan 25 17:37 cwd -> /

lrwx------    1 0        0               0 Jan 25 17:37 exe -> /programs0/telnetd

lrwx------    1 0        0               0 Jan 25 17:37 root -> /



/proc/12/fd:

lrwx------    1 0        0              64 Jan 25 17:37 0 -> /dev/ttyS1

lrwx------    1 0        0              64 Jan 25 17:37 1 -> /dev/ttyS1

lrwx------    1 0        0              64 Jan 25 17:37 2 -> /dev/ttyS1

lrwx------    1 0        0              64 Jan 25 17:37 3 -> socket:[3]

lrwx------    1 0        0              64 Jan 25 17:37 4 -> socket:[21]

lrwx------    1 0        0              64 Jan 25 17:37 5 -> /dev/ptyp0

Okay, remind me in a day or two to instrument the mount/remount calls in the kernel so we can see exactly what the player is doing (or we could just run strace on the player, but I think it would be serial-port bound..).

Back to the workshop now.. gotta get these docks out.

-ml

I got similar results in the /proc/nn/ dir for telnetd.

I did confirm that a sync fails even if the program does not have any files open during the sync. The sync the fails with the emplode message: Syncronization faid while checking media, 0xc0041010.

I couldn't interpret anything from roger's error code table from that one. I don't think it's in there.

This however is the serial output when the sync fails:

Adding Swap: 16596k swap-space (priority -3)
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/
hda4 is mounted.
Restored terminal settings
Remounting first music partition read-only
Remounting second music partition read-only
Restart code received
Starting player

Maybe that "ext2fs_check_if_mount" line will tell you something. Let me know if I can help with anything else.

John

I did the strace,

oldumount("/drive0");
fork(); // runs some program that returns "/dev/hda4: clean, 5547/" probably fsck
mount("/dev/hda4","/drive0","ext2",MS_RDONLY|0xc0ed0000,0x210f65c)
// does some more stuff
mount("/dev/hda4","/drive0","ext2",MS_REMOUNT|0xc0ed0000,0x210f65c)
// does a lot more stuff (probably the actual sync)
mount("/dev/hda4","/drive0","ext2",MS_RDONLY|MS_REMOUNT|0xc0ed0000,0x210f65c)

So it looks like we're being bitten by the fact that we can't perform a filesystem check on a mounted filesystem. The actual sync should be just fine.

At the end of the sync, the player kills itself and is restarted. Hmm, would it be possible to kill any process that has an open file reference to the filesystem at the time of umount. Then we could use ;@EXEC /drive0/bin/telnetd and it would just get killed when the sync is started, but will restart whenever the player comes back.

Mmmm.. there's nothing technically wrong with doing the fsck on a live READONLY filesystem, at least not in most versions of the kernel (think.. root filesystem check at boot time.. it's always mounted RO at the time).

If that's all that's wrong, we could just intercept "oldumount()" in-kernel, verify it's coming from the player binary, and then just ignore it (or replace it with a mount READ-ONLY).

-ml

I suppose there are two classes of filesystem repairs.. those that are fine to proceed with, and those that require rebooting if the filesystem was mounted RO during the check.. the exit status from e2fsck indicates which type occured. This could be a bit of a snag for us.. but a bit of thought will likely produce a workaround of some sort.

-ml

a workaround of some sort

Wouldn't it be possible to intercept the umount, check for open files on the two music filesystems and if there are any kill the process holding the file open before unmounting? Not the most friendly solution, but a lot simpler than tweaking a lot of existing software to avoid the problem.

-Mike

Yeah, that's what I was thinking.