lseek() returns an off_t and not an int, using an int to store and
test the return value means we'll error out when the position in the file
gets past INT_MAX.
eventfd has less overhead than a pipe, works as a counter and uses a
single fd. Use it on Linux if available (that should be pretty much
always given the glibc and kernel requirements).
512k might be a bit too much, as it can take time to read 512k from the
filesystem (and we're using a blocking read) or from the decoder. Going
down to 64k will make this more manageable and improve the response time
when streaming to multiple clients at the same time.
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.
Julien BLACHE
Ace Jones