So, what are the odds of getting these two great hacks to work together?

Last I saw, that was the next thing on Mark's plate.

Depends what you mean by work together displayserver (version)1.1 and hijack (version lost count) work fine together you just can't control the player through the applet

>Depends what you mean by work together displayserver (version)1.1 and hijack
>(version lost count) work fine together you just can't control the player through
>the applet

That is, in fact, the functionality I wanted! The coolest part of Displayserver is the remote control. However, the functionality provided by hijack is too good to give up, so.....

Okay, Hijack v109 is out, the only change being I installed Frank's IRSEND hack for remote control via DisplayServer.

Totally untested, cuz I cannot find source code for DisplayServer (only binaries, which don't interest me as much).

Cheers

-ml

Yeah I don't think Frank ever did release source... By the way has anyone seen or heard from Frank? His last post to the BBS was in November and he used to be a regular contributor... Odd...

Sorry for my ignorance at that regard, but what does this mean exactly? Is there a http server running on the empeg, yet? If so, an what port?

A big big thank you anyway!

Frank's DisplayServer required an IR hack to allow the Java applet to remotely control the Empeg. It basically faked the kernel into thinking certain remote codes had been sent. Mark just integrated that functionality into the kernel, but you *still need displayserver running* in order to have any kind of HTTP server functionality.

Having displayserver in the kernel would probably be a little too much... Way too much memory usage.

I don't think it will be that big..

Maybe later this winter I'll just trap the output from Franks program in my browser, and then add some kernel routines to mimic it..

Much later, and I'd rather someone else had a go at it first to figure it out. But I suppose it could be something as simple as some html with auto-refresh.. not as smooth as reusing Frank's Java might be.

Of course, I've never even seen displayserver running, let alone used it.

Cheers

-ml

Anyone considered implementing it as a VNC server, like the really tiny one used as an example on the VNC site? If not, I might take a look at getting it to work with Hijack.

I've thought a little about VNC, as we make rather extensive use of it around the (home) office here, as well as on the road around the world. Nice stuff.

But for the Empeg, we need something even simpler. The amount of data we're dealing with is small, but we need to keep CPU usage even smaller.

With packed-pixels format transmission, an entire loss-free image of the display goes out at 4 pixels to the byte, or basically 1KB -- less than a single ethernet frame, and very low CPU to generate it. It would be rather easy to write a UDP broadcaster that just dumps screen updates out onto the lan, at perhaps 5 frames/second refresh rate.

But apparently the big feature of DisplayServer (I've never even seen it once) is the client side app that draws the buttons and allows point-and-click for remote operation, as well as displaying the screen dumps from the unit. Somebody needs to (re)write that portion, or figure out Frank's protocol so we can continue using his Java client.

Getting the button-presses back into the Empeg is not difficult, either, just have a kthread listening on a UDP socket, and passing the codes directly into the IR handler (which has been taken over by Hijack nowadays).

Anybody wanna write a client, or reverse-engineer the protocol that Frank used?
The player side (kernel) is the easy part (for me).

Cheers

Okay, I invesstigated the VNC protocol a little more, and I don't really think that it would take up that much CPU. I haven't really thought it the whol way through, but it seems to me that, while VNC has a lot of features, those features wouldn't end up being used on the empeg, and could just be hard-coded. And as far as the control mechanism goes, VNC obviously supports mouse-click input from the client. It would be simple to just include the buttons as additional information in the server, and interpret the input from there. I understand your problem with VNC, as it is a little heavyweight, but using a standard that already exists is usually a good idea, and I think that it is in this case, especially since there are clients for pretty much every platform you could shake a stick at. Even Palm. There are other problems, as well, though, such as that VNC doesn't currently support depths of less than 8 bits, to name just one.

I'll take a look at getting something happening, probably tomorrow. If you could let me know what you think the best way to get the screen data is, I'd appreciate it. If VNC turns out to be too heavyweight, which it may well be, I'll take a look at something else. Maybe reverse engineer DisplayServer, or maybe not.

Mmm.. I still think VNC is not a good choice for doing this in kernel space on the Player. Yes, it's got viewers for most platforms, but how many systems have actually installed those viewers? Many systems use the VNC Java viewer, which most VNC servers automatically provide on request from the client. I suppose we could also do that, but it just adds more bloat in support of an inappropriate protocol.

If we use a custom Java app and messaging, we still have incredibly wide cross-platform support, and we still also have to send down the applet, but it will be a much smaller applet than the generic VNC case.

Sending VNC 8bpp quadruples the amount of data that must be transferred, instead of 1KB we then must send 8KB per screen refresh. This effectively rules out any attempt now or in the future to obtain any semblence to a real-time display.

But.. we could then apply the VNC compression to this, for which VNC is famous. Yes, but then the code just gets way more complex, and chews up way too much CPU. This again limits our refresh rate, and could possibly interfere with the fundamental application of smooth music playback.

Speaking of which, doesn't DisplayServer also do music streaming? I don't think VNC does.

VNC is just not as appropriate in this case as the alternatives.

But that's okay, the best proof is code, against which all Linux kernel mods are tested. So go for it anyway, and beat the odds!

To intercept the display, the best place, guaranteed to give the current data, is the "source_buffer" parameter of "display_blat()" in arch/arm/special/empeg_display.c. This buffer is organised as a sequence of thirty-two 64-byte rows. Each byte represents a pair of horizontally adjacent pixels (flipped order), using only the lower 2 bits of each nibble. Thus, "source_buffer" is 4KB, of which we only use half the bits.

I have never actually measured the rate at which display_blat() is invoked, but it is VERY frequent, so you would not want to capture a copy of the buffer on EVERY invocation. For better synchronisation with remote playback, it might be better to grab buffers earlier, from the internal display queues.. but you'd miss the Hijack data that way (it is never queued).

Taking a look at the system LoadAvg values from the "Hijack Vitals" screen can be very instructive, especially when music is playing and visuals are active.. the system is often around or above 100% load, contrary to early claims of light loading from the makers.

Have fun!

-ml

>Is there a http server running on the empeg, yet?
> If so, an what port?

No. Displayserver can be run, and it uses http to transfer stuff (apparently).

And the current Hijack kernels have an FTP server built-in, retrieval mode only.

-ml

And the current Hijack kernels have an FTP server built-in, retrieval mode only

Hmmm..I've been out of the loop, and I've only been able to skim through the numerous threads relating to Hijack lately, so I guess I missed this.

I'm running 109 now..what do I have to do to access the FTP server on my Empeg? I understand that I'll be limited to retrieval, but I can't seem to connect. Does it (ftpd) run all of the time? Does it use a non-standard port?

The built-in kftpd is running on port 91, rather than the standard ftp port 21 -- this is to avoid conflict with any user-installed ftpd that might be on the box.

So, from a commandline, you can connect with: ftp ipaddr 91 and from a webrowser it would be ftp://ipaddr:91/

Still a few bugs hiding in there, but it won't break anything -- might require a reboot if it locks up. I'm working on that.

Cheers

Speaking of which, doesn't DisplayServer also do music streaming? I don't think VNC does.

The only music streaming that DisplayServer does is streaming MP3s via HTTP, the Java app doesn't play music. This functionality should be met quite happily by your kftpd.

Yes but for some of us, this is the best feature. I allow my
co-workers to stream away while we're at work. They
rather like it. I don't audio attach the player while out of
the car at work. At home I do.

I dislike that the m3u's seem broken, but I've been too darn
busy to really start hacking away at it yet. Perhaps next
month when I integrate mikmod.

I thought Frank's site used to have his code posted?

Ed

Where is Frank? Is he okay?

In reply to:

---

... Speaking of which, doesn't DisplayServer also do music streaming?...

---

Yeah, that's the only bit I'm interested in. OK the Java applet is cute but I don't use it. If you (or someone else) could get this part working it would make the guys at work very happy indeed. They'd be able to listen to my tunes across the network again. Currently this part of DS doesn't work properly with player software versions higher than 1.03. Well not on my player anyway. I'd like to do it myself but my programming skills & Linux knowledge aren't up to it.

Frank posted sources to some of his things, I don't believe Displayserver was one of them. In fact, I think he was considering making it shareware or something to that effect.

I'm still wondering where Frank's been lately.

The built-in kftpd is running on port 91, rather than the standard ftp port 21 -- this is to avoid conflict with any user-installed ftpd that might be on the box.

Any chance on making that port settable in config.ini?

I understand all of your concerns with using VNC, and they're all valid. But I'm pigheaded and I'm going to try it that way first, anyway. If it doesn't work, it should be easy to replace all the VNC with a custom protocol (whether it be mine or DisplayServer's). I've installed that tiny VNC server on my empeg, and it runs fine. In fact, it runs pretty fast, even with the player going at the same time. Then again, I didn't have the outputs of the player hooked up to make sure it was doing fine.

I've never seen DisplayServer, either, so I'm not sure of all its features. As someone said, it does also stream music, but that appears to have been separate from the remote screen viewer and control. I'm not sure how well the streamer would work these days, since we can no longer guarantee that the source will be in MP3 format. (I'm making assumptions about how DS's streaming worked.) I think the only way to make it work flawlessly these days would be for it to transcode WAVs and WMAs, since I doubt that most (any?) streaming clients can handle switching formats, since many (most?) can't handle switching MP3 bitrates. Anyway, that's all beside the point, since I don't intend to work on that part. At least not right now.

Incidently, I liked this functionality so much (streaming of tunes from the Empeg) that I wrote an app to do the same thing from the BACKUP of all the fids on the player, so I don't have to hook up my player anymore and I can stream songs or playlists from my workstation/webserver. If anybody is interested, here are the details.

I have all the fids backed up on my webserver. I used CSV exported file, which I then imported into MySQL to use as an index of all the playlists, tune info, etc.

I wrote a few PHP templates that allow you to browse the playlist structures as they exist on the player (or at least, when the CSV data was mined), and then play (stream) or download the tune.

Though the FIDS file names are their hex values, I'm generating file names on the fly when you select download to something more friendly ([Artist] - [Album] - [tracknr] - [Title].mp3).

When you select to play a playlist, a m3u file is generated on the fly along with extended info (so Winamp will display all song titles in the playlist).

I did wrote the app b/c I liked Frank's DS functionality so much, I wanted to be able to use it all of the time, without having to hook up my player. It's got some drawbacks, b/c it kinda piggy backs off the player's database and structure, and when I change this on my player it makes things a pain to keep synched with my app. Other than that, it's quite a nifty little mp3 server app.

If anybody wants to see it let me know.

I'm not sure how well the streamer would work these days, since we can no longer guarantee that the source will be in MP3 format

Very good point...I hadn't thought of that. The streaming (or psuedo-streaming, if you will) was simply DS sending the browser and m3u file (which most players will take from there, and stream the files from the unit). This wouldn't work with other media types (at least, I don't think).

I'll have to write something into my app to deal with that, I guess. Then again, I'm the only one using it (so far?) and I only have mp3 files on my player anyway. But now that I'm curious..I'll have to see what happens when it encounters wav files.

>I understand all of your concerns with using VNC,
>and they're all valid.
>But I'm pigheaded and I'm going to try it that way first, anyway.

Good! I was hoping you'd say that!

If you can get it working, and smaller than the kftp code I have (just as a rough measure), then we oughta be able to shoehorn it into the kernel without really bad side-effects.

For that matter, there are a couple of "socket" routines in kftpd.c that could be shared with it, to keep the size down. Eg. sock_rw()

Cheers!

Can you get that mp3 streamer app to work over FTP, instead of HTTP? If so, then maybe we can integrate it with Hijack's kftpd server..

No I'm referring to an app that was written not to run on the Empeg, but run on a webserver with PHP and MySQL (that's the point...I didn't want to run it off the Empeg. DisplayServer already does that anyway). I could probably rewrite part of it to work without MySQL (to just use the FIDS), but it's still a PHP app, and will only work under an http server.

Now, if we could get an HTTP server and PHP running on the Empeg, we'd be set (though it'd never happen in flash)

I'm not much of a programmer, and I'm limited to my web programming knowledge.

While.. now that you mention it.. I suppose it wouldn't be too much more code to have my kftpd also provide bare bones khttpd service..

Mmm...

For v111 I'll add a semaphore to delay initialization until the config.ini gets read -- that's why it wasn't there already.

The new parameters will be:

[hijack]
kftpd_control_port=91; // default shown; change to 21 for regular ftp
kftpd_data_port=90; // default shown; change to 20 for regular ftp

Cheers