|
|
|
|
Screen Layouts
The "layout" command is used to list and select screen layouts. The basic command simply generates a list of available layouts:
http://server/layout/en_UK/index /layout/en_UK/all_info=All Info /layout/en_UK/remaining=Remaining Time /layout/en_UK/big_title=Big Title /layout/en_UK/scope=Scope /layout/en_UK/inverse_scope=Inverse Scope /layout/en_UK/with_volume=All, With Volume /layout/en_UK/test=Test
Everything to the right of the = sign in the response is listed as a layout in the Rio "Change Layout" menu. The items to the left are the URLs for each layout's actual
file, which, when selected, are provided as a binary list of fields and formatting commands. This is described in detail in the Screen Layout section, below.
The "favourites" command is used to list or select favorite search strings. The Rio supports 100 of these, numbered 00-99. This is a bit more complicated. Essentially, the user can, after selecting a top-level query (like "artist=Genesis"), hit the "List" button on the remote. The Rio then displays a list of all the current playlists, and the user can then enter a playlist number on the remote keypad, then hit "Enter", and the favourite setting is stored on the server.
For some reason which I have not yet figured out, the Rio doesn't send this "add to favourite" command over HTTP. It instead sends a UDP packet to the server, on the server's status port (typically 18678), saying "Favourite (I like it.) Index: ## <string>". The "##" is replaced by the 2-digit list number, and <string> is replaced by the query command used, like "artist=Genesis".
When the user selects a favourite list to play, however, it's again transmitted over HTTP. To retrieve a list of favourites:
http://server/favourites/all 00:artist=Pink%20Floyd 01:genre=Classical 02:album=Tweekend
When the user selects one of these, by number or by paging down with the remote and hitting enter, the Rio uses the string given as the argument to a "results" call: "http://server/results?album=Tweekend". From there, everything proceeds as if the user had simply selected the given album (or genre, or artist) from the top-level menu. It's basically a mechanism to do quick shortcuts to favorite selections of music. Note, also, that none of the open-source servers seem to support this yet. (I'll be trying to get it added to JRec, eventually).
The Rio Receiver periodically sends (or responds to a server-initiated request) a status packet, over UDP, typically to port 18678 on the server. The server says
"State? (What's going down?)" The receiver responds with something like:
State! (The word on the street is) MAC: 00:90:00:11:23:7d Playing: 10f7 State: Playing Timecode: 124000
It's quite possible that we haven't figured out everything that the Rio can do. For example, if one looks at strings in /empeg/bin/player, right around where the UDP status stuff is, we find this:
MercuryProtocol Reboot Reload State? State! Goodbye The word on the street is Favourite I like it. Index
Now, obviously we've already found uses for "Favourite (I like it.)", and "State!." But we haven't seen anything where Reboot, Reload, or Goodbye is used. Other intriguing strings:
http://server/content
Three functions: Play music, provide a playlist, and give a list of all playlists.
http://server/favourites
Returns a list of all favourites defined on the server.
http://layout
Returns a list of available layouts for the given language, and also retrieves the selected layout file.
http://server/list
Returns binary data representing track ID, filesie, and MPEG offset within file, for all tracks on a given playlist, or for a given track.
than a playlist, returns the information for that track alone. _extended=2 is required. Shuffle is optional, and if present, causes the
list of triplets to be randomized prior to returning it to the receiver.
standard Windows server's behavior.)
http://server/query
Looks up albums, titles, artists, and genres. Can be extended with regular expressions and row limiting options.
album names, and "genre=" returns a list of genres present on system.
lines in the response, since they're numbered begninning with zero).
http://server/results
Returns an ASCII or Binary list of songs matching a given criteria.
http://server/tags
Returns a list of available tags, or actual tag data for a given song.
The Rio receives all of its configuration, and even binary code, from the
server, mostly at boot-time. When the user chooses to change the display
layout, the Rio sends a request to the server for a list of available
layouts. These layouts (their names, anyway) are displayed to the user in
the Rio screen, and when one is selected, that layout is requested from the
server. It's a simple binary file, mostly a bunch of double-words (4-byte
long integers), describing what to put on the screen and where to put it.
Update - 22 January 2002 An engineer from empeg has partially
validated what's presented here, and I'm working to incorporate some of his
revelations into the page, as well as to polish a perl script for generating
layouts. I was right in guessing that type 5 was a bitmap, but I still don't
know how to make one. Anyway, you can find Roger's information
here.
The layout is described as a series of field definitions, applied one
at a time in the order in which they're found in the layout file. So, a
later field may overwrite a previous field, which might be nice if you want
to superimpose a track title on top of a full-screen oscilloscope visual.
Each field to be described requires two pieces of information: the field
type, and where to put it. Most fields require additional information, such
as what font to put the data in, whether to align the field left, right, or
centered, and what kind of data to put in the field.
Most fields, then, look something like this:
Type
Left
Top
Right
Bottom
Payload Length
Payload (optional)
The screen, I should mention, is 128 x 64 pixels. For example, "(0x00, 0x00,
0x80, 0x40) would define a 128x16 pixel rectangle
that starts in the top left corner of the screen and stretches to the
right edge of the screen, 16 pixels down from the top.
Code
Explanation
bit-junk. looks a lot like it's a bitmap, or maybe
the content-information is supposed to contain a bitmap,
or maybe an arbitrary string, but I haven't gotten this
to work yet, either.)
shuffle setting (font=2)
Not all field types use the same parameters. Here's an attempt at showing them all at once -- also check out Roger's pages for
a more C-centric way of looking at this. For each type, read downwards -- all fields are INT32 (double-words, 4-byte integers, whatever),
except those in the payload. All the payload fields are one byte wide, except for the bits-per-pixel, width, and height fields for bitmaps, and the color field for rectangles (which
are all INT32).
Information Tag
Tag Code
Explanation
Font Code
Font Code
Explanation
Style Code
Style Code
Explanation
Justify Code
Alignment Code
Explanation
Here's an example, where I built a modified "all info" layout with an added
volume level indicator. Remember, all values are double-word longs, that is,
four bytes, so "0x02" is really "0x00000002". And, also, everything's stored in the file (and transmitted to the receiver)
in little-endian format, that is, the least significant bytes first. So, "0x02" is transmitted as "02 00 00 00".
Type
Left
Top
Right
Bottom
Length
Content
Description
And here's what it looks like:
|
