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