These files provide a web interface to control your empeg via hijack's khttp server.

Requirements are hijack v214+, IE6 or IE5.5 + XML Parser 3.0

To install, simply ftp the contents of this zip to your empeg root directory. Then use your web browser and point it to your empeg’s ip address or hostname.

New features in v1.0
Flyout rio remote control
Selectable display color, setting is saved with a cookie
User links on home page

You can download v1.0 here.

Here's a screenshot:


Tom

Nice work keep it up.

it works great thanks
the remote really looks good too

Nice. Very nice!

Thanks!

Be-a-u-ti-ful!

/Michael

Thanks for all the great comments!

Tom

WOWOWO, very cool!

Thanks

ya i totally dig it i would do something similar but why you have done it to the starnds i would have used.. very clean.. nice work.. it will be permient on my player as hijack is now..

I finally downloaded MS XML parser for my ancient IE5.5/Win98 setup, and, wow, this is really great, Tom!

Of course, I have a problem: I tried one of earliest streaming Hijacks, and it streamed OK. Now (with v225 and your xsl - I haven't tried anything in between) clicking on stream icon results in some traffic, but nothing else happens. I think that .m3u files are correctly generated and associated with WinAmp, since if I right-click on the stream icon, select 'Save target as...', save the resulting playlist somewhere, and finally double-click on it, WinAmp gets fired with the list correctly (and plays as expected). So, it must be something with IE setup. Any ideas?

Also, display color change does not seem to work, but I can really live with that ;-)

Thanks!

I haven't tested with IE5.5 so I can't say everything works for sure.

What happens when you stream with just the regular hijack html? Goto http://empeg/?fid=101&ext=.htm and try that.
Also if you can, post your http headers, that will help determine whats going wrong.

Does the display color not change for anyone else? Are you stuck with blue or is it grayscale?

Tom

Thanks for mentioning headers. I checked using telnet, and my .m3u files were registered as having MIME content type of 'audio/mpegurl', while empeg sends 'audio/x-mpegurl'. It works now.

Interesting, I found out that even with 'wrong' content type registered with Explorer the playlist would be downloaded (one could see downloading window flash briefly) and WinAmp called if I clicked on the same 'Stream' link twice in succession. I checked with telnet and I get exactly the same data both times. Some Explorer peculiarity.... Never mind, with exact MIME type everything is OK.

As for color, the display content is white, but I think that the rest of the lens (the dark part) is very dark blue, not black or grey. Does not matter, really.

Thanks!

I'm using IE5.5. Works great. This is just SO COOL!

I installed MSXML Parser and it the only I have to say is : GREAT !!!!

Well, you got farther than I did. I feel like a dolt that I can't seem to get a simple thing like XML working (simple in that it's s'posed to be click-install-done).

I'm running IE6 on Win98se and I downloaded MS XML4.0. The install went fine, but IE still displays the page the broken way (like Mozilla does and like IE did before XML). e.g. the window title is exactly the unparsed string: <xsl:value-of select="@host"/> playlists: <xsl:value-of select="@title"/>

So I thought I'd uninstall MS XML 4.0 and give 3.0 SP2 a try. Same thing... no XML processing.

Is there some obvious step I'm missing?

I have no idea, sorry. I use IE5.5 and just blindly followed Tony's link to MS XML parser v3. It worked, and streaming problem also turned out to be simple (slightly wrong MIME content type in Explorer file type association).

I don't know what to say, sorry. If you have IE6 you shouldn't be required to upgrade MSXML.

Just for kicks I installed MSXML 4.0 on my IE6 WinXP, and everything still works ok.

Tom

Have you figured out why it doesn't work with Mozilla yet?

They have an FAQ here why "It works in IE, but not in Mozilla".

It looks like IE takes the xsl transformation and then parses it again to generate the html output. Mozilla simply outputs the result of the transformation.

If someone who knows more about XML/XSLT would like to point out what I'm doing wrong, I will see if I can implement some changes.

If you take a look at the index.html page in Mozilla, it at least looks like it is supposed to. So the problem is with the XML/XSLT, which is something I knew nothing about a couple weeks ago, so I need some help here.

Tom

I knew it had to be something stupid, just took me a bit to figure out what.

somehow I managed to get both index.html and default.xsl as copies of the same file (default.xsl). Looks much better now!

Mmm.. good reference for the mozilla FAQ on this. They say the Lizard is very particular about the mime types, so I'll tweak those in Hijack and see if that's enough to fix it.

-ml

Thanks for the update.

Is it really necessary to use "&amp;nbsp;" rather than just "&nbsp;" ??

That's one thing that requires recursion to resolve the way it's written right now.

-ml

Or even, for that matter, just change

<xsl:text disable-output-escaping="yes">&nbsp;</xsl:text>

to

 

inside the default.xsl file?

Cheers

Oh, never mind. Mozilla seems to only be happy when I totally remove the &nbsp stuff -- it's not really needed anyway.

Do other browsers need it in there?
Is &nbsp; even valid syntax for XHTML ?

Cheers

Next question.. what's with this "javascript:void(0)" stuff that's sprinkled all over? Mozilla doesn't seem to know what to do with that.

-ml

& alone in an XML document is illegal (which is what the stylesheet is), you have to specify &amp;

So, if you have &amp;nbsp; in the xsl, it will output &nbsp; to the html, which will of course put a non breaking space in the td. At least in IE, that's good for tables that have nothing else in the td, so it looks like an actual defined td.

Chris

The "javascript:void(0)" inside a link tells the browser to not change pages when the link is clicked. Usually because there are onmouse events which do stuff instead. There are other ways of doing this.

Tom

Without the &nbsp; empty cells wouldn't be rendered and it looks like a hole in the table, so they are needed.

Tom

I'm not sure if this has been discussed yet, but is there way to make the visual window update quicker. It seems to be set about about 1 frame every 5 seconds. One thing I really like about display server is how quick it updates.

Thanks,

Tom

Yep, just edit the value in the default.js file. I plan to make this configurable too, like the display color.

Tom

I guess you would get the same result with
<pre> </pre>

and no &amp;s

Marius (Escort Cab + Mark II)

Mozilla renders empty cells just fine, thanks.

I belive IE will also do so, so long as the header line across the top is filled in (which it is).

&amp;nbsp is not valid HTML, unless recursively parsed. The only browser I know of that recursively parses it it IE. Lets use coding here that is not manufacturer-specific, please.

If I cannot view the output from Hijack in Linux, I'll just eventually remove the feature.

Cheers

Which things need this? Perhaps it's more appropriate to get khttpd to return a 204 (no data) response for those links?

I'll add a "NODATA" parameter to Hijack v232, as in:

http://my.empeg/whatever?NODATA+anythingelse..

EDIT: original post said "NORESPONSE" .. now changed to "NODATA".

Yep, just edit the value in the default.js file. I plan to make this configurable too, like the display color.

When I did that (admittedly, several versions ago, not lately), I could increase the speed of the updates, but it was still not fast enough for my tastes. There seemed to be an upper limit to the refresh speed, about 1 per second.

I was hoping to get the speed up to about four per second so that remote menu operations felt more realistic.

Is this possible to do, or is it a limit due to the frequency that the PNG graphic on the player is updated? How does that work?

The graphic is updated on demand, quite quickly. I think the EmpVNC uses it for pretty-much real-time remote display. In fact, plugging the VNC java applet in place of the static graphics would be awesome..
just requires the VNC server to be installed.

How about an option to select VNC for the display & front panel controls?

Okay, Hijack v232 is now available, with the aformentioned NODATA flag implemented for khttpd. I've also removed the "play_count", "skipped_count", and "last_played" fields from the XML, since they are just an invalid byproduct of an emptool bug.

Cheers

Oh.. I just noticed my prior post about NODATA had an invalid example, so here goes again:

http://my.empeg/whatever?NODATA&anythingelse..

or a real life one:

http://my.empeg/?FID=101&EXT=.htm&NODATA

or this:

http://empeg/?NODATA

The last example probably being the most useful for the XSL template work.

Cheers

Here's what results in IE without the non-breaking spaces:



I also tried the <pre> </pre> thing without any luck. Mozilla displays the empty cells correctly, I guess the problem I was talking about before was specific to Netscape 4.x

I'll continue to experiment, I'm not giving up at all. I really appreciate the feedback and suggestions.

If I cannot view the output from Hijack in Linux, I'll just eventually remove the feature.

Why would you want to do that? There are plenty of people who have found this useful. I’m doing this in my spare time. I’m sure you can understand if Mozilla compatibility is not the highest priority in my life right now.

Tom

Well, perpetuating products from a (convicted criminal) monopolist isn't exactly a priority of mine right now, either.

But I'm not in a big rush to remove anything yet, as long as someday it will work for me. Hijack is something for use on my player, and things that don't work for me don't get left in there forever.

Keep up the good effort. I'm sure we'll conquer it someday.

Cheers

http://empeg/?NODATA
The last example probably being the most useful for the XSL template work.

Thanks, I have this working, and it will be in the next version.

Mozilla still doesn't seem to respond to the onmouseup/onmousedown however...

Tom

Ok, I managed to get around the &nbsp; issue by just using a 1x1 clear gif as a placeholder instead.

Tom

How about an option to select VNC for the display & front panel controls?

I'm still not sure what the best solution is for this. Obviously with an option, we could satisfy everyone, so I will probably take that route.

Tom

Devious, very devious.

Do you perchance use junkbuster? (a variant of it does something similar with banner ads)

Do you perchance use junkbuster?

No, I don't.

Tom

Just so I can stop feeling singled out. I'd like to point out that the other stylesheets don't work in Mozilla either

Tom

Yeah, but yours is the best!

-ml

Well, perpetuating products from a (convicted criminal) monopolist isn't exactly a priority of mine right now, either

That ironic, as I'm pretty sure that "feature" crept into IE to make it behave more like Netscape, which used to have real problems with empty table cells...

maybe you can program 2 style scripts one for ie and one for mozilla just to satify the world.. im getting board and thinking about style sheetin' myself

It would be lovely to have a little box on the home page with current track info (Source, Artist, Track name, etc) in case we don't have an info mode displayed on the screen. That would almost be like having Info:Track and Visual:Whatever up at the same time! Neet! ;-)

I'd do it myself but I haven't even started with X?L yet...

Yeah I think he is working on that now. How do you get that information off the player though?

Sean

/proc/empeg_notify

mark your so smart..

Nothing comes up in my web browser when I try that. Im just looking at a blank page. Am I missing something obvious here? Do I have to have notify enabled in config.ini?

edit: nevermind, i figured it out.

Thx,
Sean

Excellent work, CG99!

I know its a work-in-progress, but I'll have to resort to a simpler XSL implementation as I can't expect all my MSIE users to have to upgrade just to use it.

We worked up some complex web-forms using XSL at work that supported both Moz(4+)/IE(5+) -- if I rework your design to be less OS+browser+browser_version+XML_version specific would you mind?

Also, are you using an MS tool to cook your XSL, or are you creating/working it by hand?

See my new post for a list of things I need help with. I would not mind at all.

Tom

In reply to:

---

&amp;nbsp is not valid HTML, unless recursively parsed

---

Couple of things. How is that not valid HTML? It may not mean anything specific in HTML, but that doesn't make it invalid. (Note: Haven't checked that it's valid XHTML, still think it would be, but there's nothing that makes it invalid HTML).

I'm not sure what you mean recursively parsed. I mean, I understand the english, and the programming concept, but really, isn't this what the browser is doing when displaying stylesheet-applied xml? It reads in the xml, requests the stylesheet, produces an output from that source and stylesheet, and then, since it's HTML (or XHTML in the case of Mozilla), would parse and render that for display. Here, one source becomes another, which is then rendered for display, so in a way, it can be thought of as recursion, but it's two seperate parsers doing the work.

The &amp;nbsp; isn't HTML anyway it's XSLT, which, by extension is XML and that is also valid XML. An XSLT 1.0 compliant parser should output &nbsp; after parsing that. Of course, in HTML the &nbsp; is a named entity which will insert a non-breaking space.

It would be the same thing (but is a little shortcut) to <xsl:text disable-output-escaping="true">&nbsp;</xsl:text>.

Does Mozilla not support the appearance of &nbsp; in their html docs? I might have to go ahead and install that on a machine.

Chris

In reply to:

---

Ok, I managed to get around the &nbsp; issue by just using a 1x1 clear gif as a placeholder instead

---

The other thing you might try (I will if I get a chance) is &#xa0; This works for outputting a space with a working draft XSLT compliant parser. In fact, I think it was the only way to make that work in IE5 5/5 w/MSXML2, so it might be better for Mozilla. If that works, everyone saves requests for that little gif.

I know, not a big deal, but using blank gifs for layout and display is so, 1997.

Chris

Nice. Mozilla liked <xsl:text disable-output-escaping="yes">&#xa0;</xsl:text>

And since your more of a XML guru then me, look at my other thread (v1.1) and see what I need help with!

Tom

In reply to:

---

&amp;nbsp is not valid HTML, unless recursively parsed. The only browser I know of that recursively parses it it IE. Lets use coding here that is not manufacturer-specific, please.

If I cannot view the output from Hijack in Linux, I'll just eventually remove the feature.

---

Not to pick a fight, because I thought the last one was ridiculous... Also, I'm going to go ahead and install Mozilla on a machine to see what the problems are. Of course, this isn't even my stylesheet (or browser of choice) that I'm going to look at.

That all being said, who ever said we needed one stylesheet to work the same exact way on every browser on the planet and have every feature work exactly the same way? I thought the idea was to be able to allow people to view the output the way they wanted to. If that includes manufacturer specific goodies, good for them. At the same time, maybe someone wants a much simpler interface, that's fine too. Maybe someone wants no CSS or js at all, done. Maybe someone needs to put weird code in to make it look better on one platform as compared to another, that should be okay too. It's the XML that's iniversal, the stylesheet shouldn't have to be. Yes, it has to adhere to standards, but the output should be able to be specific to whatever the browser of choice is if the stylesheet author so chooses.

Not sure why you would ever contemplate removing the xml interface because someone made (or might make) a stylesheet that doesn't work right in Mozilla. There's nothing stopping anyone from writing a good or better stylesheet for Mozilla.

Gotta say too, if it's a threat, that's kind of lame. Not that you haven't shown you can take new versions away. On the other hand everything in Hijack that I use was done like 20 versions ago, and I've shown my appreciation for it in more than just words. Maybe others need to do the same.

Chris

Maybe others need to do the same.

Some other people already have, for example I happily bought Mark a tuner (why, oh why didn't I buy another one for myself at the same time !!!!).

No question you guys have been really nice (thanks!).

And I don't intend anything bad or nasty here. It's just that, all of this is sitting on top of incredibly valuable and useful free software. To which I contributed major portions, long before this BBS existed, as well as more recently. I can not and do not particularly want to control how it's used, but I would like to see others giving back to it.

So if an expensive (memory-wise) feature like XML generation is only ever going to be useable on software from a certain convicted criminal organization, then I'd rather not have it take up space in my player -- I'd rather use the extra memory for added music buffering instead, to better protect my hard drives. Sure I could write my own XSL, but then, others can write their own kernel code, too.

No big rush here, just some nudging in a particular direction.

Cheers

-ml

Tres excellent, guys!

Fair enough.

And I'm now trying to track some of this down. First step, why doesn't Mozilla make a request for the <script> reference from the stylesheet output.

It does[/u] make a request for the css and each gif file, so it's weird.

Chris