I have only recently tripped across this product and plan to get one for my next car.
Questions:
Which distribution of Linux is used and how fully featured is it?
Is it possible to FTP, Telnet or even WWW into the player? This could be handy for configuring a web based inferface for the controlling software, building track lists, organising tracks, uploading new music, etc...
Is there enough room left in the unit to install an ethernet card? Access to the player at 100Mbs through UTP Cat 5 would be real cool :)
Do you need to access the player using the provided software? ie. Could you FTP new Mp3's to the player which would automatically know of their existance?
Leading from that - does the player build an index of available tracks on boot, during transfers or do you need to invoke an index rebuild?
Additionally - I am very excited about the potential of such a device. With the use of additional I/O and software you could quite easily intergrate it into other aspects of your car. Alarms, engine control / management, remote control of windows / sun roof, GPS, engine imboliser, anti-theft, tracking .... the list is endless..... Imagine being able to interrogate your car remotely (where is it? how much fuel? Speeds over the last few days (for when the kids borrow it).

> Which distribution of Linux is used and how fully featured is it?

Cut down version of debian. But you can un-"cut it down" as much as
you like. See here for how to do it: Mars

> Is it possible to FTP, Telnet or even WWW into the player?

Yes, you can run pppd on the empeg (see above url) and then run telnet
or a web server, or ssh or whatever you want on it.

PING empeg (192.168.205.1): 56 data bytes
64 bytes from 192.168.205.1: icmp_seq=0 ttl=255 time=29.2 ms

> Is there enough room left in the unit to install an ethernet card? Access
> to the player at 100Mbs through UTP Cat 5 would be real cool :)

I really don't understand why they didn't put ethernet in instead of USB.
I bet they've spent countless hours on USB drivers when they could have used
an already working ethernet driver. Surely you can get hold of motherboard
mountable ethernet chips?

> Do you need to access the player using the provided software? ie. Could
> you FTP new Mp3's to the player which would automatically know of their
> existance?

You can use the windows software or the linux software (so far) to upload
data, or you can just copy the mp3s in over, e.g., ppp and create the
appropriate fidxx0 and fidxx1 files, and then rebuild the database from
them. In fact I'm thinking of abandoning the upload software and writing
a perl program on the empeg to create an automatic hierarchy of playlists
from the ID3 tags in the uploaded MP3s, i.e. /genre/artist/album/songname

> Leading from that - does the player build an index of available tracks
> on boot, during transfers or do you need to invoke an index rebuild?

At various times, on demand, and depending upon whether the empeg database
is missing/corrupt. Not exactly sure when, but it's possible. I'm sure
empeg could be persuaded to rebuild based on say the existence of a
flag (/drive0/REBUILDDBPLEASE).

Paul

Our reason for fitting USB and not Ethernet is down to product placement.

Whilst we love our techie clients, and acknowledge that at the moment the majority of our userbase falls into this category, the fact is that empeg car is primarily a consumer product.

USB is fitted as standard to virtually all new PC's and Mac's, and it's plug and play. Can you imagine the support overhead if we had to help thousands of consumers install network cards and set up TCP/IP?

This may not be the ideal solution for many people on this board, but we are convinced that it is the correct solution for the vast majority of our clients.

Rob

And it will be fine when us techies can run ppp over the usb.. =)

Jazz
(List 112, S/N 00030, 4 gig blue)

> USB is fitted as standard to virtually all new PC's and Mac's, and it's
> plug and play. Can you imagine the support overhead if we had to
> help thousands of consumers install network cards and set up TCP/IP?

That's a reasonable argument, but I'm not convinced. At least the percentage
price increase for including both would not seem to be very much.
As for complexity, the empeg could run a DHCP server and reduce the complexity
to that of installing a network card (PCI network cards are as plug and play
as USB apart from being internal). Better still, but I've no idea about the
cost, could be a PCMCIA slot, then customers could choose between nothing,
USB, Ethernet 10/100, or wireless ethernet (I use 802.11 zoomair 2Mb) cards.
With the wireless you could upload stuff whilst the radio is still in your
car! I use the Zoomairs on Linux and they rock.

Paul

The price increase would be significant: the board is full, so unless we move to double-sided surface mount (which ups the price a lot) we simply couldn't fit it in - you may have noticed there's no back panel room either when you take into account some things like PSU capacitors which are up against the back panel.

USB is on-chip on the strongarm (although it's broken in the current SA silicon, so we have to use an off-chip USB - it's still several times cheaper than an ethernet transceiver plus pulse transformer plus RJ45 socket). Later versions will move to the on-chip USB.

DHCP doesn't help when users break their dial-up PPP setup with ethernet settings and come moaning to us :)

PCMCIA needs various things on both the PSU front, size, etc. Add to this the lack of USB slave cards (a USB host card is pointless as it can't connect to a PC without *another* box between the two).

100Mbit ethernet is out as there isn't the bus bandwidth (it's simple ISA basically, not PCI) - and almost *all* 100mbit chipsets are PCI-only (there may be one which isn't, but it's unlikely to be cheap).

Hugo

OK. Given that there is only a ISA bus in the unit there is not much point installing a NIC over USB as it would only be 10Mbs. Pity the Motheboard doesn't have one built in :(
DHCP - not a good idea if you plan to connect it to an existing network which may already have one (like me). It would probably be better just to hard code a reserved IP address into it (192.168 or 10.).
I love the wireless idea!
Paul, you hit the nail on the head. I wanted to know if I could FTP all my Mp3's into the unit then ask it to rebuild the database using the id3 tags. This is then used to do searches by artist, album, track name, track number, etc ...

Might be a dumb suggestion as I certainly don't prefess to know about the finer points on ethernet hardware, but... wouldn't it be possible to effectively mount an ethernet card in place of say the second hard-drive (assuming you could make an ethernet card small enough).
Then you'd just have the fun of finding somewhere on the caase to run the RJ45 socket to.
I don't know if this is possible, and knowing how much I hate "specials" I wouldn't blame you guys for not even considering the idea, but it could perhaps be done and marketed as the super-developer version or something like that (with a suitable price increase ;o)


- Given two theories.... pick the one that sounds funniest -

> Paul, you hit the nail on the head. I wanted to know if I could FTP all my
> Mp3's into the unit then ask it to rebuild the database using the id3 tags.
> This is then used to do searches by artist, album, track name, track number,
> etc ...

I finally got so frustrated in uploading my music that I came up with a
solution. This isn't any fault of the empeg at all, it's just that I have
stuff all over the place, some of it has track info in the name, some in
the ID3, some has none, some I ripped with access to CDDB, freedb or
cdinfo, which all have differing databases, and some of my CDs aren't
in any of them. The problems are endless. Anyway here's my solution:

I did a find for all files on my disks that are bigger than 1MB and have
an MPEG magic, then made a symlink to /music/`md5 of first 100KB`. I
then compiled rsync, started pppd on the empeg,
then rsync'd all my MP3s to the empeg. I then wrote a script to generate a
set of FIDs for the empeg-car playlist, unattached items, and a misc playlist
containing all the MP3s. Deleted /drive0/var/* and then forced database
recreation with emptool -d.

So what does that achieve?

It seperates the tasks of uploading, ID3 labelling and playlist creation.

I can write another script that will generate the track info from the ID3
and organise into playlists. I can do that at any time.

If the track doesn't have an ID3 and I add it later, rsync will just transfer
the additional data at the end of the file.

I can move MP3s around on my PC, and rename them, since the MD5 of the first
100KB will stay the same, meaning I won't have to ever transfer an MP3 twice.

This is all on linux and probably won't make sense if you're used to windows.

Paul

I've been solidly copying files in to my new 20Gb empeg for the best part
of a week now using emptool 0.83 over the tediously slow serial link (not
having tried to get USB working in linux yet) but it hasn't been easy.

Originally I used ``upload -r'' to do my whole mp3 directory tree,
but doing 20Gb in one go seemed to be a bit much for it to cope with.
So I tried doing it one disk at a time (each disk is in its own directory
tree). Then I realised that certain non-mp3 files I have lying about
got uploaded too, and that some of these files seem to cause emptool to
core dump. I can't find the source for emptool anywhere so I don't know
if this is a plausible reason for the crashes of if I was just running
in to size limits again.

To avoid that problem, I tried uploading individual files. I'm now
running a simple expect script to emptool which takes a list of pathnames
and converts them in to the necessary ``mklist'', ``cd'' and ``upload''
commands to preserve the tree structure. This potters along for a while
before emptool falls over with one of several messages: occasionally
the core dump I got before; more often ``Failed to write tune data''
(there's en error code there too which I have neglected to record).
My script isn't very bright and sometimes manages to blunder on past
this error. When I eventually intervene manually, I usually have to do
a database repair and maybe re-link a few files from the ``Unattached
items'' directory, then let my script carry on. Last night, however,
I found that repair reported 930 errors and moved every single one of
the 871 tracks I have uploaded so far in to an undifferentiated heap in
the ``Unattached items'' directory. What a mess! Using the ``lookup''
command and moving things about by FID I was able to automate sorting
it all out, but I now have a few duplicates that I don't think were
there before.

I already have a well-organised collection so I just want to do
the equivalent of:
scp -r /home/mp3/* empeg:/
The post to which I am replying describes a system using rsync that
sounds exactly like what I want. Where can I find out how to do this?