cordova-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ian Clelland (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CB-6359) resolveLocalFileSystemURL continues to be inconsistent, now fails specifically on Galaxy Note 3 when capturing video only
Date Thu, 27 Mar 2014 17:49:34 GMT

    [ https://issues.apache.org/jira/browse/CB-6359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13949698#comment-13949698
] 

Ian Clelland commented on CB-6359:
----------------------------------

Ralph, this looks to be a very similar issue to CB-6300; where the media-capture plugin picks
its own temporary directory for files, which may be different than the one that file wants
to use.

Since the file systems are properly sandboxed now, the File plugin won't resolve a file that
doesn't reside inside one of the registered file systems.

I'm going to update media-capture to use the same path as file uses for temporary files, which
will make the dev versions of the two plugins compatible.

In the meantime, can you try installing the {{org.apache.cordova.file-system-roots}} plugin?
That plugin registers a number of new file systems, including alternate cache directories.
It should get your app working, but I'd definitely like to know if it doesn't.

Thanks.

> resolveLocalFileSystemURL continues to be inconsistent, now fails specifically on Galaxy
Note 3 when capturing video only
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CB-6359
>                 URL: https://issues.apache.org/jira/browse/CB-6359
>             Project: Apache Cordova
>          Issue Type: Bug
>          Components: Android, Plugin File, Plugin Media Capture
>    Affects Versions: 3.4.0
>         Environment: On Mac
> Cordova info
> Current Node Version
>     v0.10.25
> Current Cordova CLI Version
>     3.4.0-0.1.0
> Testing with: Samsung Galaxy Note 3 (Android)...the device is NOT rooted.
>            Reporter: Ralph S Theart
>            Assignee: Ian Clelland
>              Labels: android, capture
>
> Ok this is a very strange bug. Some background first though. I have 10 test devices at
my house so I can test the apps I make. Of the 10 devices 8 are android. My app works across
the board on all of them flawlessly. So I already know its not something related to my set
up or my code. Out of the *10* devices one specific feature seems to fail on one specific
device (Galaxy Note 3). When you capture video and try to resolve the URI you will always
get error core 5 every single time no matter what changes you make or conditions. Here is
the code.
> {code}
> navigator.device.capture.captureVideo(function(mediaFiles){
> 	        var mediaFilePath = mediaFiles[0].fullPath;
> 	        
>                 window.resolveLocalFileSystemURL(mediaFilePath, function(){
>                        ///never gets this far
>                 }, function(error){
>                        console.log(error.code);
>                        *Always fails with error code 5*
>                 });
> 	    }, function(error){
> 			var msg = 'Messages > captureVideo():: An error occurred during video capture:
' + error.code;
> 			console.log(msg, null, 'Uh oh!');
>            });
> {code}
> For this device and this specific scenario the path returned by capture is always something
like this: *file:/storage/extSdCard/DCIM/Camera/20140327_104747.mp4* ....yes I noticed the
"file:/" and have even tried replacing it with "file:///" and it still continues to fail.
> btw ...I have a lot of devices I test with with...do you guys have these kind of facilities.
I'm more than happy to help with any testing...I built up a rigorous excel sheet full of tests
among which are all of the media type api's. I did this because resolveLocalFileSystemURL
has become a problem child for me since 3.4 I have already submitted 3 bugs 1 of which was
solved and actually made it to the 1.0.1  File-System update. The 2nd one is solved now too.
I wouldn't care if the device this was happening to was old and was on an older firmware like
4.0.3 but this is a popular device especially in our database any help would be appreciated.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message