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

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

0.2.8 is the latest released version of cordova-plugin-media-capture. File is 
at 1.0.1 (but there are some fixes in the dev branch), and file-system-roots is 
on 0.2.0-dev (the only published version)

Does your device have an SD card installed? That will (currently) affect the 
location of temporary files; I'm wondering if that's the chief difference 
between the Galaxy Note and your other 9 devices.

One other thing to try, if you still have file-system-roots installed, is to 
put this into your config.xml file:

{code}
<preference name="AndroidExtraFilesystems" 
value="files,files-external,documents,sdcard,cache,cache-external,root" />
{code}

That will also cause it to install the "root" filesystem into your app, which 
will let the File plugin access all of the files on the device (subject to 
actual filesystem permissions, of course).

> 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 have 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)

Reply via email to