Cannot detect multipart INSV recordings — camera returns only the original filename (URGENT)

[mushtaqcontineu]

Description

When the camera records a long video, it always stores it internally as one single INSV file, for example:

FILENAME_100.insv

However, when the camera is later connected to a PC, the PC-side filesystem automatically splits this single INSV into multiple parts, such as:

FILENAME_101.insv
FILENAME_102.insv

This is expected behavior on the PC.

❗ Problem

After the PC splits the file, the camera increments its internal file counter.

So the next recording in the camera becomes:

FILENAME_103.insv

even though 101 and 102 never existed inside the camera.

Now the issue:

➤ When stopping a recording, the BLE API returns only the internal camera filename:
100.insv

But the app cannot determine:

Whether FILENAME_100.insv is a normal single file

Or whether FILENAME_100.insv will later be split into multiple files (101.insv, 102.insv, etc.)

Or how many output files will be generated

Or what the final part numbers will be

There is no BLE / API flag that indicates whether the recorded video is large enough to undergo multipart splitting when connected to PC.

This makes it impossible for apps to report correct file metadata.

Impact (Major)

Our app only receives and reports the raw filename.
Actual upload and processing happens externally on web servers.

Because we do not know whether a file will split:

We cannot determine the correct set of output filenames

The backend incorrectly assumes a single file

File grouping and indexing becomes impossible

Our metadata system becomes inconsistent

The final file delivered by users is unpredictable

The lack of this information breaks our workflow.

Expected Behavior

The camera should provide some indicator via BLE or API:

Whether the recorded file is expected to be multipart when exported

OR the estimated number of parts

OR the estimated total size

OR a flag: "willSplitOnPC": true/false

OR a stable recording ID independent of filename

Actual Behavior

BLE returns only:

fileName: "FILENAME_100.insv"

With no metadata or flags telling us:

That FILENAME_100.insv will actually become FILENAME_101.insv + FILENAME_102.insv on PC

That the next real filename on the camera will be 103.insv even though 101/102 never existed in camera storage

This causes filename mismatches and incorrect upload mapping.

Requested Fix (Urgent)

Please provide any of the following:

A flag that indicates whether the recorded file is large enough to be split on PC

The final export part count (expectedSegments: n)

A unified recording ID (e.g., "recId": "...")

A BLE callback/event including actual data size

A predictable mapping rule for how large files turn into 101, 102, 103…

Even minimal metadata would resolve this issue.

Why This Needs Immediate Attention

BLE is the only interface available during recording

The app cannot predict future filenames generated by the PC

Backend upload API depends on accurate filenames

Users deliver incomplete/inaccurate file sets without knowing

This breaks production workflows for long-recording scenarios

This is a critical missing piece for any app integrating Insta360 cameras.

[Double-Insta360]

Yes When the time of video more than 30 minutes，the video will split into two files.This information might be helpful; you might be able to use it to perform some actions in the app's background.

[mushtaqcontineu]

Thanks For this.
But some files gets split in 3 files, can you help letting us know what is the max split size and duration for each?
for 30 mins cross it goes to 2 files, at what duration it goes into 3, 4 ....

Also the Filename returned by camera BLE api is different what camera have itself.
e.g if i record big video, its name is FILENAME_100.insv in camera but in response it is FILENAME_101.insv which does not match at all. I report 101 to backend and when video is uploaded it has 100 in last, file name mismatch

[Double-Insta360]

If a segmented video recording exceeds 30 minutes, it will be further segmented, resulting in three files, and so on.

After recording exceeds 30 minutes, the returned URL path becomes inaccurate. This is a known issue, and we apologize, as we are unlikely to be able to fix it in the short term.

[mushtaqcontineu]

Could you please share any internal documentation or technical notes explaining this sequence-ID behavior and how multipart splits are handled internally?
Also, are there any recommended approaches or existing fixes for detecting when a recording will produce multiple files after PC export?

Thank you.

[Double-Insta360]

The principle is that the end-of-file data of the video file is stored in a buffer and is only saved when recording stops to prevent data loss over time. Therefore, recording automatically stops after 30 minutes and then restarts, resulting in the filenames incrementing. What are your use cases? What's the longest you need to record? Perhaps you could calculate the current filename increment by recording the time?

[mushtaqcontineu]

Thanks For this.
is there any way to get duration of current video file?

since if we start recording and timer on app, it never syncs with actual duration, there is difference bw app timer and camera duration in seconds which can cause issues in long run.

[mushtaqcontineu]

Also can we use this code for X4 model, we are using X4 models for our app.

Capturing Status Notification
Note: For the X3 and earlier camera models, videos exceeding 30 minutes will be split into two recordings. The camera will automatically stop recording the first segment and begin recording the second segment.

InstaCameraManager.getInstance().setCaptureStatusListener(new ICaptureStatusListener() {
    @Override
    public void onCaptureCountChanged(int captureCount) {
        // Number of shots captured for modes such as interval shooting and starry sky mode,
    }

    @Override
    public void onCaptureStarting() {
        // Capture is about to start
    }

    @Override
    public void onCaptureStopping() {
        // Capture is about to stop
    }
    
    @Override
    public void onCaptureTimeChanged(long captureTime) {
       // Recording time callback, applicable only in video recording mode
    }

    @Override
    public void onCaptureWorking() {
        // Capturing in progress
    }

    @Override
    public void onCaptureFinish(String[] filePaths) {
        // Capture finished, returns the file paths of the final products
    }
    
    @Override
    public void onCaptureError(int errorCode) {
        // capturing failed error reference capturing failed error code
    }
});