Okay, Hijack v114 is out. Please upgrade.

The previous 3 or 4 versions have a nasty bug whereby hijack does not restore it's state correctly on boot. This has been fixed, along with some more subtle things.

http://empeg-hijack.sourceforge.net/

Cheers,

-ml

Hehe. Thats why my player wouldn't restore visuals ; )

Thanks

Greg

Thanks Mark. That would be why my player was booting slowly, and why it never remembered what playlist I was on or what song it was playing. I'll forgive you this time, but try not to let it happen again :~)

Thanks Mark for your remarkable response to reported bugs and requests for additional features. All hail Mark Lord, or should that be Lord Mark?

Mark, for me the kftpd_control_port and kftpd_data_port config.ini options are no longer working in this release. I have them defined but when my player starts up it says:
kftpd: bind(port=21) failed: -98
kftpd: make_socket(port=21) failed

Because it's conflicting with my normal FTP server.

The khttpd is also conflicting with displayserver but I haven't tried changing the khttpd_port yet. Just wanted to see if you know of anything that would cause this to happen.

Yeah, I broke the port overrides.. oops.

Hi Mark,

I have the following in my config.ini:

initial.H=000000.L,ffffff
initial.C=20DF0B
80b44918=000000.L

SO that when I plug it in at home it always powers off and in the car it always powers on. The car bit doesn't seem to work. Can I use both initial.C and initial.H ?

I don't know. I have never personally tested .C and .H
because I've been waiting for others else to try it and report back. If nobody reports back, I figure I can remove the feature again!

But since you reported back..

Can you play with it some more, and see if you can prove one way or another, that .H works ?? And then try again for .C, and report back.

Thanks.

Okay, I've just completed (I hope) a major overhaul of the kftpd/kttpd servers in Hijack. Version v116 is now out at http://empeg-hijack.sourceforge.net.

The current status of the HTTP server is:

-- works very well as a filesystem browser
-- only downloads files, no uploading
-- sends audio files as "audio/mpeg", for streaming music applications


The FTP server shares about 90% of the same code base:

-- implements a very rich FTP subset
-- can upload / download / delete files
-- can create / delete directorys
-- can change file / directory attributes

Note that in order to upload/modify anything on the player, you first have to drop to shell mode (developer version only) and issue the "rw" command from the shell. Don't forget to do "ro" again when you're done, or you'll have to endure a very long filesystem check the next time you sync!

In my testing, I have found that the Unix/Linux "mirrordir" utility is happy with the FTP server, and can be used to backup and/or restore much of the player's filesystem from a Linux box.

Enjoy!

This release should enable changing permissions on files and directories through FTP, correct? What command is actually sent to the FTP server for this to work?

My FTP client issues the chmod command, but the server returns "bad command". Should this work, or do I misunderstand what file / deirectory attributes is referring to?

I have no trouble writing or deleting files.

Also...I don't know what HTTP is supposed to be doing with audio files. I see the file sent to my browser as text, proceeded with text that looks like it should be headers, like:
Content-Length: 5463272 n: close Accept-Ranges: bytes Content-Type: audio/mpeg 9461 ÿû�l�O
(followed by lots and lots of garbage)

Is this a problem on my end?

wow this is amazing! at last i can easily take things ive downloaded at work home! great work mark!

Thanks Mark,

Don't take it out PLEEAASE.

Here's the deal.

Initial.H works fine
Initial.C does not work if it appears after the initial.H line in config.ini
Initial.C does not work if it is the ONLY initial line
I have tried initial.C=different codes just to see if they were the prob.
Initial.H only works at home as expected.

This feature is the answer to my startup options in another thread, so would be very useful to me.

As an aside, when using the FTPd (in v115) my WSFTP32 (old but trusted) insists on sending HELP to the empeg after logon, this is invalid in your implementation. Could it be supported even if it returns nothing?

The HTTP and FTP stuff is great, just what I always wanted.

Would you consider adding RW, RO as menu items on the Hijack menus so that I dont have to use my serial cable?

Franks DS2 seemed to add these as options on the quit menu but I have had varying success with DS2. DS1 worked fine but doesn't give these mount options.

>My FTP client issues the chmod command,
>but the server returns "bad command".
>Should this work, or do I misunderstand
>what file / deirectory attributes is referring to?

There is no such command in the FTP standard (RFC-959).

However, most sites implement this using the "SITE" command, as in "SITE CHMOD 0755 filename" -- which is exactly how my kftpd does it.

Your client is broken, but if you can send me the exact string that it passes to kftpd, then I'll see about a server-side fix. To see the strings, add this to your config.ini, and then monitor the serial port while using ftp:

[hijack]
kftpd_verbose=1

Cheers
-ml

>Also...I don't know what HTTP is supposed to be doing
>with audio files. I see the file sent to my browser as text
>proceeded with text that looks like it should be headers,

That's pretty much what you should see, except that the headers appear to be broken in v116 -- fixed for v117 (out shortly).

So listen to streaming audio with v117, just configure the "mime types" or "helper applications" in your browser to feed data of type "audio/mpeg" to your favorite streaming mp3 player. Many browsers will do this automatically for you.

Cheers

Oops.. previous post (now corrected) should have said:

[hijack]
kftpd_verbose=1

The HTTP and FTP stuff is great, just what I always wanted.

>Would you consider adding RW, RO as menu items
>on the Hijack menus so that I dont have to use
>my serial cable?

Yes, that's something I have in mind for a future release,
although I'd like to do:
(1) just have arbitrary menu exec commands configurable in config.ini, and (2) be able to do rw/ro with just the "consumer" image installed (which doesn't actually include those commands on disk..).

Cheers

Okay, I've added the ftp HELP command for v117.

I'll take a look at .C before I release it, though. Maybe that can be fixed in time for v117 as well.

Mmm.. on further examination, your client is probably doing "SITE CHMOD", and the server has a bug: "SITE CHMOD" fails if the full pathname was not specified from the root directory. I'll fix that bug for v117.

Cheers

-ml

I'm using 177 now.

I mispoke about the command my client was sending. It was sending the SITE command:
SITE chmod 755 testfile

There are two problems with this
1) Apparently "chmod" is only accepted in all-caps.
2) CHMOD 755 doesn't work...it must be 0755

I know this because I can send custom commands to the server via my client, and using SITE CHMOD 0755 testfile works fine...it's just not the way my client sends it. Can this be changed on the server, so that CHMOD can be lower case and the three digit numeric value works?

Wouldn't it make more sense to use another client ?

Well, no...it wouldn't. First, I really like my client. I've used several, and this is the one I like the most. Second, I would think it'd make more sense to try to make the server as cross-platform and client-independent as possible. This way it won't be a problem the next time some other user out there with a different client that behaves similar to the way mine does. Make sense?

When I write a web-based app, for example, and it doesn't work in Internet Explorer, am I going to tell all my users that you have to use Netscape? Of course I'm not. I'm going to rewrite the app so it works in as many client configurations as possible.

Okay, good one. I had forgotten to go back and implement strncasecmp() for keywords -- the RFC says the server should accept mixed case keywords. Done for v118.

The mode is tricky.. it really is supposed to have a '0' to indicate "octal", but I'll have the code just tolerate modes without the leading '0'.

Cheers

it really is supposed to have a '0' to indicate "octal", but I'll have the code just tolerate modes without the leading '0'.

Qrious; will it accept 4-position numbers? (ie 4755) Not that I imagine much use for it though...

/Michael

Yes, it blindly accepts any length of octal numbers for the mode.

-ml

Just thought I'd let you know that I've dumped 600 Megs of zip files onto my empeg to take home using Hijack v117. The transfer speed was not to bad. I'll let you know if I have any problems with the zips.

When i try to connect with CuteFTP i get this error. This doesn't matter to me much cause I can use other ftp programs and they work fine... it would just be cool to be able to use cuteftp.

*** 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 anonymous
230 Okay.
STATUS:> Login successful.
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

In reply to:

---

When I write a web-based app, for example, and it doesn't work in Internet Explorer, am I going to tell all my users that you have to use Netscape? Of course I'm not. I'm going to rewrite the app so it works in as many client configurations as possible.

---

You don't work for microsoft, that's for sure

Just tell your CuteFTP to not use "passive" ftp. It will work.

-ml

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

So far today i've been messing around with picker | emptris | disp ...etc... I made a short menu system that you can choose to play emptris or run other programs,etc... and goes away after the timeout if no buttons are pressed... Now is there any easy way I could get this to load when a certian button or something is pressed?

I know this is probobly the worst way of doing it but it was the only way I could think without writing programs that needed to be compiled myself to run programs like emptris for other people to play while in the car...

-Greg

Mark,

I have just tried the initial.C again with V127.... No luck.

I tried to disable your "Restore DC Visuals" just in case this was the cause but it still does not seem to do these commands at startup on DC.

Did you attempt a fix back around v116?

Okay, the .C and .H should now be working as advertised.. Hijack v132.