We do not have native seeking support for MP4, using a patched version of faad2 for this functionality instead. faad2 only supports single-track MP4s in any case, and also does not have HD-AAC support.

There has been some work on making the server support native seeking (without using faad2) in MP4 files but this is not finished and also works on the basis of a file containing only a single track. 

MP4 as a format makes the assumption that whatever is streaming from it has random access to the complete file but this is not the case for Squeezebox players which get a stream that they read incrementally. I expect that a substantial amount of work would be need to make this work reliably. 

>> Does it try to seek and fail (just restart), or not try in the first place?
>
> It tries to seek and fail (just restart). 

This is probably just the issue in bug 12727. From other UIs it is not possible to attempt to seek.

Since you guys are surely MP4 experts, maybe you can help us with this.  In order to support AAC seeking we need to determine the file offset to seek to (this is relatively easy), rewrite the MP4 header (this is the hard part), and then begin streaming at the given offset.

So for example:
Given an MP4 file and a sample to seek to, create a new MP4 file that begins at the seek point and has a valid header that can be decoded by faad as well as the FHG decoder.  After much work I've been unable to create the proper header.

Also see bug 15661, this is probably a dupe of that, HD-AAC seeking should work if we can implement regular AAC seeking.

We already implemented seeking for hdaac-bitstreams (basically the same as for AAC only, except that you have to apply it for two tracks) with the MPEG-4 file format reference software (libisomedia).

libisomedia provides two helper functions to achieve this. The first function returns the next possible Sync position for a previously calculated point in time you want to jump to. The second function returns a sampleNumber (I think the same as Access Unit number) for the Sync position returned by the first function.

This calculated sampleNumber can be set as the next sampleNumber to be read from the bitstream (at least in this libisomedia file format library implementation) and reading of the bitstream continues at the desired point in time.

For more informations on libisomedia and our implementation please contact me (or Virgilio).

Right, there are various seeking implementations but they all assume random access to the file.  In our case we need to construct a complete MP4 bitstream including new header for sending to a device that does not have random access to the entire file.

I've implemented seeking for single-track MP4 files, will take a look at supporting 2-track HD-AAC files soon.