Any known issues with load problems and the kftpd in v128? I just had an ftp session lock, and the setail port, plus kftp/khttpd are unresponsive. Vitals show load of 202.30, 166.56, 87.something...

The button links send "GET " commands, which REQUIRE loading a page of some kind.. but you could "GET /dev/null" for really short ouput. Maybe I'll redirect "?button=xxxx" to /dev/null in v129, just for a trial.

Also, table-based CRC32 turns out to take 1/10 the CPU usage (I measured it) of the non-table version used in v128. So, I guess I'll waste another KB on a CRC table..

Cheers

Hey Mark why was site exec removed from kftpd? Permanent change or just remodeling?

No, solid as a rock here, until beta7 crashes on its own (rare, now that I have reserved=9 in config.ini).

It was giving me too much grief, so I nuked it -- non synchronous, no output, etc.. and not really required for a "stripped down" kernel kftpd.

I think just running a telnet server would be a better idea, and they're easy to install with kftpd now. I'll eventually see about program launching from config.ini, where being synchronous isn't a big deal, but I just got terribly frustrated with it all today.

Cheers

Okay, v129 will be out shortly:

-- http "GET /?button=xxxxx" now returns NO DATA WHATSOEVER.
-- http "GET /?" also now returns NO DATA
-- the .PNG encoder now uses a table-lookup version of the crc32 calculation, which reduces it's CPU load by a factor of 10 (for just that portion of the PNG code).

Nothing else (that I remember).

Cheers

Gotcha... Good reasons. So where's ktelnetd?

No I'm not at all serious about that. I was thinking of getting telnetd on my Empeg at some point but I didn't want to waste the memory. Actually I still don't.. Forget I mentioned telnetd.

Tried out your code here, very cool! Only thing is I couldn't get javascript refresh to work. So I modified your code a bit, this method of cycling is dead simple, just attach ?nocache=x to the url where x is an incrementing number. See the code attached.

Hmm.. the code you just posted was just like the one i tried writing last night. For some reason it doesnt work for me. I'll have to look into this.

-Greg

Ok attached is the most resent updates. I've done a few more things with this one. There are not more static links (unless I forgot to take one out here or there). There is also a built in option to view the empeg large or small. I couldn't find an easily modifiable fascia that would with on the 2x screen so i just blew up the small fascia. If anyone wants a better looking one I can do it, no problem. I actuly don't think it looks too bad. I also fixed a few buttons on the empeg that were set wrong.
Let me know if theres anything else I should put in here. I also tried making this out of flash and i can't get the screen to refresh. If anyone has a better way of updating the screen please post. The way right now is ok but it could be a lot better.

-Greg

A few absolute URL's (with 192.168.0.2) are still hanging around in
screenlarge.html
screenregular.html
index.html

Buttons aren't working for me on this one.. Not sure why.

Anyway Flash is nice I think a Java applet might work well. Frank certainly had that part of it nailed down with display server. Java is also much more portable than Flash.

The buttons use new features in Hijack v129. If you upgrade they should work. I'll fix the statcs ; ) . Java would be nice but I only have experience in javascript not actaul coding.. I guess its never too late to learn.

-Greg

Ok here is the latest. I went over everything to make sure it works. I also removed all the statics ip's except for the main ftp:// link. Anyone know how i can make this load to show the directory of the empeg without having it static? I tried "/" but it didn't work. MAKE SURE YOU HAVE Hijack v129 or this wont work without modifying. You should be updating Hijack every release anyways, hehehe.

-Greg

Hey Mark,

It looks like IE6 doesn't like the FTP server in v129 anymore. In v128, it worked fine, but now with v129, IE crashes as soon as I try to contact my player via FTP.

HTTP still works fine though.

I'm runng the XP version of IE6, BTW.

Hmm. It works fine for me. I just tried it on my WindowsXP box with IE6. Check windowsupadate I think there was a something that needed to be patched with the ftp and some other stuff in IE6. Plus if you havnt already you can patch the nasty exploits that were found.

-Greg

Actually, this is exactly how I got into mp3s.

Back at warwick university, where myself, Mike, Roger, John and John also went (though not all at the same time), there was a terminal room in the CS dept called the Fyshbowl, because it had glass walls.

This is where all the geeks hung out, despite the room being starved of decent hardware (lots of ADM-3As, a couple of IPCs, several ELC(?)s and one Sparc 5 a bit later on).

Anyway, people got to finding sun 8khz mono .au files around on the net, and built a jukebox/chat server. You could log into it, chat, search for music and play it (queue it up), which was used for general entertainment for everyone in the room.

When the sparc 5 came on the scene with its bigger speaker and better sound (22khz?) people found l3dec and integrated it - it didn't have enough CPU for full rate decode though! I used to record (at 22khz) my CDs on my pc through an analogue connection, mp3 encode them and bring them in on floppies to build the library.

Later versions even had fair queuing, so if someone had queued 10 files then another used queued 1, it'd go in as nr 2 in the list.

Richard Neal was the original perpetrator

Hugo

Same problem here. With W2k and IE60. V128 works also ok.

bye

I just checked Windows Update again, and theres nothing new in there. I check it at least once a day, so I'm usually pretty on top of updates. The only stuff that I haven't downloaded are completely nonsequiter, like the "Euro Conversion tool". Don't think the stuff that's in there has anything to do with the problem I'm seeing. Keep in mind, that it works fine with v128. I backgraded to that, and sure enough, it works fine again.

This is awsome! GREAT JOB!

this could be a browser problem I was using IE 5.0 what browser were you using? Javascript is notorious for not being standard. I get the feeling also that IE doesn't handle PNG image rollovers as smoothly as it does gif and jpg files, the support for png files in IE has never been perfect.

Well, that is easy enough to fix: just insert a Mandrake-8.1 installation disk into the CD-ROM tray, hit the reset button, and choose "fully automatic" installation.

Or you could try connecting up your serial port, setting [hijack] kftpd_verbose=1 in config.ini, and then running ftp again, and sending me some useful diagnostics.

Cheers

>Ok here is the latest. I went over everything to make sure it works.
>I also removed all the statics ip's except for the main ftp:// link.
>Anyone know how i can make this load to show the directory
>of the empeg without having it static?
>I tried "/" but it didn't work.

Well, now that you've got it looking really pretty-like, I've probably gone and broken it again.

Hijack v130 is out, and the changes that affect your awesome scripting are:

-- http "GET /some/path?options" no longer returns NULL, but rather fetches the path as in pre-v129 versions. So if you want button presses to not waste bandwidth, then point them at /dev/null, as in "GET /dev/null?button=20df12"

-- http "GET /any/directory/?anything" now skips the search for "index.html". This means the "ftp://static_ip/" can now be replaced with a simple "?"" (I think), or perhaps "/?"

Other new stuff in v130:

-- new "SITE RW /" command: rw remount of / only
-- new "SITE RW /drive0" command: rw remount of /drive0 and /
-- new "SITE RW /drive1" command: rw remount of /drive1 and /
-- ftp "CWD" command now validates the new directory path
-- the .png generator is faster and smaller than before
-- the .png generator is now re-entrant, allowing multiple simultaneous connections to /proc/empeg_screen.png

Cheers

I did again some tests and found the problem. The problem is when I start to edit the index.html. If I do open local on my PC the original file from empegweb13 then it works. But after editing with Frontpage or Ultraedit my Internet Explorer 6.0 hangs.

I did only change my IP Address.

Any idea why?

bye

Sorry,

Some addional information. If I change the IP back to 192.168.0.2 then it works again...So I think there is a bug somewhere in the empegweb! But for mandiola and mlord is this peanuts .

Thanks

At this point, I haven't the foggiest what you are having a problem with. Can you post a URL that does not work for you? Or is the FTP server not working (try something like ftp://my.empeg./proc/)

Any chance of using meta tags to refresh ONLY the empeg_screen.png image, rather than the current javascript? I ask because Communicator doesn't do refreshes for the latter method (under Linux). Mozilla works, though, but 0.9.7 is wwwaaaayyyy too buggy for general use yet.

Cheers

Okay, I replaced the FTP reference with a simple src="/?" for Hijack v130, and it works well. But if you descend a directory, and then click on "..", one end's up with a nested page -- because of the "index.html" name of the main file. So, I've renamed "index.html" to "RUNME.html" to get around the problem. Works FANTASTIC now!

Now all that is needed is a little more JavaScript for the button presses, to distinguish between LONG and SHORT presses somehow.

In aid of this, I'll add a "buttonraw=" command that only sends a single press or release code into Hijack. The current "button=" command automatically sends a press followed by a release, which makes it harder to do synchronous press/release events from a web browser..

Look for "buttonraw=" in hijack v131 shortly.

Cheers

Mark,

I did delete all the empegweb Files on my Empeg. And then the HTTP and FTP Connection to my Empeg is working (Hijack V130). But If I go to install the latest version 1.2 or 1.3 from empegweb it does not work.

This means: I did the change the IP-Address in the index.html from 192.168.0.2 to 10.0.1.10. And then It doen't work. I did try to browse empegweb on my local machine. Not on the Empeg. But the same problem is also on the Empeg. I did only try to get out where excactly the problem is. If I go and change the IP-Address back to 192.168.0.2 then I can browse it locally again.

So I thinks there is a little problem in the Empegweb application.

That's reasonably easy, by using the mousedown and mouseup events (and a timer variable) instead of the onclick event.