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

DisplayServer does not do any "streaming" in the way you mean it. If simply serves the MP3 (or WAV) files to the client over HTTP. WinAmp and other clients with quite happily play MP3 and WAV files over a network in this manner.

When Mark's kftpd is complete it should be able to provide the same "streaming" that DisplayServer does. What you do need though is something to present the MP3s and WAVs in an intelligable way so that the user can select them.

This extra bit of code would use the data in the FIDs or the database to serve up the playlists to the user, either as M3U files or as web links or symlinks. This could either be dynamic, or just a process that you ran every once in a while.

If would be easier to do this if kftpd also gained the ability to be an HTTP server, looking at Mark's code for kftpd it should be very easy for someone to add a simple HTTP server. It would be even better if it could run simple CGI apps (to do the dynamic work of creating M3U files or web links on the fly), this would involve forking userland apps and attaching them to the incoming HTTP port which would be a little more interesting.

I'm gonna get to it ASAP, but it looks like I'm not gonna start today. I finally got my iPod delivered today and I'm playing with that, and I have to dub all the old episodes of Buffy off of my TiVo onto tape before the new episode comes on tonight so that I've got enough space. Maybe late tonight.

In another point, it occurred to me late last night as I was trying to get to sleep that the new scrolling title features in the player, while quite nice, are going to play minor havoc with broadcasting the screen. Anyone know if there's some way I can synchronize screen grabs with the scrolling?

So it implements a small HTTP server, generates M3U files on the fly and serves the files directly when requested? So that means that it might not be streaming the same data the player is playing? Can it send separate data to separate clients? How do I make a request? If it's by the display control, that seems awkward. I realize that I could probably find this information elsewhere, but I'm lazy, so tell me.

It has nothing to do with the applet or what's playing on the player (or the player software for that matter). It's a completely different thing (though both are included with DS).

Yes, it's like any other http server. Yes, mutiple clients can each send different requests, and be psuedo-streaming whatever songs they want independent of each other. It's a glorified file server.

In reply to:

---

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

---

I was hoping you were going to say this .

Im probobly just being ignorant, but where is it that I can change it from port 91 to a different port? I'd rather have it at 21 ; )

-Greg

Mark said that it won't be able to do that until v 111
and it will be in the config.ini like everything else.

See the previous post in this thread for the details and wait for v111

Told you it was ignorance ; ) hehe.. for some reason my ftp clients and browser dont always like it when i choose diffent ports for some reason, so i was just woundering if there were anyway... but yeah, i'll just wait for v111 ; )

-Greg

The source for the older version of DisplayServer is at http://empeg.dyndns.org/empeg The Java applet source was also there. The site seems to be down at the moment.

No source for 2.x though.

- Trevor

Okay v111 will be out by the time this gets posted.

New in v111:
-- bugfixes in kftpd
-- kftpd is now way more efficient for directory listings
-- kftpd now defaults to the standard ftp ports (21/20), so no more awkward port 91 stuff.
-- new config.ini options for changing kftpd port numbers:
kftpd_control_port=21 ; default shown
kftpd_data_port=20 ; default shown

New in v110:
-- PopUp message at boot when flash settings are lost by player
-- other misc changes and clean-ups

Beat it, bash it, and let me know if you can break it.

-ml

Hmmm.. ftp is working great. I don't need/want to change the port or anything but im just curious where the settings are. I saw you had mentions they were in config.ini but when I looked at the config.ini under Emplode they weren't in there. (and yes I did install v111 ; D )

-Greg

You've gotta add the options. Hijack doesn't put them there. The default is 21 if you don't do anything.

I appreciate that you are working on this as of a daily basis, and Ive only played with it a little so far, but Im sure there are a few people like me who just aint got the foggyist about many of the features or config options.
Is there going to be a man for it?
Just the mention of the config.ini file for example, are all the possible settings in there by default?

Cheers

Dave

I tried displayerserver 1.1 with hijack 112 and the buttons don't work in the applet.

For your info my features of displayserver and kernal that goes with it were.

1 ability to run a pioneer remote with empeg (well covered by hijack)
2 ability to stream MP3s over a network to winamp
3 ability to control player over ethernet with a small applet where you could click on the buttons and control the player.

Frank said that he was hoping to have another applet which had a remote on it and that would be clickable to control the player.

>I tried displayerserver 1.1 with hijack 112
>and the buttons don't work in the applet.

Yes, that will not work: displayserver 1.1 sends the OLD IR codes, which are no longer recognized by the player software in beta7. Use the "Show Button Codes" display in hijack to see what DS is sending, and then either setup some [ir_translate] for them, or send me the codes and I'll translate them back inside hijack.

Cheers

There is no manual for Hijack (yet), but I think I have a volunteer working on one..

The config.ini options are defined in "hijack_option_table[]", near the top of linux/arch/arm/special/hijack.c --> you can see them if you look at the "*.patch" file for the current version of Hijack (from my website).

Cheers

Note that Hijack v112 can now stream .mp3 data over HTTP.. to try it, go to /drive0/fids/ on the Empeg (using HTTP), and click on a tune (the REALLY BIG files with hex names).

-ml

If you grab the screen from within "display_blat()" inside the kernel, then you don't have to worry about "scrolling text" -- it will all be nice and stable at the time of grabbing.

-ml

>>...have my kftpd also provide bare bones khttpd service..
>I was hoping you were going to say this..

Done.

I tried already...doesn't work for me. I don't know how it's supposed it work..I don't see how it can work this way, but if it's working for you, you'll have to let me know exactly how. Perhaps it depends on browser configuration...my browser just doesn't know what to do with the files. I get an open/save dialog box. If I try to save the file, it only saves the first 48.2kb of the file. If I try to open the file, my machine just doesn't know what to do with it.

Here's what my mp3 server app looks like, which was inspired by Display Server's behavior..so you get an idea of what I was talking about.

If it's just a straight listing of files it's not going to stream mp3s. If you are somehow generating custom headers, or somehow attempting to creat m3u playlists, then it might work...but I'm just not seeing it.

Woops...forgot the link.

http://mp3.everonn.net/mp3

(runs on my webserver, btw...not on the Empeg)

It does not even attempt to generate m3u headers. It just sends the files. If your browser is configured to play them (like mine is), then they play.

Anything fancier than this will NOT be in Hijack.. somebody will need to do userland for playlists, m3u, etc..

I am still undecided as to whether to keep khttpd in the kernel or not.. it takes up space, isn't perfect, and kftpd is a better solution for most problems.

Note: neither kttpd nor kftpd are smart about "slashes in filenames".

-ml

I agree...I don't know what we can do with khttpd that we can't use kftpd for.

I'm curious to know how your browser is set up that way...mine wouldn't even know the files without extensions are audio, I don't know how they'd play.

My personal vote is "yay" to kftpd and "nay" to khttpd. There are a variety of simple HTTPD projects abound which could be ported to the Empeg. Plus displayserver does everything I need. It's a little heavy on the memory but I'd rather have that memory in a user application I can shutdown rather than in the kernel.

Just out of curiosity, how much memory is khttpd adding? I haven't had a chance to try it out.

The next thing I'd want to see is file upload to the Empeg from kftpd. But my guess is that's on your list anyway.

OK, now we've got a HTTP server all we need is some bright person to add the facility to serve up some nice web pages like DisplayServer does - but more reliably. I wonder what it is that has made DS unreliable in this respect since the upgrade of the player software/kernel. Do other people have timeout problems with DS and 2.0b3 or 2.0b7?

I am still undecided as to whether to keep khttpd in the kernel or not.. it takes up space, isn't perfect, and kftpd is a better solution for most problems.

Here's a wild idea. Dunno if this will work.

I've noticed that if you are using a web browser, and you browse to to a set of HTML files stored on a FTP server, that it will tend to work more or less the same as if you were getting it from a web server. As long as they're plain HTML files without any server-side processing needed, it's almost transparent.

What if you messed around in KFTPD and created some kind of a "Fake" folder that appeared in the root directory which pointed to the necessary pages (which your code would assemble on the fly)?

I don't know if this would be more work than simply using KHTTPD or not, but surely it's got to have a smaller memory footprint if you do it that way?

Naw, the existing khttpd code already does something along those lines, except better. And now they pretty much run exactly the same code, except that kftpd needs a bigger command parser.

I suppose khttpd may be better than kftpd, in that it can handle multiple simulataneous (well, queued..) connections, and my kftpd cannot. But I need kftpd for use with "mirrordir" for backups..

Anyway.. BIG bugfix.. both kftpd and khttpd in v112 seem to chop off the end of some directory listings, so I'm putting out v113 shortly with that fixed.

Cheers

-ml

Yep. Displayserver would freeze up often. I had the serial line in at the time and it appears to cause the empeg to run out of memory reboot and that explains the long pauses because the empeg is rebooting. Displayserver wasn't very stable.

Calvin

>Just out of curiosity, how much memory is khttpd adding?

Not much at the moment, but if it stays in there I can see people wanting a million things added to it.. and my poor little Mk2 (12MB) will soon croak.

>The next thing I'd want to see is file upload
>to the Empeg from kftpd.

Me too!

-ml

Perhaps it's time to split the code branches. An khttpd mlord kernel and a kftpd mlord kernal.

Calvin

tried to see what codes DS was sending and no luck i am afraid

That's not what I meant. I mean that if I poll at random (or regular) intervals, the chances are fairly high that it'll always be grabbing the middle of a song title, if it's scrolling. I can't think of any way right now to assure that it will send out a screen grab where the title is at the beginning of its scroll.

HTTP servers send Content-Type headers. Hopefully, Hijack's HTTP server will send the appropriate Content-Type (audio/mp3?) for mp3 files. I can't think of a way for ftp servers to do this. Which may be a reason to keep HTTP there. But it may also be a reason to move it into userland.

Nope. If you grab the screen buffer from within the kernel, from the point where display_blat() is called, it will never have mangled text.

Either you still don't understand me, or the kernel is doing an assload more than I think it is. If a long songname is being displayed on the empeg, let's say "The Girl Who Lives on Heaven Hill", the screen will sometimes be displaying "The Girl Who Lives on Heaven H", and sometimes it will be displaying "e Girl Who Lives on Heaven Hill". If I select the wrong times to update the VNC client, then I run the risk of never sending the beginning of the title, or other pertinent sections. I'll figure out the best way to deal with this, I'm sure, but I doubt the kernel can take care of it for me automatically. Or am I wrong?

Frank didn't put up source for 2.0. As far as I remember, it was only ever a beta version before he disappeared off the face of the planet. Where are you when we need you, Frank? We miss you, please come back..

You are right.

But I don't see any reason for concern, so long as your refresh rate is more than once a second it will be fine.

I thought you were more concerned with sampling during a partial font rewrite, which would produce garbage if it were possible to do.

-ml