jalik / meteor-jalik-ufs-gridfs

GridFS store for UploadFS

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Version 0.2.1: Cannot correctly read small audio files (< 256 kB)

seabrus opened this issue · comments

Hi @jalik,

Please help me with this issue:

When I use the version 0.2.1 of the jalik:ufs-gridfs package my app cannot correctly read audio files that are less then 256 kB. Files with sizes that are larger than 256 kB are loaded and played fast and correctly. If I use the version 0.1.4, everything is OK for files of any size.

The behavior of the app is a little different in FireFox and Chrome (I'm using the latest versions of both ).

FF: when starting loading an audio file of, for example, 37 kB in size, the browser waits for exactly 120 seconds and then loads the file correctly (all 37 kB) with the status 206, and the app plays it.

Chrome: for the same file that is mentioned above the browser loads first 22 kB with the status 206 and the app plays them. But after about 2 minutes the browser indicates the error net::ERR_CONTENT_LENGTH_MISMATCH, then 6 times net::ERR_EMPTY_RESPONSE, -- and the status is changed from 206 to (failed). At the end the error 503 (Service Unavailable) is shown for the file under consideration and it can't be played.

Meteor's version: Now I use 1.5.1 version but that issue is seen for other versions too, e.g., for 1.4.3.2.
Code for the store is standard:

AudiosStore = new UploadFS.store.GridFS({ // or AudiosStore = new GridFSStore({... - no difference
  collection: Audios,
  name: 'audios',
  chunkSize: 1024 * 255,
  ...

Thanks in advance!

Hi @seabrus, I am really sorry to says that I don't have free time to spent on open source projects.
I hoped that people would participate more in improving this project, that happened already before.
All of these are really specific cases and should not be difficult to fix.

Did you try with another store like the LocalStore ? (to be sure it's related with the GridFS store and not with core functions in the main UFS package)

Hi @jalik,
I did not try LocalStore yet. I tried jalik:ufs-gridfs version 0.1.4 instead of 0.2.1. The result was positive: with jalik:ufs-gridfs version 0.1.4 the app works correctly. That is why I suspect that the problem is in jalik:ufs-gridfs version 0.2.1.

Hi @jalik,
I've tested the app with LocalStore -- it works correctly.
So, the problem appears when transferring from jalik:ufs-gridfs 0.1.4 to jalik:ufs-gridfs 0.2.1.

If other tests are necessary to clarify the issue, I'm ready to make them.

@seabrus I've made some tests and researches today, but unsuccessful..
Seems that it's kind of related to the range HTTP request, since when the related code is commented, everything is fine, also it's definitly related to the GridFSBucket component in conjunction with the start/end options given by the HTTP range request. Maybe there's a bug in their code.

https://jira.mongodb.org/browse/NODE-829

@jalik If in my app I replace jalik:ufs-gridfs 0.2.1 with 0.1.4 for a while, is it safe?

@jalik
One more test.

1). jalik:ufs-gridfs: version 0.2.1

2). Standard code for chunkSize is as follows:

AudiosStore = new GridFSStore({
  collection: Audios,
  name: 'audios',
  chunkSize: 1024 * 255,
  ...

This code version leads to failure when loading an audio file of 37 kB in size.

Then I changed chunkSize from 1024 * 255 to 1024 * 10 -- and now the file size is bigger than chunkSize. The result is positive: the file was loaded correctly and without any delay.
To check that result I also made:
chunkSize: 1024 * 50 -- failure;
chunkSize: 1024 * 20 -- success.

So, the problem appears only when the file size is less than chunkSize.

@seabrus I think you can use the v0.1.4 because the difference between both versions is the driver used to read/write streams in GridFS, previously the gridfs-stream package was used, but later replaced by the native GridFSBucket API that causes problem in this issue.
Here's the diff : 82af323

I've submitted an issue : https://jira.mongodb.org/browse/CDRIVER-2220
I can't do more from now.
Hope they will fix this if it's really a bug on their API.

@jalik OK, thanks a lot for your support and time!