No, I haven't written any code yet. Just creating a thread to focus discussion on how to make it work. I first posted this on the RioReceiver BBS, but since it is actually mostly an Empeg hack, I'm moving the discussion (if any) to here.

(1) DHCP not provided -- use whatever DHCP server your network already has. None present? Get one then!

(2) The initial NFS download of "zImage" will be spoofed by Hijack as a special case. A real NFS implementation will not be provided -- this hack will work ONLY for the one "zImage" download.

(3) The zImage file itself (Receiver's Linux kernel) will be hacked to use FTPFS instead of NFS for subsequent .ARF accesses. This allows it to "mount" its Linux filesystem using FTP via Hijack's existing FTP server. No new code in Hijack for this.

(4) The actual music services will be provided by the existing Hijack HTTP server, with some special-case enhancements to find/filter the database info required. Soup views and the like can be obtained by having Hijack read/filter the existing Empeg "database" file.

Comments?

This sounds like a totally cool project. Best of luck!

Some information about the HTTP interface (off the top of my head, so it may not be completely accurate):

/tags

The first thing that the Receiver asks for is "/tags". This is just a list of the database field names. You can hand over /empeg/var/tags.

/layout

The next thing that the Recevier asks for is "/layout/en_UK/index". This is the index of layout definitions.

The index file contains the layout definitions, one per line. The Receiver will pick one and download it. The file contains the server-relative URI for each layout definition.

You'll probably want to stash these in /empeg/lib/layout and hand them out from there. Wherever the Central keeps them is probably a good idea, for consistency.

Then, there are various other things that the Receiver will ask for:

/tags/fid

This is the tags for a particular FID. It's exactly the same format as in the empeg's "database" file.

/content/fid

This is the MP3 content for a particular FID. You'll need to be able to satisfy "Range:" requests, since the MP3 download is in chunks.

If you specify the FID for a playlist, then this returns the FID entries for the immediate children. See this for more information. A variables that you can try is "_extended" for controlling the format. _extended=0 (the default) returns the binary format (i.e. the content of the *0 file). _extended=1 returns the format detailed on the linked page. It might also support _extended=2 and _extended=3, depending on whether they got turned on for the final release (one of them was a nice HTML-rendered list).

/list/fid

The Receiver wants the (flattened) list of descendants for a particular playlist. It'll generally ask for /list/100 soon after it starts.

You can ask for this list to be shuffled by passing "_shuffle=1" (or was it _shuffled, or shuffle?).

/query?tag=regex

Used for the Receiver search screens. It'll only ask for "artist", "title", "album" (or was it "source"?) and maybe "genre". I don't remember. I detailed the response format in a PM conversation with Tony. Maybe he can repost it here.

The only regexes supported are character classes (i.e. simple lists of characters in square brackets). A wildcard (i.e. dot-star) suffix is implied.

/results?tag=value

Return the list of FIDs found by choosing one of the entries returned from the above query. Takes the same _extended variable as described above.

Other Notes/Caveats

The Receiver does not support "Transfer-Encoding: chunked". You should(preferably) return a Content-Length header. You will always have to use "Connection: close" semantics.

The Receiver will never pipeline requests.

If you don't respond to a query within a sensible time limit, the Receiver will retry its request. If you're going to take a long time to process a request, consider waiting for the retry and handing back the data then, IYSWIM.

Oh, and notes for v3.0-alpha users: The Receiver doesn't support UTF8, so you'll probably have to do something nasty to get it to work against the /empeg/var/database3 file.

I detailed the response format in a PM conversation with Tony. Maybe he can repost it here.

Here's the resulting notes I have from that conversation. I created a list of queries and the responses that my Jupiter returned when I tried...

(Get the list of playlists...)
http://192.168.0.4:12078/content/100?_extended=1

3760=P(Low Key)
3c80=P(Workout)
5620=Ptemp

(Get all the songs in one playlist...)
http://192.168.0.4:12078/content/3760?_extended=1

3ee0=TLessons
3ef0=TTears
3f30=TCloser to the Heart
3500=T'39
3520=TSeaside Rendezvous
(...)

(Play a FID once we know it...)
http://192.168.0.4:12078/content/3ee0

(Plays LESSONS)


http://192.168.0.4:12078/query?artist=a

matches=
0=0,0,0:Aaron Copland
1=0,0,0:Aimee Mann
2=0,0,0:Al Petteway
3=0,0,0:Al Petteway and Amy White
4=0,0,0:Alabama 3
(... all artists that start with a)

http://192.168.0.4:12078/query?artist=

matches=
0=0,0,0:10,000 Maniacs
1=0,0,0:Aaron Copland
2=0,0,0:Aimee Mann
3=0,0,0:Al Petteway
(... entire database is returned, by artist)


http://192.168.0.4:12078/results?artist=Rush

Gets a funky binary file named results.txt?


"You might need to stick '&_format=1' (or =2, or =3) on the
end of that to get the results in a different format.
Otherwise, I think it's just a binary list of FIDs (and
possibly lengths or something). Or, that might be '&_extended='.
I suggest that you download a copy of Ethereal and watch what a
real client does."

http://192.168.0.4:12078/results?artist=Rush&_extended=1

3eb0=T2112
5570=T2112- Discovery (Live DS)
7230=T2112- Oracle- The Dream (Live DS)
5550=T2112- Overture (Live DS)
5580=T2112- Presentation (Live DS)
(... all songs by Rush)


http://192.168.0.4:12078/results?source=2112&_extended=1

3eb0=T2112
3ec0=TA Passage to Bangkok
3ed0=TThe Twilight Zone
3ee0=TLessons
3ef0=TTears
3f00=TSomething for Nothing

(... the album 2112 in alphabetical order)

Okay, I just applied half an hour to this stuff, and got a working FTP-filesystem implementation in an Empeg kernel (haven't tried the receiver kernel yet, but that's where it will eventually go, rather than in the empeg's kernel).

So for 17KB of code (I used someone else's implementation, after fixing it), one of my Empegs can mount the filesystem of another Empeg and browse it's files, all over FTP instead of NFS. Cool. So I suppose I ought to move that code into the Receiver kernel soon. I will also leave it in the patchfile for Hijack v344 eventually, but not configured by default so that it takes no space in a normal empeg build.

Cheers

Hey.. I just thought of something.. with some cleverness in FID numbering, it should be possible to amalgamate the music collections of two players with this scheme.. so that each player can access the other's tunes .. I suppose DJ's would have a use for such..

Cheers

I suppose DJ's would have a use for such..

Or Paul... I mean, 160GB is like nothing...

/Michael

Oh can I, can I ???























Imagine a Beowulf cluster of these!

Imagine a Beowulf cluster of these!

Hugo did it already...

Must get wireless at next empeg meet

Any further progress on the Hijack for the Rio Receiver?

Oh, and one thing I forgot. If you're grabbing the files with IE, you can wedge a &_ext=.mp3 on the end there to make it "do the right thing" with /content/fid. If you specify an extension (even as a parameter), it'll give it that extension when getting it. If you don't, it'll probably display it as binary or text (it depends on your IE configuration).

The actual &_ext=.mp3 is ignored by the server, but gives a hint to IE about what it is if your MIME types are screwed up.

(I had to use this hack on an internal build of the Receiver server that handed out .m3u files when asked for a playlist).

Nothing new right now -- I did the Empeg subdirs hack instead. And now I'm working (once in a while, it happens..), and next week I'm flying over to visit with Alvin and Erin in gay Paris.. so perhaps this will become my Christmas project..

Cheers

Ooh hey, that's good info Roger, thanks!