Uploading .m4a files

Hi folks. Trying to get ELMO to work with audio.

Problem is m4a files are not making it.

Seems the issue is here
https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/tasks/InstanceUploaderTask.java#L306
.

All the files that are making it are listed explicitly there, but m4a is
not.

It seems that if openRosaServer were true, any file type would be
uploaded, which is probably what I want.

But I'm not sure how to make openRosaServer true. Looking at the code, it
only seems to get set to true if the server issues a valid Location: header
in response to the HEAD request. That doesn't make any sense to me. Our
server is not doing that but I don't understand why it would be necessary
to prove OpenRosaness...

Can someone shed some light please?

Thanks.

··· -- Tom Smyth

Worker-Owner, Sassafras Tech Collective
Specializing in innovative, usable tech for social change
sassafras.coop · @sassafrastech

Resident, Touchstone Cohousing
touchstonecohousing.org

Interesting.

The code should set this flag to true if the response from the HEAD request
returns with an X-OpenRosa-Version header.

https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaRequest

But instead it is set if it finds a Location header. Which is incorrect but
happens to work.

The reason for this treatment was for legacy compatibility with ODK
Aggregate 0.9.x, which did not conform to the OpenRosa standard (and in
particular, did not handle HEAD requests, so anything that did handle head
requests was effectively conforming to OpenRosa as far as our
implementations are concerned).

··· ================== The fix would change to look for the X-OpenRosa-Version header on the response and set this flag accordingly. Will flag this and try to get this change in for the next ODK Collect release.

On Thu, Mar 24, 2016 at 1:35 PM, Tom Smyth tom@sassafras.coop wrote:

Hi folks. Trying to get ELMO to work with audio.

Problem is m4a files are not making it.

Seems the issue is here
https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/tasks/InstanceUploaderTask.java#L306
.

All the files that are making it are listed explicitly there, but m4a
is not.

It seems that if openRosaServer were true, any file type would be
uploaded, which is probably what I want.

But I'm not sure how to make openRosaServer true. Looking at the code,
it only seems to get set to true if the server issues a valid Location:
header in response to the HEAD request. That doesn't make any sense to me.
Our server is not doing that but I don't understand why it would be
necessary to prove OpenRosaness...

Can someone shed some light please?

Thanks.

--
Tom Smyth

Worker-Owner, Sassafras Tech Collective
Specializing in innovative, usable tech for social change
sassafras.coop · @sassafrastech

Resident, Touchstone Cohousing
touchstonecohousing.org

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Ok glad you can confirm that I am not losing my mind here. For now I just
added in a Location header that points to the same location and that seems
to have fixed the problem.

··· On Fri, Mar 25, 2016 at 1:13 PM, Mitch Sundt wrote:

Interesting.

The code should set this flag to true if the response from the HEAD
request returns with an X-OpenRosa-Version header.

https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaRequest

But instead it is set if it finds a Location header. Which is incorrect
but happens to work.

The reason for this treatment was for legacy compatibility with ODK
Aggregate 0.9.x, which did not conform to the OpenRosa standard (and in
particular, did not handle HEAD requests, so anything that did handle head
requests was effectively conforming to OpenRosa as far as our
implementations are concerned).

==================
The fix would change to look for the X-OpenRosa-Version header on the
response and set this flag accordingly. Will flag this and try to get this
change in for the next ODK Collect release.

On Thu, Mar 24, 2016 at 1:35 PM, Tom Smyth tom@sassafras.coop wrote:

Hi folks. Trying to get ELMO to work with audio.

Problem is m4a files are not making it.

Seems the issue is here
https://github.com/opendatakit/collect/blob/master/collect_app/src/main/java/org/odk/collect/android/tasks/InstanceUploaderTask.java#L306
.

All the files that are making it are listed explicitly there, but m4a
is not.

It seems that if openRosaServer were true, any file type would be
uploaded, which is probably what I want.

But I'm not sure how to make openRosaServer true. Looking at the code,
it only seems to get set to true if the server issues a valid Location:
header in response to the HEAD request. That doesn't make any sense to me.
Our server is not doing that but I don't understand why it would be
necessary to prove OpenRosaness...

Can someone shed some light please?

Thanks.

--
Tom Smyth

Worker-Owner, Sassafras Tech Collective
Specializing in innovative, usable tech for social change
sassafras.coop · @sassafrastech

Resident, Touchstone Cohousing
touchstonecohousing.org

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Tom Smyth

Worker-Owner, Sassafras Tech Collective
Specializing in innovative, usable tech for social change
sassafras.coop · @sassafrastech

Resident, Touchstone Cohousing
touchstonecohousing.org