UPnP sendfile64 returns Invalid argument error.

[MTisza@…]

Line 287 of httrequest.cpp uses sendfile64 to send the files out to the UPnP/http client. I narrowed down my probelm to that call, and changed it as such to find the error message:

if (sendfile64( getSocketHandle(), file, &offset, llSize ) < 0 ) {

perror("Error sending file: ");

}

After that I can see: 2006-09-20 06:33:47.977 HttpWorkerThread::ProcessWork:Begin( -1394639952 ) socket=15 Error sending file: : Invalid argument 2006-09-20 06:33:47.987 HttpWorkerThread::ProcessWork:End( -1394639952 )

This only happens on some files. At first I thought it was only & all large files. After some additional testing I can see a file that's 5.8GB so that's out I think. All my files are recorded OTA/ATSC/HD. They play fine locally, but not via UPnP. My troublshooting included a complete reinstall of the OS, from ubuntu at first to kubuntu. Both were dapper drake releases.

[MTisza@…]

I'll just add the fact that the arguments do appear to be valid as far as I can tell. The file and stream descriptor are 15 & 14 most of the time (this obviously changes now and then). The offset is always 0, and the files size is a match with what ls -la gives me for the corresponding file. I verified this before and after the call to sendfile64. Is there a better replacement to the sendfile64 call?

[anonymous]

This should be major. Video files aren't served.

[MTisza@…]

For the time being I was able to hard code some changes that tell the client to stream the files from another server which in my case was an apache 2.2.3 server on the same machine. That works beautifully, but it's a real kloodge. Anonymous, have you been able to duplicate this problem exactly?

[troycauble@…]

single file patch

[troycauble@…]

Attached patch fixes the bug. Basically sendfile takes up to INT_MAX bytes and doesn't guarantee to write them all.

[dblain]

(In [11304]) fixes #2430

Fixes issue where sendfile64 returns without sending all data.

Also, added Date: to the response http header.