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