Mmm.. you're correct in that the empeg_state does not store the FID of the current track. Bummer.
In an ideal world, the empeg folks will add this info to /proc/whatever for us someday. But don't hold your breath waiting for them to do us this freebie, and we cannot easily do it our selves since the player code is closed source..

Ironically enough, if we had the FID, and a way to "Feed" a FID back into the player software, this would be all we'd need extra to replace the player menu system entirely with our own menus (that scroll vertically instead of the clever but clumsy horizontal scrolling the player uses..).

The only "clever" idea I have so far is to just "intercept" the calls to "open()" and have code recognize when FIDs are opened/closed, since the FID is part of the pathname. This could be stuck into a hacked (or hijack'd) kernel without much trouble, and made available via /proc, ioctl(), and the vitals display. The only trouble is that the player buffers ahead, reading the next track(s) while playing the current selection.. but I wonder *when* the close() gets called for a track.. ?

-ml