fix range for bogus mp4 streams#655
Conversation
According to this discussion https://forums.slimdevices.com/showthread.php?115070-Global-Player-Remote-M4A-(containing-AAC)-streams-no-longer-working-in-LMS, some site migth have bogus mp4 header or content-length HTTP which causes stream GET using a range requets to fail. This PR forces audio_size to make sure audio_offset+size do not overshoot content_range
| if ($info->{audio_offset} + $info->{audio_size} > $http->response->content_length) { | ||
| $log->warn("inconsistent audio offset/size $info->{audio_offset}+$info->{audio_size}and content_length ", $http->response->content_length); | ||
| $track->audio_size($http->response->content_length - $info->{audio_offset}); | ||
| } else { | ||
| $track->audio_size($info->{audio_size}); | ||
| } |
There was a problem hiding this comment.
Please help my limited understanding: when doing a range get, wouldn't the content length always be shorter than offset plus size? Basically: is the content length reporting the chunk size, or the full file's size?
Ok, but this change is about them being larger, so this shouldn't even matter.
There was a problem hiding this comment.
The content_length is always the full size, never the chunk size. In fact when you use chunked mode, the content_length must not be indicated.
When scanning a stream, I'm memorizing the audio_offset and audio_size and then during actual streaming I'm making a range request starting at the offset and up to offset+size-1 which must be less than content_length. I have to do a range request with a precise last byte because some files have crap at the end and I just want the audio.
The issue he is that this server sends a mp4 with (eg) 100b of header (offset) 1kB of audio_size, so I make a request of 100-(1100-1). The file should be at least 1100 bytes long but in fact the content_length of the http response is 1020 bytes, so my range request fails. It looks like an incorrect encoding or (much less likely) an HTTP error when content_length is set
|
Let's give this a try - thanks! |
3 participants
According to this discussion https://forums.slimdevices.com/showthread.php?115070-Global-Player-Remote-M4A-(containing-AAC)-streams-no-longer-working-in-LMS, some site might have bogus mp4 header or HTTP content-length which cause stream GET using a range request to fail. This PR forces audio_size to make sure audio_offset+size do not overshoot content_range