Cool.

I too am using my Empeg as a portable (60GB) backup device.

Cheers

I tried that.. and i got:

*** CuteFTP Pro 2.0 - build Nov 20 2001 ***

STATUS:> Getting listing ""...
STATUS:> Connecting to ftp server 192.168.0.2:21 (ip = 192.168.0.2)...
STATUS:> Socket connected. Waiting for welcome message...
220 Connected.
STATUS:> Connected. Authenticating...
COMMAND:> USER
230 Okay.
COMMAND:> PWD
257 "/"
STATUS:> Home directory: /
COMMAND:> FEAT
500 Bad command.
STATUS:> This site doesn't support the 'features' command.
COMMAND:> REST 100
500 Bad command.
STATUS:> This site cannot resume broken downloads.
COMMAND:> TYPE A
200 Okay.
COMMAND:> PASV
500 Bad command.
ERROR:> Syntax error, command unrecognized.
ERROR:> Failed to establish data socket.


-Greg

The "PASV" means your ftp client is trying to do "passive ftp". Tell it not to do that, and life will be good. Happy Days, chap!

-ml

Okay, v118 is out, with all of the minor bug fixes (except ".C") for problems that have been reported (few).

Also new, on an experimental basis, is /proc/empeg_screen.tiff

If you access this file (using kftpd or khttpd, for example), it grabs the current empeg screen buffer and returns it as a .tiff (image/tiff) file -- many browsers understand this format, and all image editors (eg. gimp, photoshop, xv) do as well.

I will likely convert it to .png soon, for better browser compatibility. Then all we need is some html and javascript, and we'll have almost full displayserver equivalency from the kernel and your favorite web browser. I'll add http "POST" for remote button presses later as well.

Cheers

-ml

I don't know if I've said this lately.

Mark, YOU DA MAN.

Impressing. Really. If I think of how the empeg will look like in just few months if Mark keeps improving hijack at this amazing pace... wow!

Sheesh! It's been almost three months since I last heard that!

Cheers

-ml

ML,

You're my hero. Seriously.

"...It's full of stars....."

This is so amazing. Mark, you are unreal!

Thank you

TommyE

The png option would be appreciated, IE does not appear to like TIFFs.

Also, some apps don't like the tiff you are generating. Photoshop shows them fine, but ACDSee strectches the images so that it is 128x512 in size.

A png file should get it to fit in a single Ethernet packet too...

>Photoshop shows them fine, but ACDSee strectches
>the images so that it is 128x512 in size.

Well, actually, the latter behaviour is what I was trying to achieve, using the "resolution" (scaling) parameters embedded in the .tiff file. The problem with 32x128 "native" resolution is that it's just plain too tiny to see very well on a 100dpi screen.

The scale factors I encoded are supposed to cause it to be displayed "actual size", the same dimensions as the actual Empeg front panel display.

But no bother.. .png is a completely different (and way more fscking complex) format for this.. ugh.

Cheers

-ml

How about an RLE encoded BMP instead then ?

Actually, .BMP was the first attempt.. none of my browsers here supported it (I suppose IE probably does, but nobody else).

Cheers

I haven't found a browser that supports tiff yet either, neither IE or Mozilla do...

Okay, Hijack v119 is now out at http://empeg-hijack.sourceforge.net/

New in this version:

-- ftp/http error message always go to the console, even if verbose=0
-- ftp/http directory listings are MUCH faster now
-- some built-in mime types for common file extensions

The faster directory list enhancement makes a big difference when accessing the /fids/ directory on a unit that has a lot of tunes installed -- really speeds up restore/backup functions.

Cheers

-ml

Mark (or anybody who can help me), I searched and could not find it, so, sorry to bother, but did you implement a command in the config.ini to change the port of the http server, just like the one for the ftp server?
Thank you!

I believe it's in khttpd_port, but bring up the kernel patch file (either in your browser or notepad) and do a search for khttpd.

It didn't work. Maybe it has not been implemented yet...

I think the "[hijack] khttpd_port=nn" option for config.ini may have been broken for a release or two, but it should work fine in v118 and v119.

Cheers

-ml

Hi,

Your improvements are totally awesome, dude! :-)

How about a SITE RW and SITE RO (and the kftpd should automagically do a SITE RO if a user invoked SITE RW after logging off).

I just got my "virgin" RioCar plugged in. It doesn't get anything uploaded until:

- Upgrade to 2.0b7
- Patch logo to empeg Tux
- Install newest ML-Kernel.

Which doubles it's value to me, compared to the stock V1.02 it ships with.

The NFS-software for my Psion implements remote control
by "chdir"'ing into "virtual" directories and "cat'ing" virtual files.
I guess posting to /proc woould work, but not be as "user friendly" from a web-browser /ftp browser

Marius (Escort Cab + Mark II)

I couldn't get it to work in 119, but it works perfectly in 120. Thank you!

Now that's interesting.. I wonder why v119 didn't work -- no difference in that code at all for v120.. must be a race in there somewhere, probably with the semaphore. I'll fix that by initializing the semaphore earlier.

thanks

Well, everything under /proc/ is virtual, files or directories. I am not sure what you meant.

Cheers

-ml

Yes... of course... In my above mentioned psion remote control, these files are not present on the actual filesystem, only when accessed by NFS, and the NFS-daemon does not treat them as files, but as commands.
I guess the /proc/ files could be used directly in the same manner?

Could you have a file /proc/empeg/play that will do a "play" function when *read*?

Marius (Escort Cab + Mark II)

>Could you have a file /proc/empeg/play
>that will do a "play" function when *read*?

How about when *written* instead?

Something like:

## send "play" button code:
echo "20df18" >/proc/hijack_input

## send "next track" button code:
echo "20df11" >/proc/hijack_input


???

I realise it will be easier to implement on the server-side when
you activate by writing to /proc files.

My reason for wanting action when read is that I can point my FTP-client to /proc/, and then just click each file to achieve
the relevant "action".

Otherwise, I guess would have to have a fine that I upload each time, and check the name and content before uploading etc...

But... don't get me wrong. The support you are suggesting is 99% very very good for me :-)

Marius (Escort Cab + Mark II)

Exactly what I wanted to ask for (well, either a pseudofile in /proc or a device file in /dev...)

For now, v123 has limited SITE EXEC capability: the command output is NOT captured and returned to the user, so you have to ensure that the command is correct before sending it.

For example, this will not work: SITE EXEC ro
But this example here will work: SITE EXEC /bin/ro

The command output goes to the serial port, instead of back to the user. I will probably leave it like that for a while (BIG JOB, lots of code bloat needed to fix).

-ml