Wow!!! nested playlists. You managed to get around the recursion problem then?

Didn't want to start a new thread. Hope you see this easily enough.

FTP rename isn't working for me. And I haven't seen it discussed elsewhere. RNFR is reported as a bad command (I did make sure to rw first) using WS_FTP as well as SmartFTP (pretty interface, but operation still leaves a lot to be desired).

Bruno

Fantastic. Out of curiosity... How are you discriminating between downloading and streaming? Are you using User-Agent or some other method?

>FTP rename isn't working

That's cuz it is not implemented.. this is a kernel FTP daemon, and it needs to be very space-efficient as a result, so not all commands exist.

But "rename" (RNFR+RNTO) will be implemented in Hijack v170.

Err.. v170, not v169 as originally posted.

Cheers

>Fantastic. Out of curiosity... How are you discriminating
>between downloading and streaming?

I could tell you, but then I'd have to kill you.

Use the Source, Luke..

-ml

>Wow!!! nested playlists.
>You managed to get around the recursion problem then?

Yes, with a loop and a 16-entry file-descriptor stack. Very nice and tidy, after all the screaming and whimpering stopped...

Cheers

-ml

>Has anyone put together a good hijack help file? Hmm..

Not yet. I'm kinda hoping somebody might step forward and write a quick webpage for me, summarizing all current features of Hijack and how to access them. There was a volunteer earlier, but he got really distracted by silly things like family and job..

-ml

Your ARTIST and SOURCE name passing seem to be limited to 31 characters right now. So I only get "Carter the Unstoppable Sex Mach" instead of "...Machine." This also won't be able to fit "My Life With The Thrill Kill Kult"

It seems to be able to deal with the TITLE length of all my tracks (didn't count the characters on any of these, but I have plenty that go beyond 31).

Just a heads up.

Bruno

I've bumped the "artist" buffer size up to 48 chars in v170.

Cheers

Have you done any speed tests on http and ftp transfers?

Using HTTP, I'm getting about 320KB/s when downloading a track while another is playing on the player. And a rate starting at about 10KB/s and decreasing to under 4KB/s while sending my entire player contents through your m3u method.

While the player is paused, these increase to downloads of about 660KB/s and playlist compiling/download starting at 12KB/s and ending at about 6KB/s (475KB list gets generated using the "Play All" link on the root view). That's just over 5900 tracks - my music is all within album lists within artist lists - split into two top level lists + a bunch of compilations that are equally recursive.

If this sounds correct, what's the likelihood it can be improved at some point?

With all this added functionality, I'm wondering how come no one is talking about making a nice backup program that could handle tracks and database. The communication is easier than ever with all the work already put into Hijack.

Bruno

edit: Damn, the first time I posted I noticed winamp was still streaming in the background. Then I was getting downloads at about 280KB/s.

48 chars gets all that I care about out of my 1902 different artists. I don't care about these three getting truncated, they aren't on my empeg anyway.

Celine Dion, Gloria Estefan, Shania Twain & Carole King
Whitney Houston, Chaka Kahn, Faith Hill, Brandy, LeAnn Rimes, & Mary J Blige
Methods Of Mayhem, Tommy Lee, Fred Durst, Lil' Kim, Crystal Method, George Clinton

took me a minute to figure out how to find out what the longest artist name in my collection are. If anyone's interested, I can post the sort perl bits I wrote and the command line process it all.

I just spent a couple of hours fiddling with the .m3u generation code, with no luck. It just has too much random disk access to do, which makes it rather slow.

For each playlist, it has to open/read/close the tagfile, and then open/loop-thru the corresponding fidlist file. For each tune, it has to open/read/close the corresponding tag file. This amounts to a lot of random access on the drive, and a ton of directory look-ups. The Linux ext2 filesystem in the kernel is pretty lousy (linear search) with directory lookups in LARGE directories.. like the /fids/ dir.

Not much to be done, unless we want to reverse-engineer the database file, instead of using the raw data in /fids/

If you (or anyone else) can figure out (from emptool sources) the format of the database file, then we can use that for a dramatic speedup.

As for backup programs, I use use mirrordir, an excellent Linux/unix FTP mirroring program.

Cheers

-ml

Hijack v171 is out.

v168: tons of enhancements (see earlier release notice)
v169: fixed empty playlist issue from v168
v170: added FTP "rename" capability; revamped the playlist browser
v171: added config.ini "spindown_seconds=30" option (default shown) for hard drives, since kftpd/khttpd can leave them spinning "forever" otherwise.

-ml

Tested with v171 (you release three versions while I sleep :-))

Works, as expected. Thanks!

Hi,

Can we have the /proc/empeg_screen.png and /dev/null added with these headers, pretty, pretty please:

Cache-control: no-cache
Pragma: no-cache
Expires: Tue, 01 Jan 1999 01:00:00 GMT

It would help me with some JavaScript stuff I'm working on, so we can have remote-control capabilities in a browser.

Hi

I know I'm probably just being dump, but I can't work out the password feaure for FTP & HTTP. Can someone explain how it works?
I've set a password in config.ini, but I'm not sure which username to use, I've tried anonymous but that does'nt seem to work.

Thanks
Phill

Huh?

Added with what headers?

By the way, if you send buttons exactly like this, then the server returns a "204 No Response" header:

     GET ?BUTTON=xxxxxxx;BUTTON=yyyyyyyy

or

     GET ?BUTTONRAW=xxxxxxxxx

If it would help, I could add a "NOOP" command as well, for silly browsers that always insert a leading slash, as in

     GET /?NOOP;BUTTON=xxxxxxxx

The NOOP would guarantee a "204 No Response", even with a pathname.

-ml

Oh.. those headers (my eyes are extra blurry this morning..).

Do you really need all three?

-ml

The khttpd does NOT support password use, so don't bother trying there. For kftpd, insert these lines into config.ini:

[hijack]

kftpd_password=MyP4SsW0rD

Connect up the serial port, and monitor the output while rebooting the player. You should see the above line get echoed out somewhere near the "end". If not, you screwed up.. fix it.

Once that part is working, just ftp to the player, use ANY userid (it is 100% ignored), and enter the password exactly as in config.ini.

-ml

Okay, I'm awake now.. I'll add those non-cacheable headers to everything from "/proc/" and "/dev/" (as it should be).

Hijack v172, shortly.

Thanks!

empegVNC is already browser-capable. Not to discourage you from developing what you want, but there's little point in reinventing the wheel, unless you want to.

It's nice to have a selection of wheels. I keep two sets for my car, why would the empeg be any different. Hehe.

Bruno

Hi,

Did build 172 break ?button=something? I get an 403 Access Not Permitted no matter what's in front of the ? ....

Yeah, it's broken -- forgot to add "khttpd_commands" to the options table, so it's picking up default value of '0' == not enabled.

Fixed in v174 shortly.

Mark, the disk integrity check disabling feature is definitely not working for me (previously with 166 and now with 172). Let me know what details you need to help get to the bottom of this.

Bruno

Login to your empeg on the serial port, and do this:

fsck -fay /

fsck -fay /drive0

fsck -fay /drive1

sync

and then reboot and double-check the hijack menu setting for the fsck. It should be fine after that. If not, let me know.

-ml

If you find yourself in the habit of rebooting from the Hijack menu "reboot machine" feature, then do keep in mind that this method of rebooting does NOT remount-ro beforehand.. the "SITE REBOOT" and http "?REBOOT" do remount-ro, but not the menu.

-ml

I never reboot from the hijack menu itself. And even when using the SITE reboot I had been in the habit of manually mounting ro beforehand.

I'll check out what you wrote above...

Bruno

Okay, Hijack v175 is released. Hopefully nothing will appear different, except that the playlist browsing has been revamped internally to be much more CPU efficient (faster, but still slow though, because of all of the random disk I/O it requires).

A side effect of this is that LONG tags are far less likely be to truncated. The only fixed size buffer is for places where the "artist" and "title" fields get merged (such as in .m3u playlists) into a single 128 byte buffer.

Anyway, please give it whirl and let me know if I broke anything.

Cheers

How long is the fsck on drive0 supposed to take (running 2 30GB drives)? It's been going over 15 minutes so far...

Bruno