You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I ran into an issue while trying to execute retrieveSignedPackage. The GetToFile function in rokuDeploy needs further customization to handle devices with low CPU and memory, as is the case with a Raspberry Pi.
Below is an optimized version of the GetToFile function that "optionally" can also compare a checksum to verify the integrity of the signed package. I tested it on a Pi, and it works as expected.
asyncfunctionoptimizedGetToFile(requestParams,filePath,expectedChecksum){awaitfsExtra.ensureFile(filePath);// Handle partial downloadsconstheaders=fs.existsSync(filePath)
? {Range: `bytes=${fs.statSync(filePath).size}-`}
: {};requestParams.headers={ ...requestParams.headers, ...headers};letwriteStream;returnnewPromise((resolve,reject)=>{try{writeStream=fs.createWriteStream(filePath,{flags: 'a',highWaterMark: 64*1024});// // Calculate checksum while writing// const hash = crypto.createHash('sha256'); // Change to match your checksum algorithm// writeStream.on('finish', async () => {// // Verify checksum after the file is fully written// try {// const calculatedChecksum = await computeChecksum(filePath);// if (calculatedChecksum === expectedChecksum) {// console.log('Checksum verified successfully.');// resolve(filePath);// } else {// reject(new Error('Checksum verification failed.'));// }// } catch (err) {// reject(err);// }// });writeStream.on('finish',()=>resolve(filePath));writeStream.on('error',(error)=>reject(error));constreq=request.get(requestParams);req.on('error',(err)=>reject(err));req.pipe(writeStream);letdownloadedBytes=0;letlastLogged=0;req.on('data',(chunk)=>{downloadedBytes+=chunk.length;if(downloadedBytes-lastLogged>=64*1024){console.log(`Downloaded ${downloadedBytes} bytes`);lastLogged=downloadedBytes;}});req.on('socket',(socket)=>{socket.setTimeout(requestParams.timeout||300000);socket.on('timeout',()=>{req.abort();reject(newError(`Request timed out after ${requestParams.timeout||300000}ms`));});});req.on('end',()=>{console.log(`Download completed: ${filePath}`);});}catch(err){reject(err);}}).finally(()=>{if(writeStream){try{writeStream.close();}catch(err){// Ignore stream close errors}}});}
The text was updated successfully, but these errors were encountered:
From what I can tell, the only relevant changes are to set highWaterMark and also support calling the function multiple times so you can download the file in chunks.
However, I don't know why either of those matter. The entire signed package should be 4MB or less, which every PI since the first release has enough RAM to do that.
Could you better explain what you're trying to accomplish here, and how your changes mitigate the issue? How would consumers expect to use your proposed changes? (do they need to call the function multiple times?)
Hey @TwitchBronBron! The configuration above was the only one that got things working on an ARM32 Raspberry Pi. While the signed package was relatively small at around 3.2MB, I found that managing the download in smaller, optimized chunks helped me successfully download the entire file. Otherwise, after increasing the timeout property on your original implementation, I kept encountering an ESOCKETTIMEDOUT error towards the end of the download -- event.
I started by adjusting the timeout property to the highWaterMark setting to ensure more efficient stream buffering, which helped limit memory usage during I/O operations. Ultimately, adding support for partial downloads (by setting a range) allowed me to complete the full download of the file successfully.
The function doesn't require multiple calls. It can be called once as usual (within the related functions), and it will handle partial downloads automatically if a file already exists at the specified path.
The checksum part is a nice add-on, but I haven't added that part on my end, either.
I ran into an issue while trying to execute
retrieveSignedPackage
. TheGetToFile
function in rokuDeploy needs further customization to handle devices with low CPU and memory, as is the case with a Raspberry Pi.Below is an optimized version of the
GetToFile
function that "optionally" can also compare a checksum to verify the integrity of the signed package. I tested it on a Pi, and it works as expected.The text was updated successfully, but these errors were encountered: