Hijack v161: lots of stuff

Okay, a major release of Hijack tonight, v161.

New in this release:

• Added XMKD, XRMD commands to kftpd, for Win2K clients
• Added REST command to kftpd, allowing it to resume interrupted transfers in either direction
• Added "Range" support to khttpd, allowing it to do partial downloads of static files, e.g. for "seeking" in WinAmp
• Added workaround for bug in player software, whereby if Tuner is set to AM, and player is removed for use elsewhere, the player will eventually recover instead of running schitzoid forever..
• Converted "NextSrc" to use Rio codes, instead of Kenwood codes, so that it will still work if the Kenwood codes are disabled in config.ini
• Added "[hijack] ir_debug=1" for config.ini, to help debug IR/button issues
• Fixed "knob doesn't work after reboot" issue
• Fixed HTTP "%xx" translation problems
• Added "SERIAL" command, which can be used to inject serial port commands into the player, such as feeding it a playlist FID:

  
      echo "SERIAL #100" >/proc/empeg_notify

  or

  
      http://your.empeg./proc/empeg_notify?SERIAL%20%23100

• Other small bugfixes
  

The playlist and tune streaming still seems to work, but has not been fixed for two-drive players yet. Someday soon..

Enjoy!

Added "Range" support to khttpd, allowing it to do partial downloads of static files, e.g. for "seeking" in WinAmp

This is something I don't know how to do with my app. Do you have any ideas on how to get this to work on my webserver, or could you point me to something that might give me info I need to implement this? I'm not sure what the right question is to ask here, because I'm not quite sure how and where this is fixed.

http://your.empeg./proc/empeg_notify?SERIAL%20%23100

I tried your example here (and a couple variations of it) but it didn't work for me. Just shows me info on what's currently playing on the unit. I might not be using it correctly or understand what it's supposed to do.

This is something I don't know how to do with my app. Do you have any ideas on how to get this to work on my webserver, or could you point me to something that might give me info I need to implement this? I'm not sure what the right question is to ask here, because I'm not quite sure how and where this is fixed.

When a webclient (in this case Winamp) requests a file from a webserver (in this case serving mp3's) it can tell it a range of bytes of the file to transfer.. This lets winamp seek to a specific place in the file (IE, the user dragging the seek bar) and start from there. Without this, the server would just send the whole file again. It can also be used to resume file transfers if something goes wrong.

I tried your example here (and a couple variations of it) but it didn't work for me. Just shows me info on what's currently playing on the unit. I might not be using it correctly or understand what it's supposed to do.

I'm not getting anything.. I can connect to the serial port and send commands, but only once did I even see serial commands initiated through the URL show up.. Even then, # commands don't seem to work for me.

Edit: now that I posted, the serial commands are working again.. but # command is not.. even through the serial port nothing happens..

This lets winamp seek to a specific place in the file (IE, the user dragging the seek bar) and start from there. Without this, the server would just send the whole file again

Well, my app is currently restarting the song when you try to seek, and I'd like to fix that, but I don't know how. That's really what I was asking. In Winamp, I seek to a point in the middle of a song served by Hijack, works great. I try to do this with a song coming from my server, it doesn't work so great. I don't know where this is fixed.

Well, my app is currently restarting the song when you try to seek, and I'd like to fix that, but I don't know how. That's really what I was asking. In Winamp, I seek to a point in the middle of a song served by Hijack, works great. I try to do this with a song coming from my server, it doesn't work so great. I don't know where this is fixed.

One of the header fields given by the client for HTTP 1.1 is:

Content-Range: bytes=<start>-[end]

Edit: For more information about server side stuff, check section 14.16 in RFC2616.
Edit: here's some information about client side: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35

Here is the reference I found on the subject of "Range" transfers via HTTP:

http://www.vbip.com/winsock/winsock_http_08_01.asp

Okay, v161 broke IR translations .. oops.

v162 fixes them again, and adds ERROR messages on the serial port for bad translations, plus a Popup ERROR alert as well.

Cheers

-ml

This example:

http://your.empeg./proc/empeg_notify?SERIAL=%23100

sends "%23100\n" to the serial port "input". The %23 is just a '#' character, so it really sends '#100\n', which should (after a few seconds) cause the player to restart at the root level playlist.

The rest of the URL just returns current player status.

You could replace /proc/empeg_notify with /dev/null to send the command but receive no output back.

-ml

Oh yea, the '#100' syntax appears to be broken in beta7, so you may have to wait for a newer beta to use it.. forgot about that..

Mark, great stuff as usual!!!

I love the ability to browse with http://player.IP.address/drive0/fids/101?.html!

It seems to act strangely on my system though...

Clicking on "Play" opens the playlist, instead of playing it, unless there are no more nested lists. So, if I'm at "Artist" level, and click on "Play", then it opens that artist's subfolder, which contains albums. But when I'm at "Album" level, and click on "Play", then it actually plays the album. Clicking on a track also plays the track as expected, BTW.

Another strange thing I get, is that only half of the artist names show up in the playlists. I've attached a screenshot of that one.

And lastly, the other strange thing I'm seeing, is actually within WinAmp. When albums are streamed to WinAmp, all of the songs have the correct name in the playlist window, but, as soon as a song starts to play, the HTTP address of the empeg flashes by quickly, and then the name changes to a 4 digit code. My guess is that it's somehow reverting back to the code that shows up on the unit, but I'm not positive.

Details...
empeg MK2, 2.0b7, hijack 161
WinXP system, running IE6

Hi.

As noted in other threads, Hijack will not play from nested playlists, because I don't want to do recursion within the kernel (would run out of memory very quickly). This is by design, and is unlikely to be fixed anytime soon. Sorry.

I dunno why some of your artists don't show.. how about you look at the tag files (the /drive0/fids/*1 files) and make sure the "blank" ones actually have the "artist" information filled in.

I'm not sure what WinAmp wants for data, but I'm feeding titles to it. Perhaps your MP3's are missing ID3 tags? I don't use WinAmp, but if you can figure out what it wants that is missing, I'll fix it.

Cheers

Hmmmm... Looks like I'm not the only one running into the WinAmp issue. I just found this thread...

How to get Winamp to show id3 info when streaming from the empeg via http

Not sure why this was in "Off Topic"...

Does anyone else experience this behavior with hijack? I’ve had this for a few versions and it hasn’t fixed itself so here is a bug report.

After the player starts up, if you crank the volume knob down/up it is very slow in response. I can literally turn the knob down, let go, and watch the volume go down slowly for 3-4 seconds. After all of the “queued up” buttons finish, everything is normal.

This happens whether in car or home mode and with “Restore DC/Car Visuals” enabled or disabled. The behavior goes away when I install the unmodified kernel on the hijack website.

I usually listen at 0db at home and -40db in the car. I have a home docking station so the empeg doesn’t know the difference. I guess the empeg will remember my settings when the tuner id is implemented in software (any word on that?), but for now I am adjusting the volume every time I’m in the car. With the current versions of hijack I can’t turn down the volume fast enough before it’s really loud.

Tom

Well I started that thread and its not stricly a Empeg issue - I suspect its more a Winamp issue, hence the Offtopic nature.

I did intend to stick a quick post with a link to that thread here but I got distracted.

I'm not sure what the Winamp problem is and as Mark doesn't run winamp [no non-Linux OS's for the kernel king :-)) ], so its pointless [and wasteful of his time] to ask him to sort out a problem not related as far as we know to his streaming hack for hijack.

The only comment I'd make is that Winamp may expect the id3 tag up front in the file - I think the rio Receiver outputs the ID3 tag at the very start in the mp3 file [i.e. it makes a mp3 tag, then tacks it on the front of the mp3 stream].
This way winamp has a tag as soon as the file starts.
thats just my surmise though and I may be wrong.

My only question to Mark would be, how difficult/costly [time & kernel memory wise] would it be for Hijack to take the http request for the *0 file, open the adjacent *1 file and using the [text] info in the *1 file make a valid ID3V2 MP3 Tag and whack it on the front of the mp3 file as its streamed to to the requesting app?
This might keep Winamp happy - but thats merely a suggestion not a request.

In reply to:

---

Another strange thing I get, is that only half of the artist names show up in the playlists. I've attached a screenshot of that one.

---

I get that too, and I know what the cause is - Mark was right when he said look at the Playlist properties in Emplode.

The playlists with no filled in fields *OTHER THAN* Playlist name show up blank. If you fill in some other fields [such as artist, source etc ] (& resync your player) then this information will be shown along with the title
when only the playlist title is filled in you get a blank line in the HTML playlist table.

Not sure if this is a bug or by design - Mark care to comment?

That would be, err, by design.

This shouldn't be needed.. hijack already inserts m3u tags with the track duration and title on them. I wonder what else it wants?

-ml

Hijack will not play from nested playlists, because I don't want to do recursion within the kernel

Cool, no problem.

I dunno why some of your artists don't show.. how about you look at the tag files (the /drive0/fids/*1 files) and make sure the "blank" ones actually have the "artist" information filled in.

Wow, cool... I didn't know you could pull up the ID3 tag info like that... Anyway, I just double checked a couple of those artists, and the ID3 info is all there. I've been pretty anal about making sure all of that info is always filled in, and as far as I know, there isn't a song on my player that doesn't have the ID3 info. ok... some of them have the incorrect year or genra...

Hmmmm... now that I think about it, I know that all of the songs have all of the ID3 info filled in, but I'm not sure about the playlists themselves... Maybe the artists I'm having trouble with are pre-emplode 2.0beta synchs or something... I need to investigate further...

Damn, you have to be fast to keep up with some of these threads!

Well I started that thread and its not stricly a Empeg issue - I suspect its more a Winamp issue, hence the Offtopic nature.

Oh... Yeah... Duh. I guess that does kinda make sense So, yeah, it does pretty much look like a winamp issue. Oh well. Hmmm... I'm curious though, do any other streaming players exhibit this behaviour...?

look at the Playlist properties in Emplode...

Yeah... That's kinda what I just figured out...

*sigh* Not looking forward to moding the details of all of those artists...

After the player starts up, if you crank the volume knob down/up it is very slow in response. I can literally turn the knob down, let go, and watch the volume go down slowly for 3-4 seconds. After all of the “queued up” buttons finish, everything is normal.

I had this happen the other day, actually. I tried to reproduce it with no luck, so I just chalked it up to a stray gamma ray or something.

*sniff sniff* smells like a bug...

The playlists with no filled in fields *OTHER THAN* Playlist name show up blank. If you fill in some other fields [such as artist, source etc ] (& resync your player) then this information will be shown along with the title
when only the playlist title is filled in you get a blank line in the HTML playlist table.

OK... I did a little more research on this... In my case, none of the artist info is filled in on any playlists, only on songs. I guess this is a byproduct of me already having the directory structure in place on my computer, and just doing the drag and drop thing in emplode. If you take a look at that screen shot I attached earlier, and you'll notice the "Artist" column is completely blank. It's actaually the "Title" column that shows the artists, albiet only half of them.

So, I tried filling in the artist info for one of my playlists, and sure enough, the title shows up fine now. So, the real question now is...

Is there an automated way of filling in this info...? I have a ton of artists, and it's gonna suck doing this by hand...

My comment relates to the HTML Playlist that gets sent out.
not the m3u files you get if you click on the 'play' link of a playlist.

The html 'table' you create for the root playlist (and playlist containg playlists) has a all blank table row entry [**including the Playlist name**], whenever the fields from the playlist are missing [i.e. even if the playlist name is present its not shown in the html table if all the other fields are missing from the playlist properties].

This sounds like a bug in the html table output routine.

Hmm, how do I use the playlist function.

Do I simply create a playlist in Winamp and FTP it over??

TommyE

Install Hijack V160 or later,
then point your web browser at your empeg using a url like:

http://192.168.1.43/drive0/fids/101?.html
where you raplace the 192.168.1.43 with your empegs IP address/machine name.

then follow the blinking lights - you'll get a clickable HTML table of playlist, if you click the first link on each row it sends a Winamp m3u playlist file to your PC, which winamp should then fire up and start playing the playlist.

clicking on the next link will produce another html table like the first showing all the songs for this playlist.

Try it its easy,

> Install Hijack V160 or later, then point your web browser
> at your empeg using a url like:
> http://192.168.1.43/drive0/fids/101?.html
> where you raplace the 192.168.1.43 with your empegs IP
> address/machine name.

What he said.

And if you get tired of typing that (am sure we'll all bookmark it) or telling your co-workers how to reach your empeg, put an HTML file in the root directory containing something like this:


<html>
<head>
<title>empeg 30GB Playlist</title>
</head>
<FRAMESET>
<FRAME SRC="/drive0/fids/101?.html">
</FRAMESET>
</html>


...and if you named it, say, PLAY.HTM, all you'd have to enter is this:

http://<empeg IP address or HOSTS alias>/PLAY.HTM

Not particularly clever, but handy. One could also just use a META-REDIRECT set to 0 seconds.

Great, Thanks for the help. Both of you, I have it working now.

TommyE

I can see that the knob might be less response immediately after startup, because the player is doing a lot of disk reading at that point.

And the "knob twist debounce" logic in Hijack DOES add a slight delay to all knob rotations, and this could be magnified if the player is really busy with the drive, I suppose.

-ml

Mmm.. I don't see this happening, ever, on v162.

Can you supply more info, like the offending tag files themselves?


Thanks

Could you include symbolic button names on the khttpd ?button= interface? Or is it a hassle .... ?

>Could you include symbolic button names on the
>khttpd ?button= interface?

Sure.. I just noticed this morning that I'd forgotton to do it there. It's in for v163.

Cheers

Hey Mark, I am having problems get v162 to compile. I used to be able to compile your patches without a problem (although I haven't tried since about v100). Does the following error mean anything to you? This is 2.0b7 + voladj.patch + rdsfake.patch + v162.hijack.v200b8.patch. Will this not work against the b7 kernel? Everything patched cleanly except for one small offset.

arm-linux-gcc -D__KERNEL__ -I/home/mcomb/empeg/kernel/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -msoft-float -march=armv4 -mtune=strongarm110 -c -o hijack.o hijack.c
hijack.c:14: linux/empeg.h: No such file or directory
In file included from hijack.c:17:
/home/mcomb/empeg/kernel/include/asm/arch/hijack.h:4: linux/empeg.h: No such file or directory
hijack.c: In function `hijack_ioctl':
hijack.c:3670: `EMPEG_DISPLAY_MAGIC' undeclared (first use in this function)
hijack.c:3670: (Each undeclared identifier is reported only once
hijack.c:3670: for each function it appears in.)
hijack.c:3676: warning: unreachable code at beginning of switch statement
make[2]: *** [hijack.o] Error 1
make[2]: Leaving directory `/home/mcomb/empeg/kernel/arch/arm/special'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/home/mcomb/empeg/kernel/arch/arm/special'
make: *** [_dir_arch/arm/special] Error 2

Thanks,
-Mike

Okay, Hijack v163 is now available (use the link at top right of your screen).

New in v163:

playlist browser now works for two-drive systems (untested)

song titles are provided for WinAmp streaming

song title.ext is provided for http music downloads

slightly slower FTP/HTTP file transfer performance, due to rewritten internals (smaller, but slower)

Symbolic button names now work with the "BUTTON" command (/proc, http, and ftp SITE)

Let me know if anything you use appears to be broken.

Cheers

The latest Hijack kernel sources require a base kernel of v200beta8, available from the hijack site.

Cheers

Ahhh! Thanks, guess I missed that.

-Mike

But now I have another problem, voladj won't patch over the b8 kernel. It fails trying to patch include/asm-arm/arch-sa1100/empeg.h????

Am I missing something obvious again?

-Mike

Mark,

I can only see v162 on your web page?

Thanks,

James.

It's up for me..
http://empeg-hijack.sourceforge.net/v163.hijack.v200b8.mk2.zImage

Thanks for the link - I can still only see v162 though? Oh well.

James.

I can see that the knob might be less response immediately after startup, because the player is doing a lot of disk reading at that point.

Well, it only happens with the hijack kernal. So unless it's hijack that is doing the disk reading, I don't understand why.

And the "knob twist debounce" logic in Hijack DOES add a slight delay to all knob rotations, and this could be magnified if the player is really busy with the drive, I suppose.

Sounds like this might be it. I tried searching and couldn't find what this is for? Is it possible to make it a config.ini option?

If not, I'd like to request a set volume startup level feature (In car/home the player always boots with a volume of -Xdb). I think this has been discussed before and seems like it would be very useful.

Tom

song titles are provided for WinAmp streaming

Looks good, it reads songname.mp3 when it's playing. You might want to consider doing what I'm doing (or you might not want to consider..as it'll only benefit the anal Winamp users among us, myself included) so far as sending a different value for the filename depending on the request method (either from a playlist, or not).

I don't know if it's possible, but if we could get the "Artist - Title" for the filename when playing an m3u, it'll match the information that's displayed on tracks that haven't been played yet (read from the m3u ext info). Right now the a song that hasn't been played will show the Artist and Title, and once it's played it'll change to "title.mp3". No biggie either way, I guess.

That's why I have playlist=1 in my URL string..it tells my app if it's a "straight" request, or if it's part of a playlist.

playlist browser now works for two-drive systems (untested)

It seems to be working better than it was, but I'm noticing something quirky with the empeg db info / ID3 tag info missing sometimes...

Play  Danzig  0:00  playlist    

Play  /drive0/fids/201  0:00  playlist    

Play  /drive1/fids/bcc1  0:00  playlist    

Play  Dio  0:00  playlist    

Play  /drive1/fids/1af1  0:00  playlist    

Play  /drive0/fids/9a21  0:00  playlist  

Thanks for sorting the two-drive issue. There's still something a bit odd going on with it though. Some of the Playlists don't have names they're just pathnames. Take a look at the attachment to see what I mean. BTW did you get the fids I sent you OK?

Just edit voladj, and change the "empeg.h" to "linux/empeg.h"

-ml

Basically, Hijack inserts the playlist pathname whenever it cannot get a title for something. I'm not sure why it is having trouble with some titles, though.. probably another buffer issue somewhere.

Of course it works perfectly here.

In the meanwhile, hijack v164 is now released. The only difference is that it now uses the "icy-name:" tag to provide tracknames to clients that request it, which includes WinAmp and the Linux/unix XMMS look-a-like. This also solves the ".mp3" extension problem.

If anyone else wants to do it, just include a line like this in the HTTP response header

icy-name: Abba - Super Trouper

Cheers

Ahah.. I just figured this one out.. some of the "title=" tags on your system are stored with an uppercase 'T', as in "Title=". I thought my tag matching logic didn't care about case, but it does for the first letter only.

v165 will be out in a few minutes with the fix!

-ml

That's a nifty tip...thanks.

I just figured this one out..

Great! Keep up the good work

OK, I can confirm that this works perfectly now. Yippeeeeeee!!!!!!!!! the guys at work will be happy Bunnies again . Well done Mark. This is fantastic. Now, the next project should be to get the player to do the washing up and make the Coffee .

(v166) Song titles! w00t!

Although I lost the ability to FF/RW (seek) within a track. Any time I mess with the slider it just changes tracks, forward or backwards.

Me too, I'm on V166 with Winamp 2.78
seeking [forward or back] in a track goes to the next track.

I'll put out v167 in a minute or so, with the seeking fixed (Hijack was not testing the result value from lseek() correctly).

Cheers

-ml

hi Mark, just tested 167 with Winamp - works well.

but I noticed a odd difference between my Mark2 empeg [1 disk] and my Mark2 RioCar [2 disks].

Whenever I reboot the RioCar via the Knob [and press the left/right buttons on the front to begin the reboot], I get a 'Rebooting' message on the display - then it reboots etc.
[the waving tux animation appears, your version number pop up etc].

But - on my Empeg Mark2, it doesn't show the Rebooting message, it just reboots without the Rebooting message.

Is this something other folks have seen or is it related to one being a 2 drive system and one not [the 1 drive system 2 drive detection disabled].
Other than the drives the only other difference [now] is that one is a Mk2A and the other a Mk2.

any ideas?

That's just a hardware (or boot block?) difference between Mk2 and Mk2a units.. on Mk2, the display hardware is reset (cleared) immediately, and on Mk2a it doesn't happen until software (the kernel) is loaded.

Cheers

v168 will remove the "knob rotation delay" from hijack, except when Hijack menus are active (which is where the delay is needed anyway).

-ml

Works very long distance too, I had a friend of mine try it from Australia (Hello Mark!) through a NAT'ing router into WinAMP. No problems!

Okay, v168 is out.

a convenient shortcut is now supported:

    http://your.empeg/?playlists

playing nested playlists now works, up to 16 levels deep, with no limit on the number of tunes

lots of new config.ini settings for security purposes:

   kftpd_password=xxxxx ;; require FTP password

   khttpd_files=0       ;; prevent HTTP file downloading

   khttpd_dirs=0        ;; prevent HTTP directory browsing

   khttpd_commands=0    ;; prevent HTTP Hijack commands

   khttpd_playlists=0   ;; prevent HTTP playlist browsing/playing 

removed some delays from knob-rotate processing

Have fun

-ml

Are you putting this stuff into a help file of some sort on your site? I'm not going to be able to remember everything. BTW, if you have a list of some additional config.ini options, then I wasn't able to find them on your site last night (like a setting for how fast Hijack menus timeout).

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

Bruno

Hi!

My MkIIa was playing a longish playlist (~5000 tunes) when I tried new nested playlists. I displayer root playlist (using new syntax), then clicked on 'Artists' playlist that contains many others (I clicked the name, *not* 'play'). There was a brief glitch in player audio output, browser's title changed to trap v1.02 20001106 (hugo@empeg.com) but otherwise didn't change, and serial output contained disgnostics found in the file attached.

P.S. If at all possible, *don't* remove nested playlist feature in the course of debugging

removed some delays from knob-rotate processing

Thanks Mark!

Tom

Has anyone put together a good hijack help file?

That would be a full time job, just keeping up with the updates! Mark, could you go on holiday for a week or so so we can catch up?

Is it possible to create a flash app or something which runs locally and access the db/files on the empeg, given the right pointers?

Can you retest with v169, and if still broken, send me (1) the trace again (thanks), and (2) a .tar file containing all of your *1 files and all of your *0 playlist files (but not the *0 tunes.. just gimme all files under 3KB in size).

Thanks

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

A VERY LONG time.

It could be reduced by certain parameters at creation time, but on the empeg I think those are needed.. so.. go see a movie or two.

Cheers

When browsing dirs on my empeg through the cool ?.html interface, I hit one directory where I got the following error (and no files listed):

invalid fid type in "/drive0/fids/2071": ""


Just a heads up, obviously this isn't anything crucial

Thanks Mark!
Jon

Greetings!

In my case, a double feature. Very painful. I just had my first surprise fsck while syncing to the empeg, and it timed out the sync code! Of course, that means I am now going in manually and doing the fsck...

>invalid fid type in "/drive0/fids/2071": ""

Oh, Good! The error messages *work*!

Go back to your player, and view this file:

http://your.player/drive0/fids/2071

Tell us what you see.. I'm betting either (1) nothing,
or (2) no line that looks like "type=tune" or "type=playlist".

All of those are signs of a "bad database" on your player.

Cheers

Actually, when Emplode "times out" on the media check, just ignore it and leave it alone.. the player WILL eventually finish the fsck and then (hopefully) bring up the player.. it just takes it a while.

Cheers

Here's what I get:

ctime=1011908571
length=52
title=00-goldfinger-hang-ups-1996-hit
type=playlist

If it means anything, I can play that directory just fine on my Empeg.

Jon

Are you sure that last line did not have an uppercase 'P',
as in "type=Playlist" ??

Thanks