Page 1 of 2
Downloading with http.request corrupts file
Posted: Wed Aug 03, 2016 3:03 pm
by Tjakka5
Heya!
I'm trying to download files from my server with socket.http; I had it working before, but lost the code.
I'm now trying to recreate the code I made before, but I'm running into the problem that the downloaded file gets corrupted.
In the case of .ogg files, I couldn't even play them. In the case of .wav files, you can faintly hear the sound, but it's mainly noise.
This is my code:
Code: Select all
local http = require("socket.http")
local ltn12 = require("ltn12")
local url = "http://tjakka5.sorunome.de/Extern%20Files/Projects/Data/Soundboard/Tjakka5/Data/Sounds/How%20could%20this%20happen.wav"
local path = "How could this happen.wav"
local down = 0
function counter(chunk)
if chunk and chunk ~= "" then
down = down + #chunk
end
return chunk
end
http.request({
method = "GET",
url = url,
sink = ltn12.sink.chain(
counter,
ltn12.sink.file(io.open(path, "w"))
)
})
Am I missing something obvious?
(The counter function is because I want to track progress as it's downloading.)
Re: Downloading with http.request corrupts file
Posted: Wed Aug 03, 2016 3:15 pm
by Nixola
I tried your code and it yielded a corrupted file. Simply changing 'ltn12.sink.file(io.open(path, "w"))' to 'ltn12.sink.file(io.open(path, "wb"))' solved the issue on my system.
Re: Downloading with http.request corrupts file
Posted: Wed Aug 03, 2016 3:28 pm
by Tjakka5
Ah, I see.
Thank you very much!
Re: Downloading with http.request corrupts file
Posted: Fri Aug 05, 2016 9:23 pm
by Tjakka5
Sorry for the late bump, but is there a love.filesystem equivalent to use? I've been trying them, but they all result in a Error.
Re: Downloading with http.request corrupts file
Posted: Sat Aug 06, 2016 7:24 pm
by NickRock
If you mean io.open equivalent, I don't think so. There's nothing similar to io.open in the documentation
Re: Downloading with http.request corrupts file
Posted: Sat Aug 06, 2016 7:50 pm
by Tjakka5
NickRock wrote:If you mean io.open equivalent, I don't think so. There's nothing similar to io.open in the documentation
I mean, a replacement for "ltn12.sink.file"'s argument.
The current code creates the file where the main.lua is located. I'd rather save it in the save directoy (Appdata).
Re: Downloading with http.request corrupts file
Posted: Sat Aug 06, 2016 8:30 pm
by zorg
NickRock wrote:If you mean io.open equivalent, I don't think so. There's nothing similar to io.open in the documentation
io.open's counterpart would be [wiki](File):open[/wiki].
As for ltn12, i never really grasped the stuff it purportedly could do for me, so can't help you there sadly.
But, as a general idea, if it would be possible, i'd use an in-memory buffer, and when that fills up, would i call love.filesystem.append with the queued up data to be flushed.
Re: Downloading with http.request corrupts file
Posted: Sun Aug 07, 2016 12:17 am
by pgimeno
If I understand what you want, you can use io.open with [wiki]love.filesystem.getSaveDirectory[/wiki].
Re: Downloading with http.request corrupts file
Posted: Sun Aug 07, 2016 6:31 am
by bartbes
I never really understood why the whole ltn12 stuff was supposed to be a good idea either, but I'll second zorg's advice of reading it into memory, then writing that out using love.filesystem.
Re: Downloading with http.request corrupts file
Posted: Sun Aug 07, 2016 8:20 am
by zorg
I suppose it's supposed to be "data driven" maybe?
Pump -> Source -> (Chain -> (Chain or Filter ->)) Sink
Unless i could have 500 processor cores with syncronous memory access... i can rewrite this as
Pump(Source, Destination, Func, offset)
where Source is a buffer, destination is a buffer, and Func can be any function that takes two buffers (and the offset), even a chain/aggregation/composition of functions, or filters; and offset is where we are in the processing...
Interestingly, to me, data driven and functional languages should represent two extremes of programming methods/styles (in my mind at least, purely because of data/code separation), but here i can't help but notice that they are more similar to each other than i'd like to admit
