I dont seem to be able to get that to work here. It requests from the empeg, but the image is not refreshed.

The meta tag refrest works, and is a fast update with 0.5 and below although a little flickery but as mentioned crashes the machine very quickly.

On a side note a friend who said it was too expensive for him in the xmas rush is now immensely jealous

What browser are you using? I think I may not be using one of my old universal methods for referring to an object, so it may not work outside of IE.

I'll dig up some of my Javascript coding to see the best way to do it.

Forget *FILE* management. How about a Jukebox manager?

Basically an HTML interface that *EVERYONE* in the office can use to "request" songs. Songs that are requested are queued up. The empeg can then be hooked up directly into the pager system of the office, and voila!!!!

Calvin

Forget *FILE* management. How about a Jukebox manager? Songs that are requested are queued up. The empeg can then be hooked up directly into the pager system of the office, and voila!!!!

That would be a cool thing to implement as an external program using the Emplode protocols. You could distribute it as a client program to each of the workstations. Each workstation could insert one song at a time (using the emplode protocol's "insert" feature), and then would lock the user out of inserting anything for the next ten minutes or so (so no one would monopolize it).

A little work with password protection would need to be done to prevent someone from just running Emplode and taking over the player, but it's do-able.

Sounds like a fun idea for small offices.

Since Mark implemented HTTP methods for controlling the player.. it seems like it's one step away from complete HTTP access to the player. You don't need the empode protocols (though it can be done with I guess).

It seems to me, that you have designate one machine as the "gatekeeper" to the empeg, install the jukebox queue there, and that machine has the necessary software to connect to the empeg and insert songs, etc. The "gatekeeper" machine is also running a web front end that loads the queue. Pretty simple, no need to install any client programs anywhere.

Calvin

Inserting songs into the players current playlist pretty much has to be done with the emplode protocol. However, there could in theory be a daemon running on the player that connected locally using the emplode protocol, but then accepted HTTP request and passed them through to the player.

This sort of thing doesn't belong in the kernel however...

Since Mark implemented HTTP methods for controlling the player.. it seems like it's one step away from complete HTTP access to the player. You don't need the empode protocols (though it can be done with I guess).

I guess you could do it that way, yeah, my point was that it sounded like a good project for a third-party app that didn't depend upon a hacked kernel. Seems like it could be done pretty easily with a subset of the Jemplode code. It's always nice when something can run against a stock player with the default consumer build installed.

Almost everything in Hijack belongs in the player, not the kernel.

But the player is closed source, and uses proprietary (though published) non-extensible protocols to communicate. So that leaves us with a very hackable kernel.

Speaking of hacks.. is there a way to use the remote or the serial port to feed a "FID" to the player??

-ml

Fair point, although I think adding code for the emplode protocol into the kernel would be more bloat that we need...

There was a command to play a FID from the serial port, but I believe it stopped working many builds ago.

Take a look at this post for an answer.

Not so much an answer...

I'm still wondering why it isn't working.

If you can FID or script-FID the player, then I can see the beginnings of speci,alist off-empeg control programs.

I think you take the empeg not as a computer, but at face value -- hardware that plays music... then indeed, you can argue that some of this stuff "belongs" in the kernel. (yeah, the argument is weak because there are alternatives for functionality placement ). In any case, given that "playing a song" is associated with the hardware, then you could wrap that with some HTTP compatible control mechanism and create firewall friendly, network friendly, web based software that leverages the box pretty easily.

Calvin

The crashing (after a while) is now fixed in v128.

It took, like, forever to find the magic flag that wait4() wanted for it to "wait" on kernel threads..

-ml

Im using IE 5 so something's a miss somewhere
Still a problem with Hijack V128

Its working really well now in the web browser with meta refresh set to 0.1
The only problem being that the refresh flashes the .png file, it reminds me of some of the old AMiga demos
Is there any way to have a real time display update without the flashing? The best I could think of is some sort of quicktime stream, but then I hate QT so...

That Javascript method above dosen't have a flicker (Are you removing the spaces I had to add around all the tags?), and a Java applet would also be able to do it with no flicker.

Let me dig up a premade java applet for web cams here real quick...Here we go.

Ok I did this at my G/F house (see attached) in notepad and paint for a while till i got home since she has nothing good for editing on her computer. This is really simple to make but I know there are some out there that don't have much design experience so I decided to write this. It need hijack install but it can be run from whereever you download it or in your / dir on your empeg as long as your empeg ip is 192.168.0.2 otherwise you'll need to change that. I had a problem with linking the empeg fascia around the display screen with the javascript that was posted. It would leave a white line on the bottom of the display ; / If anyone can get this to work please post. I set the display to update every 3 seconds you can change this very easily. If you guys want me to work on this more I'll be happy to.. this is just a rough design to see how it all looked. I was trying to make something in flash so a blue/green/red transparency could be put over the empeg_screen.png and make it look like your player. The problem is getting the empeg_screen.png into the flash and refreshing it. Let me know what you thing.

-Greg

ohhh!!!! you sod!
Guess what I just finnished doing...

Right thats it, Im off to bed...

IIRC flash lets you do transparency, so could you not just use the .png file as a backgrouns image and have the flash movie over the top, with an option to select the colour of your face plate?

Hehe.. post yours.. im interested in seeing you idea. ; )
-Greg

well, I just finnshed the code for the image map (I cheated, used FIreworks) and it was a dodgy attempt at using my girlfriends new digicam Its embarassing in comparison, but Ive attached the code anyways for a laugh.

Here is a ScreenShot of the source I posted above. Just to know what your downloading.

Oops, found the problem. I grabbed some old rorational image code, and stripped it down. I though I had saved and verified it, but I just went back to my HTML editor and realised I missed the save button

Attached is the updated screen.htm with Javascript Based rotation. I'll work on using that Java webcam one above here in a bit.

Me too !!!

I was just putting the finishing touches to my player graphics when it was posted...

You guys are insane!!!

Okay, a couple of notes for you script/java/flash writers:

The latest (v128) hijack now supports "GET" with parameters and any (or no) pathname.. this may make button pressing easier for you.

Eg. instead of: "GET /proc/empeg_notify?button=20df12"
you can now do: "GET /?button=20df12"
or even: "GET /proc/empeg_screen?button=20df12"

And I'm looking a a table-based CRC32 to see if it's any faster than the on-the-fly CRC32 currently used for the .png encoding -- see if the load on the empeg can be further reduced with it.

And if anyone wants a non-PNG version of the display (for flash importing or whatever), let me know.. not sure if it will speed anything up, though, since even my PNG version does NOT actually compress the image.

Cheers

-ml

Hehe. if anyone else was working on one post them I'd like to see your guys idea. If enough people are going to use this i'd like to get it up on a website for people to download from. I'd stick it on my server but anymore traffic and im gunna have to get a loan hehe. Let me know if you guys have any idea's to make it better.

-Greg

That Java applet dosen't work with PNG images, so no go without modifications.

Has anyone looked at the Java file from Displayserver? It had support in it for color. In theory, a few modifications (possibly with a raw feed available in /proc), it should work pretty well.

The odd thing is that Sun says 1.30 and higher supports PNG images. Maybe it has to be compiled and run under that version. (I'm running 1.31 here). I don't have all the tools here to recompile it and try, and I'm heading home for my weekend once this call is over.

You can improve your .html scripts if you use "relative" paths instead of hardcoded ones. Eg. instead of "http://192.168.0.2/proc/empeg_notify?button=20df07.S just use "/proc/empeg_notify?button=20df07.S".

Note that the ".S" is totally ignored, so it should get removed.

And with v128 hijack, this all becomes: "/?button=20df07"

Cheers

Don't think flash is possible, i've been looking around. I've attached the latest files to this one. It has Drakino's refresh javascript and I added controlls on the empeg fascia. For volume the top have increases volume and vice versa.

-Greg

Also, I'd like to see a larger image size. If you add WIDTH=256 HEIGHT=64 to the IMG tag for /proc/empeg_screen.png, then it becomes readable. Could somebody have a go at that, with larger facia to match?

This is just soooo CL!!

Noproblem. I'll work on it when I get home. No image editing tools here for the fascia. I just set it small since the empeg_screen.png is really nice at the size it is now. I tried expanding the .tiff when it was set to that and it didn't look as nice. Maybe png will look better. I also just set in the 192.*.*.* so it could be ran right away without having to upload it so you can modify it a bit. I'll post the next one with relative paths. Anyone know of a way to make a link not actually open a page? I had to add that other frame in the upper right corner so that everything would work, there has to be a better way.

-Greg