evbuffer_read() is really meant to read from sockets and not regular
files. It also looks like evbuffer_read() was causing issues with large
files, locking up a little below 2 GB for an unknown reason (couldn't
reproduce).
Try to be a bit more strict about integer types, use off_t or int64_t for
file size and file offsets.
Replace safe_ato*() by safe_atoi32() and safe_atoi64(), fix integer types
at call sites to match.
Hinting the OS about our behaviour shouldn't make a big difference in
performance but it will help the OS manage its disk cache and can reduce
memory pressure on small systems.
When streaming AAC/MP4 files that aren't stream-optimized (metadata at the
end of the file), clients will seek through the file to grab the metadata
prior to playing the file, causing the play count to increase by 2 or 3.
To counter that, do not increase play count if not streaming at least half
of the file.
Honor end offset provided in the Range header and do not stream more than
what the client asked for.
Based on a patch by Ace Jones <ace.jones1@yahoo.com>.
Clients like Front Row expect video/<type> for video streaming, whereas iTunes
likes application/x-dmap-tagged when streaming audio.
Based on a patch by Ace Jones <ace.jones1@yahoo.com>.
This is an extension to evhttp. Without this, we cannot know that the client
closes the connection, and we keep pushing chunks while the underlying
evhttp_request has been freed, leading to a segfault.
iTunes and Roku devices do not encode + as %2B in the query string and
do not encode space as + either in the query string (though at least the
Roku encode space as %20 everywhere). This needs to be worked around or
browse queries fail to parse because + was decoded as space when the query
really needs a + character.
Transcoding is not supported yet.
In the current state of affairs, we will crash if the client closes the
connection before the tranfser is done. This is a limitation of evhttp,
it is not possible to detect this condition. This will need to be fixed
in evhttp.