All i need now is someone with the brains to do it.

I know that Hijack can can userland applications which i think means small programs well i have an idea for one that would be great but i have zip knowledge of programming.

What i would like is an application that can take a list eg shopping, set of directions, list of reminders etc and then display that one the empeg having an ability to scroll and skip through the list.

Idea solution for this would be taking a set of directions from lets say autoroute and displaying them and reading them while driving along like

junction 5 take exit so and so

I think what would be needed is a way to upload it to the player as a file and then a program to do the needed.

I say, what a spiffing idea, what .

I like that idea. You could even store the list in flash memory since it's ASCII and would be small. You could use a variation on UPLOAD.EXE to send it to flash. I'm sure there's some bits of flash that aren't being used yet that we could find, right?

Oy! How about this. How about have Mark simply include a function in Hijack that displays ascii data it finds in specified areas of flash. You could use the knob to scroll it. Then you wouldn't need a userland application at all, just UPLOAD.EXE and the kernel...

OO, I like this, then I could program my trip directions (which are always ASCII anyway) into the player ahead of time and not have to print them out. Poor man's nav system

I like it...

How about just ftp'ing a text file - something like 'list.txt' or whatever to a pre-determined directory... Or get real fancy and support multiple lists in an .ini file format:

[List1]
Name = Shopping
Line1 = Milk
Line2 = Eggs
..
[List2]
Name = Directions
Line1 = Left on main
Line2 = Right on Amber
..
[List3]
Name = Whatever
Line1 = abcde
Line2 = fghij

And have a second level menu to select which list you want to view.

Just a thought...

Cheers

Great idea, but I don't really see how it would be useul for a shopping list unless it's only two or three items that you can remember from your car to the store. Anything more you'd forget unless it was written down anyway. But for directions it's a great idea.

I agree as well. Directions would be awesome though, hopefully gps gets working as well (differnt thread all together). Also, what about a reminder? I always get in my car and a few minutes later am trying to remember everything that i need to do. [Laundry at 4:00pm, Ship Packages, LAN Party at 8:00 ; ) ...etc]

-Greg

I like Tony's idea as you don't have to mount the empeg drives RW first.
[normally the disks are mounted Read Only so that there are no delays for fsck's during the startup process on the empeg and to prevent data corruption/loss when the power is lost when the unit is pulled from your car].

The only problem I have with Flash is that its a finute lifetime component - if we update the flash heaps it will 'wear out' sooner, yes I know that the flash ram chips are rated for X cycles on average but the less wear and tear on flash the better.

However, by using flash its real simple to upload - if you have access to upload.exe and know the address to upload things to.

I was wondering if Mark (Lord) could create a virtual device in /dev (like /dev/kernel_flash works now) that his kernel ftp server re-routes to the correct address/block in the flash area that we have determined is 'free' to use for this purpose - thus encapsulating the implementation of this functionality totally inside the hijack kernel.
[as its the same kernel that will display the info also].
Any CR/LF or LF only seperated file should be able to be displayed, maybe we can impose some structure [like a minature tree of 'sub-options' so you can have the directions to the Mother In Laws, the shopping list and whatever other checklists you need access to in your empeg, so you can select which list you need to view and then view it as 'text'.

Remember that the flash is getting written and re-written every time we create a new playlist, power down the player, change a sound setting...

In other words, adding some text to the flash once in a while is a drop in the bucket compared to how often the flash is rewritten by other stuff.

Does anyone have the link to our thread on how many years the flash will last at current write frequencies?

The disks have to be spun up on power on to start the player, right? This is probably better suited for a userland app that reads some file at power on (added to init, whatever) and is able to display at any time. The files probably wouldn't be large, so could be completely read from disk and kept in memory. I agree that this shouldn't be kept in flash -- if its to be used as discussed, it could change daily.

However, by using flash its real simple to upload - if you have access to upload.exe and know the address to upload things to.

Now, with the ftp server (thanks again mlord!), it will be easy to upload (if you want to go all out, the app could have a sync on the PC to upload the data using ftp) and the only time the disks would be mounted RW is when data is uploaded, same as music. The commands to RW mount the disks remotely is still a problem (w/o a serial line & developer image).

Yes I agree, however Hugo designed the Flash Savearea so that it saves in a different part of the flash each time, thus ensuring that the flash is 'evenly roasted' and over many years the whole flash area is used up evenly - probably long before then the hard disks and display dies but thats only part of the problem.

If we keep updating the same part of flash with shopping lists then we are not probably doing the same to exetend the flash rams life as the flash save area does now for saving the player status.

The same goes for kernel updates - in all likelihood we are not likely to 'use up' the flash with kernel updates even if Mark released 3 updates a day for 2 years and we installed everyone of these updates as they were released.

However the shopping list idea in flash is not without some [minor] drawbacks and we should bear this in mind as this does limit some of the things we can use it for.

There must be a 'flash' block size which is the minimum that gets erased/written every time you changed even one byte, so changing one byte in X bytes is the same as changing every byte in X bytes.

I would figure the flash in the player is designed for up to a minimum 1,000-10,000 erase/write/cycles but this is calculated assuming a even spread of updates over the lifetime of the device and no more than X% of it is updated more than say 1,000 times ever.

To keep whacking a the same block of flash with updates ala shopping lists does put a different stress on the lifecycle design of the flash ram.

I guess Hugo can comment as he obviously had these things in mind when the save to flash routines were developed for saving the player status.

Don't get me wrong I'm not knocking it, I think its a great idea, but lets be a little cautious about using something like flash as if it were a RAM device - its not.

And once the Flash Ram starts going bad it will begin to affect everything stored in it - i.e. the kernel also as its stored in there & the save area etc.

My memory is going Dave, I can feel it....

No, that's not strictly true. Flash is ONLY written when:

-- a new kernel is installed
-- player software is upgraded/replaced
-- power is turned off
-- once every 64 power-on cycles

Other than that, flash is NOT written to.

(when you change sound settings, etc.. these are NOT committed to flash until power-off time).

In fact, when the player is running, I suspect the hard disk is being written to far more often than the flash.. keeping track of the "Mark Track" data, and possibly the "Shuffle" order, and the "Info Seek" display data (not sure about that last one).

Mounting the drives rw AT HOME to dump in a shopping list is a no brainer, guys. It still remains as "readonly" as ever in the car, which is actually not the 100% many of us thought.

I really dislike the idea of storing anything new (and big) in flash. Bad Idea.

Somebody slap Tony silly for us, okay!

-ml

I did not know that.

I thought they also implemented a flash write when the player was put into standby mode.

That's actually what I was working on developing... a list for directions etc... I initially thought storing a section in the config.ini file for each 'document' would work, but I don't think this would be the best of ideas....... any others for how to store these documents to be viewed?

any others for how to store these documents to be viewed?

Yeah, you can just transfer the file over to the Empeg while it's at home onto any available partition. The user app would just have to know where to look for the file.

To allow writing to the disks while in the car, we'd actually need some kind of a storage API which can do raw sector-level writes to an unmounted volume and handle error-checking in case the power fails during a write. This has been talked about before. I currently lack the knowledge to make something like that happen. My hope was that someone with more knowledge about that stuff would appear on the forums and start writing such an API, or that it might get worked in to a future Hijack kernel release. Neither has happened so far.

Incidentally I already have about 95% of the code that would be required to display an arbitrary text file on the Empeg's screen and scroll through it. That's really what my Trivia game is doing, you know.. So if someone *really* wanted this kind of functionality I could probably work something out. Then the user would just have to come up with a creative way of getting those text files to the Empeg.

Would it be a bad idea to just add a section the the config.ini (which can be easily changed via emplode) that would hold the text... such as

[text]
{start}
first text 'section' here
{end}
{start}
second 'section' here
{end}
...
rest of config.ini

Yes, 'cos the player wouldn't parse it correctly, and might fall over horribly. You'd need to use the:

[section]
key=value

...format.


Something like this, maybe:

[text]
count=3

[text_1]
lines=2
line_1=


...etc., ...

Hmm it's not an inherently bad idea, but it's not very intuitive. config.ini wasn't intended to carry that kind of info. Plus I can see it being easy to futz up your config.ini whilst entering your groceries or whatever.

I would prefer a solution involving some kind of storage on one of the user partitions. Unfortunately that animal doesn't exist yet. Text files in some predetermined directory on the root partition would be another option, and like I said, I've almost written all of that code (though it uses the really slow GD graphics API for text.)

even if Mark released 3 updates a day.......

He almost does this now, I don't think I've ever seen updates as fast as mlord does. I like it.

Q:Is the ramping signal strenth meter in Aux (Car only) something Hijack does or in 2.0b7?

Must be 2.0b7.

So what's wrong with just doing:

ftp my.empeg.localnet

site ro
put driving.directions /drive0/driving.directions
site rw
quit

Thats what i've been doing. Then I use picker to show it on the screen. Only two problems... (1) I can't load picker without being dropped to or shell so oviously not in my car and (2) picker is only setup for up to 4 menues and your can't scroll through them. It uses the four buttons on empeg to choose a menue (up is menu 1 right is 2... etc..)

-Greg

Nothing at all except I am hoping for the ability to edit stuff while in the car, i.e. writing stuff without mounting disks rw. This would be extremely useful if someone got an IR keyboard working, but would also have some other applications...

Right now my selfish reason for wanting the ability to write to the HD in the car is so my lyrics scroller could be pre-loaded with a bunch of text lyric files, and the user (passenger obviously) could generate timings for them while on the road... Each line of the lyrics would be displayed, and when the player got to that line in the song, the user could click a button. This data would, of course, not be immediately written to the ID3 tag, but could be parsed and written later.

The OBD-II stuff is another area where we could use the ability to write to a custom HD partition. I'm sure we can think of many other neat applications, like recording a log of GPS data while driving (I'm sure many of the GPS units themselves provide this, though.)

All in all I think it'd be a very neat thing to have. I realize you're overloaded right now with more worthy tasks, so hopefully someone out there might have the knowledge and the desire to make this happen. I have the desire, but not the knowledge... yet.

Why not just have the lyrics premade before putting them on the player. Have you tried to set lyrics for mp3? I did this for a party and it was not fun. After find the lyrics on a website I had to sit there and press spacebar while listening to the song to set where it scrolls to the next line. Believe me, I would love to have a lyrics scroller for people to sing along to (actually this is my second thing im dying to have on my empeg, 1st is gps) I wouldnt want to have to edit them in the car. Plus opening up a way to screw up my filesystem while driving make me shutter... ; )
Just out of curiosity, hows the lyrics project comming along? If you need some help let me know. Or if you want someone to test things out i glady will. I think if anything is created for public someone could setup a webpage to post and download lyrics for songs with preset scrolls in them.

-Greg

-Greg

Instead of doing raw block io, you could just repartition the drive so you have a small data partition that doesn't take long to fsck. No need to reinvent the filesys^H^H^H^H^H^Hwheel. Or, slightly more ambitious (but not to the extent of writing a new filesystem), patch the kernel to support ext3, or even just FAT.
If you do it right the only time you need to worry about file system state is if you do something dumb like yank the unit out of the dash while you're editing something, anyway.

So, just create yourself a new partition, say "hda7", by shrinking one of the others slightly (just a couple of blocks is plenty).

Now you can write C code to access it as if it were a file, as in:

fd = open("/dev/hda7", O_RDWR);
read(fd, buf, sizeof(buf));
...
write(fd, buf, sizeof(buf));
close(fd);

and just treat it like any other file. The only difference is that the size will remain constant == the partition size.

Simple, eh?

Of course premaking the lyrics would be doable. But why not provide a method to do it while in the car? For those long trips or whatever.. Basically I think it'd be nice to have the following methods to get your MP3 files tagged with timestamped lyrics:

1. A converter/importer for existing formats. I believe there are two formats in which people have already done lyric files. I remember that one of them is .LRC, I can't remember the other. The number of lyrics done isn't THAT impressive, but here are some sites with some tagged lyrics.
http://coollrc.cjb.net/
http://filebox.vt.edu/a/aekamal/Lyrics/Tagged%20Lyrics/
http://f5lyrics.port5.com/

2. A method to do what you said you did... Get the lyrics as text files and sit at home pressing the spacebar to insert timecodes. Who says it's going to be fun? The thing is once it's done, it's done, and you could share the files with everyone.

3. The aforementioned procedure where you have the files uploaded as simple TXT files and can generate the timecodes while you're in the car.

I think this would be really flexible. Hell, if I'm in the car for eight hours listening to music, how hard is it to be tapping a button to do the timestamps? If they're not perfect, they could be edited later on.

As for my lyrics project, I just answered this question in another thread yesterday, but... Right now it's limited by the lack of a FAST graphics API that can handle the scrolling. I have to skip four or five pixels in order to get things to scroll fast enough. I am going to try to change the process' scheduling mode to realtime to see if that helps out, but I haven't had time to do that yet. Right now it's just reading text out of a flat file in a format similar to the LRC format, eventually I would want it to read the timecodes out of the ID3 tag. I haven't decided if I'm going to use the ID3v2 timecode tags or just have the text stored in a comment field, a reliable ID3v2 library has so far eluded me.

How does one shrink an ext2 partition? I've never heard of such a thing.

I know I should just wait untill someone developes something nice but I'm just kinda anxious with the awesome advancements of the empeg that I wanna try some stuff out. So my question is: is there any ease way I could get a quick menu running or something to that extent to run a few programs I have on the HD? I know this is more complicated then it sounds so im not expecting anything or asking anyone to go out of their wait... i was just woundering.
thanks.

p.s. I want to thank everyone who has/is making the empeg a VERY wounderful thing.

-Greg

Sure, Rexkp's picker.

http://rexkp.ne.mediaone.net/empeg/

Yeah, I 've been using that for a while now. The problem is I don't have a way to get it to load while its in my car. The only way I can load it is by dropping to a shell. Thats what I was trying to get acrossed.

-Greg

Backup, shrink partition, make new filesystem, restore.

More to the point, check out ext2resize and parted.

>How does one shrink an ext2 partition?

One usually doesn't. Instead, copy the data off, resize the partition using fdisk, and re-run mke2fs to recreate the metadata. Then copy back you saved data.

Much simpler would be to just delete the swap partition, and recreate it again 2 blocks smaller, giving you 4K of available space to play with.

Or, I could hack the kernel for you to provide a means of locating the blocks of an ext2 file on disk, so that you could re-write a file "in-situ" on a readonly filesystem. No chance of any fscking screw ups that way. To locate the file, I'd just have an ioctl() stub that invokes ext2_getblk() on the inode, which will return the block address within the partition. This can then be used as an offset for doing a write() on the raw partition (/dev/hdx), bypassing the filesystem code.

Cheers

Oh... Get Frank's modified_init package at fvgestel.dyndns.org/empeg

You put in a custom init which calls a shell script called userinit (be careful! make sure it's executable, no syntax errors etc.) Mine calls picker before it calls player. I can get you my init script if you'd like.

Yeah I'd like that.. Does yours run pick_list or just picker? pick_list would be nice. If you can send it over to my email greg@mandiola.com. Right not im kinda stuck on stuff cause i dont have a machine to compile. I do have my laptop but its slooooooow.
Thanks

-Greg

Well I was thinking more like this...

[stream of consciousness mode ON]

Instead of the user apps asking for specific blocks, there could be a lightweight API which takes as its inputs an application identifier and some kind of offset.

The app identifier would ensure that the lyrics scroller wouldn't ask for the same blocks that the OBD-II logger would ask for. Then the numeric index could be an offset, or maybe a block number within the range assigned to each application.

So let's say I've got an Empeg with my (now fictitious) lyrics scroller time tagger, the also fictitious OBD-II diagnostic logger, and the shopping list/directions thingie.

Somehow this API would read in (possibly from config.ini) a configuration for the "virtual disk" like this:
LYRICS, 16
OBD2, 64
SHOPLIST, 16

So it would give the lyrics scroller the first 16k, the OBD2 logger the next 64k, and the shopping list thing the next 16k. A call from the OBD2 logger would look like this:

empeg_storage_write("OBD2", 4, &buf)

When the storage API gets this call, it writes to the OBD2 "base" of 16k plus the 4k offset. Offsets could, of course, be in bytes or whatever for finer grain.

Obviously this is a bit more work than just an offset. I think If the kernel code was there for writing to a specific block, I MIGHT be able to string together the user code to call it properly. If not, I'm sure some other smart person could.

Does this API seem feasible? I think it would be a good way for users to have multiple apps which all would like to write data to the disk.

I don't know what pick_list is... haven't seen it yet.

My init script is on its way.

Cool thanks.. Its just a script that you can define the menu in and then it runs picker. Its included with the picker gz.

-Greg

Naw, too complex.

Just put the data into regular named files on an ext2 filesystem.
Once the files are there, and the filesystem is "readonly", we could just have a special "Open flag" to permit rewriting their data block(s) in-situ without updating any meta data (cannot change size, though).

fd = open("existing/file/path", O_RDONLY|O_SPECIAL);

read(fd, buf, sizeof(buf));

..

// modify the data in buf[]

..

write(fd, buf, sizeof(buf));

close(fd);

=========================

Sounds good... And if the power gets yanked during the write() the file is corrupted, but no filesystem damage is done.. right? That wouldn't be too bad. Just have to have a nice warning screen "do not power off the system" kind of like when console games are saving to their flash memory cards..

What about duplicating each file, and when a write is done, the first file is written, then the second. If the power is pulled anytime during this, the worst that could happen is that the file has to be reverted to the version right before it. Much better then just loosing it completly.

(Of course this needs the overhead of some sort of checksum/date stamp system to know what file is good and such.)

Yeah, error checking would be a nice thing to have, it'd be very similar to the way the flash blocks are written.

So who's gonna do all this?

No, actually I'd bet very heavily that even the file won't be corrupted. After all, it's just a disk block write, which will either succeed or fail at the drive. Laptop drives are good at detecting powerfail. Same sort of thing goes on today with the shuffle-order, mark-track, and "info-seek" "visual", all of which must write to disk to save their data. Even in car mode.

Cheers

Well yah but what about the case of a multi-block write? Couldn't some blocks succeed and others not? Obviously writing larger files wouldn't be an everyday occurrence but I could see it happening...

If you can guarantee that they'll happen in a particular order, just keep an overall CRC at the end of the block.

However, by the time you've gone this far, you've pretty much implemented a filesystem.

Well, sure, if your files are larger than 1Kb, I suppose it will depend upon the drive. But the IDE driver with Hijack sends 4KB at a time to the disk, and if you really want to scroll through a 4KB text file on a 64x128pixel screen.. well..

I think the odds of anything bad happening here are somewhere less than NIL in Real Life. And the worst that can happen is that part of your file will still have the old data, and part will have the new data. Not an issue if you organize your data structure in 1024-byte chunks.

Still simpler than a filesystem, of course, cuz we're letting ext2 keep track of directories, inodes, and block allocations. We're just adding code to "overwrite in place" on a selected file.

-ml

I agree. I think this would suit the needs of most people. I would have no problem organizing my data in 1024 byte blocks. So where might this rank in your list of things you'll be working on in Hijack?

Mark,

Re: "Simple, eh?"

I'm familiar with the everything-is-a-file philosophy of Unix and how to use it. Nonetheless, for the purposes being discussed, I stand by my suggestion that using a small filesystem is the most flexible solution, as well as being among the easiest.

A generic "small pieces of persistent data" filesystem which is mounted rw in the car would provide all applications with space, and a namespace to avoid collisions. The time to fsck e.g. a 1 meg partition is trivial... and if the file open mode is O_SYNC then the chances of data being lost due to corrupted metadata are pretty slim.

Oh well. Do as you please.

I just don't see how writing a new filesystem is easier than just using the existing ext2.

-ml

Hi Mark.

Say, did you implement some support for this yet? I mean the special flag for open() that allows in-situ overwriting of files even on R/O-mounted filesystems? This would be really great, and I guess the guys@empeg could also use that functionality for their software (like writing back some of the data about tracks to the metadata FIDs).

cu,
sven

Edit: PS: If anyone wondered how I kept the BBS from making the text "guys@empeg" into a mailto-link (like this: guys@empeg) automatically: I put a set of "< b > < /b >" (without the spaces) aroung the "@".

Edit: PS: If anyone wondered how I kept the BBS from making the text "guys@empeg" into a mailto-link (like this: guys@empeg) automatically: I put a set of "< b > < /b >" (without the spaces) aroung the "@".

Sven, you sly dog, you...


tanstaafl.

>Say, did you implement some support for this yet?
>I mean the special flag for open() that allows in-situ overwriting..

Not there yet. I am waiting to see if it's just so much hot air like some other "desperately needed" features have been in the past.

But I think this could be a really cool extension even for stock ["blessed with holy Torvalds penguin pee"] kernels.. so maybe I'll look at it and do a nice job on it. Someday..

Cheers

Yeah I was using that trick to avoid my smileys :) being turned into gay pictured emoticons But I got sick of doing it all the time. I'm succumbing to the lameness of the forum software... sigh. You can only "fight the man" for so long.

being turned into gay pictured emoticons

The emoticon prefers the term "jovial".

"Not that there's anything wrong with that..."

I can think of several other things to do with a small (1M) RW fs.

For small files, it's faster to sync a Palm than an empeg. For things like directions, it's easy to put them in your Palm and it'd be nice to be able to send text files from the Palm to the empeg. This would also be handy for people who leave their empegs in their cars, but carry their Palms with them. I know this requires IrOBEX and without that available in Hijack, it doesn't seem like a likely use.

When the OBD-II gang gets farther along, it will be nice to write to log files for permanent storage. This data could be used to generate graphs for display on the empeg or via khttpd (mrtg style).

GPS data would also be nice to save to log files. You could use this to plot graphs of places you've been, distance travelled, etc.

I'd even find a history of when the empeg's been on in home/car mode interesting. From those logs, I'd be able to tell how much time I spend driving on an average day.

I'm sure there's other uses too. Between those things and wanting more graphics for khttpd to serve up, I'm thinking of popping a 2nd HD in there to store my own data on ext2 fs's.

TFabris: The emoticon prefers the term "jovial".

Ummm, actually I'd prefer the term "Hot-Ass Chick"

Emoticon
Ubiquitous Internet Utilities, LLC

GPS data would also be nice to save to log files.

FWIW, Kim's GPS project currently does this. It uses a rw mounted partition for swap, log files, configuration, etc.

It seems like many people are asking for a place on the empeg they can write to for various reasons and we have that spare 32? meg partition. Why don't we just use it? fsck times for a partition that small are trivial so even if it gets fsck'd every time it isn't that big a deal as long as apps are prepared to occasionally loose data written to it. Of course if we could ext3 it that would be even better.

-Mike

Okay folks i still know nothing about programming but i know we have ftp with hijack can we do this idea for my shopping list plan?

I think I could implement something like what you described without excessive trouble. (I'm always up for fun little programming projects anyway.) I'm finishing up something else I'd like to have done for my own use though, (ran to a minor snag that I'm hoping mark can help with last night) so give me a few days and I'll see what I can do.

John

That from Ask Jeeves?

- Trevor

Yeah, I got the idea for that joke from reading about that thing on Ask Jeeves in a magazine. Funny thing is, when I tried the search, they'd already changed it (I guess because of the published article).