I am recording audio files on different browsers and share them to all clients via the server. In order for browsers of all platforms to be able to read them, I re-encode them all to .m4a (AAC encoding in the MP4 container) on the server similarly to your piece of code.
On the client, I am using fileRef.link('m4a') to get a link to the re-encoded version. The problem is that the link is pointing to a filename which is using the extension of the original version and not the extension I set in the m4a version. It looks like a bug. It prevents the audio files to be played on the iPads (which are overly picky).
I am on Meteor 1.5.1, latest release of Meteor-File.
Hello @green-coder ,
This is a known "bug" (which is actually a feature). Let me explain - when you requesting a subversion of the file if it is not available original file will be returned, this was done for images and its thumbnails. Which seems okay in a first place, but may lead to larger issue as requested file may be cached on the proxy/web server, CDNs or intermediate servers.
To avoid this behavior - wait for subversion to be created.
As reference take a look at this piece of code, where thumbnail won't be displayed unless versions.thumbnail40 is created. And here loading spinner is displayed while versions.preview is undefined.
Hope this will help you, let me know.
I'm going to keep this open. This changes will require major version bump, as may break existing implementations which depends on this "feature".
Hello @dr-dimitru and thank you for your answer. I will try your fix at work tomorrow.
Alternatively, until a major release happen, would you consider an opt-in fix via a flag on the collection which would avoid redirecting a missing a subversion to the original file ?
I will try your fix at work tomorrow.
Keep me updated.
Alternatively, until a major release happen, would you consider an opt-in fix via a flag on the collection which would avoid redirecting a missing a subversion to the original file ?
We have scheduled monthly releases, I mean we collect issues and suggestions for a month then releasing an update. This suggestion is under consideration to be discussed. Anyways you should wait for sub-version to be available.
hi @dr-dimitru , hi @green-coder
( My english is bad sry for this)
It seam that i got the same issue before for an image upload with an 'avatar version' wich i could not handle it. Because the AfterHook may take more time than ui render. Or because you try to get the subversion earlier than it made.
https://github.com/VeliovGroup/Meteor-Files/issues/387#issuecomment-318861085
The best way that i made is to Remove your encoding Code from the AfterHookUpload from File.collection.
Then when your upload endz Up:
uploadInstance.on('end', (err, myUploadFile) => {
if (err) {
console.log(err)
}
Meteor.call('m4a.encoding', myUploadFile, (err) => {
if(err) console.log(err)
.... then go back to your logic code....
}
And server side
Meteor.methods({
'm4a.encoding'(myUploadFile) {
....your encoding....
}
})
AfterUpload will make your new version in async way.
Did you try to remove the cache and refresh the page multiple times ?
In Mongodb, does your versions added properly ?
Don't know if it answer the question : / , Hope it help !
@dr-dimitru Your fix did not work. I tried:
const link = file.link(file.versions[version] ? version : 'original')
and I still get the same wrong file extension in the URL (it should be .m4a):
http://localhost:3000/cdn/storage/Files/hDpqB6xg5zWoXnQfJ/m4a/hDpqB6xg5zWoXnQfJ.webm
The content of the file is the re-encoded one, just the extension is wrong.
@green-coder post your MongoDB record after its update
And check "Network" tab to see file's mime type
Yes, don't you forget to update correctly your Files.collection when your encoding ending ? like :
https://github.com/VeliovGroup/Meteor-Files/wiki/Create-and-Manage-Subversions
and at the bottom : https://github.com/VeliovGroup/Meteor-Files/wiki/Image-Processing
const updateQuery = {$set: {[`versions.${version}`]: fileObj.versions[version]}};
Images.update(fileObj._id, updateQuery, (err) => {
if (err) {
{
"_id": "hDpqB6xg5zWoXnQfJ",
"size": 16597,
"type": "audio/webm;codecs=opus",
"name": "6AFtb6mrrMREePQTJ-BBnE5zLwoMBNjyJM4.webm",
"meta": {
"storyId": "6AFtb6mrrMREePQTJ",
"partId": "BBnE5zLwoMBNjyJM4",
"moderation": "notYet",
"creationDate": ISODate("2017-08-16T00:21:15.494Z")
},
"ext": "webm",
"extension": "webm",
"extensionWithDot": ".webm",
"mime": "audio/webm;codecs=opus",
"mime-type": "audio/webm;codecs=opus",
"userId": "JTudYQD4muBgf4hej",
"path": "/Users/Vincent/Code/ICT/story/data/hDpqB6xg5zWoXnQfJ.webm",
"versions": {
"original": {
"path": "/Users/Vincent/Code/ICT/story/data/hDpqB6xg5zWoXnQfJ.webm",
"size": 16597,
"type": "audio/webm;codecs=opus",
"extension": "webm"
},
"m4a": {
"path": "/Users/Vincent/Code/ICT/story/data/hDpqB6xg5zWoXnQfJ.m4a",
"size": 23820,
"type": "audio/x-m4a",
"extension": ".m4a"
}
},
"_downloadRoute": "/cdn/storage",
"_collectionName": "Files",
"isVideo": false,
"isAudio": true,
"isImage": false,
"isText": false,
"isJSON": false,
"isPDF": false,
"_storagePath": "/Users/Vincent/Code/ICT/story/data",
"public": false
}
HTTP/1.1 206 Partial Content
content-disposition: inline; filename="6AFtb6mrrMREePQTJ-BBnE5zLwoMBNjyJM4.webm"; filename*=UTF-8''6AFtb6mrrMREePQTJ-BBnE5zLwoMBNjyJM4.webm; charset=UTF-8
cache-control: public, max-age=31536000, s-maxage=31536000
pragma: private
trailer: expires
transfer-encoding: chunked
connection: keep-alive
content-type: audio/x-m4a
accept-ranges: bytes
access-control-allow-origin: *
content-range: bytes 0-23819/23820
date: Wed, 16 Aug 2017 00:58:34 GMT
I just noticed that have a mistake in the extension which should be 'm4a' instead of '.m4a', but fixing it does not change the problem.
Typically, if you follow the Meteor.call Logic to avoid the async stuff and waiting for UI and then do
const link = file.link('m4a');
if you're in React try to force that
const link = file.versions && file.versions.m4a && file.link('m4a')
to not take the '.webm' by default
extension which should be 'm4a' instead of '.m4a'
You're right here. But this is not a root of the issue.
Congrats! 馃 Looks like you just found a real bug here :)
Going to reproduce, and publish a fix (hope in next few days).
Should be noted what only the name (and extension) of the file is wrong, content-type and file itself (ones and zeros) is sent properly.
Meanwhile it's strange what iOS refuses to play audio/video, as it should take content-type prioritized (if served in header) over extension. Could you confirm having an issue with content-type: audio/x-m4a and misplaced extension webm on iOS?
Yes, on iPad iOS v9.3.3
Correction: The sound does play on the iPad even without the correct file extension.