I know this was discussed before and I have read Drakinos page http://central.miniinfo.net:8081/empeg/. I can get dnetc to run just fine. The commands are like this:

/empeg/bin/player -s- &
rw
./dnetc &

Here is the question: If i understand it correctly, it basically involves putting the drives are in rw mode, while the player is running. Should that concern me?

Armin

As long as you remember to put them back to read-only before you remove the power or start a synch, and as long as you don't go driving with the drives as RW, you should be OK.

Thanks, Tony, but...

...part of the idea was to _drive_ an rc5 crunching machine!

Armin

Oh. Then I wouldn't.

What I did (and never documented, damn) was to run the buffers off a ram drive in car, then I just periodicially had a script pull the buffers back to the disk. With the quick remounting Hijack can do, it should be possible to do this without any damage to the empeg hard drives. I was tempted at one time to look into putting a symbol on the screen when it was writing to the drives, but I think Rc5 will be long since over before I get time to do it.

Oh yeah, biggest problem with this was when I had d.net running on AC power, and would use emplode. Odds were that eventually my timer would come up and screw with the mounting of the drives. I've asked a few times about ways to detect emplode syncs, but never got anything solid enough to implement quickly.

I agree, rc5's days are numbered, but this is a learning exercise for a linux-newbie liek me. I suppose you don't recall how you set that ramdrive up and what the script looked like?

Asking as an even-more newbie (and one that DOES work with linux - on desktops/servers) Why all the fuss about putting the drives in RO mode while driving / syncing?

What does having the drives in RO mode prevent that can't happen in RW mode? (Other than writing, I mean..)

Just curious..

They're not in RO mode while synching but they are while driving. If a drive is in RW mode then as data gets written to a disk it doesn't necessarily go straight on the disk. It can be cached which means that potentially that data will never get written if the unit is powered down without warning. Since basically nothing ever needs to be written while driving/listening then this is not a problem. However it does seem the player must mount RW some times when it saves things like the plays counter and the seek tool info. I'm not sure where this data gets saved.

In the case of a PC this generally doesn't happen since when you shut down all this cached data is written to the drive. In the case of the empeg, the ignition can turn off at any time without warning. Imagine having to shutdown your empeg every time you go to stop your car...

I think you may be thinking that RW vs RO mode means that the drive can't be damaged. In terms of the drive it doesn't have a RO mode. It's the filesystem that does all the RW/RO stuff. Edit And technically Windows is in RW mode 100% of the time. It doesn't have a RO mode.

Does that it explain it well enough?

"it does seem the player must mount RW some times when it saves things like the plays counter and the seek tool info. I'm not sure where this data gets saved. "

My guess is there's a little bit of flash reserved for this purpose.

In reply to:

---

My guess is there's a little bit of flash reserved for this purpose.

---

Yeah I thought flash too, but when people have over 10000 songs (I think I have seen someone up to 14000 odd), 1Mb of flash doesn't go very far. Particularly when it also has to hold the bootloader and a 500k kernel. You're only talking 50 bytes a songs for 10000 songs then. Unless it just uses the available space and then stops - but I doubt that.

There are a few partitions like /dev/hda3 which is listed as "empeg's dynamic data partition". I'm guessing this is where it goes. As far as I'm aware it never gets mounted since it doesn't contain a partition - rather it's raw data. I assume there is just some sort of checksum per song which would get around the partially written data problem. But even then it's only 16 megs.

Anyone in the know care to comment on this?

If the drive is in RW mode and is not unmounted cleanly, the ext2fs driver will force a filesystem check on the next boot, which can take a considerable amount of time. Considering that no data is really going to be written to that filesystem, it probably won't actually get corrupted, but it's possible nonetheless.

Having the filesystem mounted RO will definitely prevent a forced check and corruption.

Maybe someone could get ext3 support into Hijack. This should allow you to mount RW without fear of corruption or forced checking, even though you might lose data that is being written.

ISTR that ext3 support on Linux 2.2 on ARM is a bit flakey. Post player-2.0, there's talk of moving the car player to Linux 2.4, and then using ext3, but we need to update the sound/display/etc. drivers first. Unless anyone else fancies doing it ?

Correct, the play counts and seek tool info are saved on /dev/hda3.

ext3 on Linux 2.2 is flaky in general even on i386 as far as I am concerned. Basically, the newer ext3 stuff stopped getting applied to the 2.2 tree. If you want ext3 you pretty much have to go to 2.4. BTW: I did attempt ext3 on an i386 2.2 kernel and had limited success. I bit the bullet and went to 2.4 and everything's sweet.

Yeah, I'm running 2.4.17 on my home box, so that I can use ext3. My point was that we'll need to port some of our drivers from 2.2 to 2.4, and then we can support ext3 on the car player.

However, since all of the source for the drivers is included in our released kernel source, there's nothing stopping someone else from porting them (hint, hint).