방법: 업로드(고급)

소개

안정적인 에셋 업로드는 모든 C2C 통합의 핵심 기능입니다. 이 가이드에서는 까다로운 환경에서도 성능을 발휘할 수 있도록 강력하고 복원력이 뛰어나며 효율적인 업로드 시스템을 만들기 위한 고급 기술과 모범 사례를 제공합니다.

사전 요구 사항

아직 확인하지 않으셨다면, 계속하기 전에 C2C 구현: 설정 가이드를 검토해 주세요. 인증 및 권한 부여 과정에서 획득한 access_token이 필요합니다. 기본 업로드 가이드에서 사용했던 것과 동일한 테스트 에셋을 계속 사용할 것입니다.

고급 에셋 매개변수

Frame.io에서 에셋을 생성할 때 여러 고급 매개변수를 사용하여 업로드 동작을 사용자 지정할 수 있습니다. offset 매개변수는 적절한 통합을 위해 특히 중요합니다.

오프셋 - 일시 중지된 디바이스 처리

정확한 offset 값을 제공하는 것이 중요합니다. 이 매개변수는 미디어가 생성된 시점을 지정하며, 귀하의 디바이스가 공유되지 않아야 할 콘텐츠를 업로드하지 않도록 보장합니다. Frame.io에서 디바이스가 일시 중지된 경우, 사용자는 일시 중지 중에 생성된 미디어를 업로드해서는 안 된다는 것을 나타내는 것입니다. 자세한 내용은 저희의 일시 중지 기능 가이드를 참조하세요.

offset 매개변수의 추가적인 이점

offset 매개변수는 Frame.io 내에서 미디어를 구성하는 데 있어 또 다른 중요한 이점을 제공합니다. 과거에 캡처한 콘텐츠를 업로드할 때, 예를 들어 사용자가 재생 중 지난주에 촬영한 사진을 선택하는 경우 offset 매개변수는 해당 미디어가 현재 업로드 날짜가 아닌 원래 캡처된 날짜에 해당하는 폴더에 표시되도록 합니다. 이러한 시간순 정렬은 Frame.io 프로젝트 구조에서 논리적인 타임라인을 유지합니다. offset 매개변수가 없으면 과거 미디어가 오늘 업로드된 콘텐츠와 잘못 그룹화되어 편집자 및 기타 공동 작업자에게 혼란을 줄 수 있습니다. 귀하의 인터페이스를 통해 이 문제와 관련하여 사용자에게 선택권을 제공하는 것이 좋습니다. 사용자가 미디어 캡처 시점과 관계없이 모든 업로드 항목을 현재 날짜별로 정리하길 원한다면, offset 매개변수를 생략하기만 하면 됩니다. 지정하지 않을 경우 기본값인 0이 적용되기 때문입니다.

저희의 API 설계 덕분에 귀하의 디바이스가 일시 중지 상태를 직접 추적할 필요가 없습니다. 대신 파일을 업로드할 때 해당 파일이 몇 초 전에 생성되었는지 표시하기만 하면 됩니다. 저희 서버는 이를 일시 중지 기간과 비교하여 일시 중지 중에 생성된 파일의 업로드를 거부합니다.

이 기능을 시연해 보려면 C2C Connections 탭의 점 3개 메뉴에서 디바이스를 일시 중지하세요.

이제 에셋 업로드를 시도해 보세요.

$
{
>
curl -X POST https://api.frame.io/v2/devices/assets \
>
    --header 'Authorization: Bearer [access_token]' \
>
    --header 'Content-Type: application/json' \
>
    --header 'x-client-version: 2.0.0' \
>
    --data-binary @- <<'__JSON__' 
>
        {
>
            "name": "C2C_TEST_CLIP.mp4", 
>
            "filetype": "video/mp4", 
>
            "filesize": 21136250,
>
            "offset": 0
>
        }
>
__JSON__
>
} | python -m json.tool

다음과 같은 오류가 나타납니다.

1
{
2
    "code": 409,
3
    "errors": [
4
        {
5
            "code": 409,
6
            "detail": "The channel you're uploading from is currently paused.",
7
            "status": 409,
8
            "title": "Channel Paused"
9
        }
10
    ],
11
    "message": "Channel Paused"
12
}

디바이스의 일시 중지를 해제하고 동일한 요청으로 다시 시도하면 에셋이 생성됩니다.

그러나 일시 중지 기간 내에 에셋이 생성된 경우, 실제로 생성된 시점을 반영하도록 offset을 설정해야 합니다.

$
{
>
curl -X POST https://api.frame.io/v2/devices/assets \
>
    --header 'Authorization: Bearer [access_token]' \
>
    --header 'Content-Type: application/json' \
>
    --header 'x-client-version: 2.0.0' \
>
    --data-binary @- <<'__JSON__' 
>
        {
>
            "name": "C2C_TEST_CLIP.mp4", 
>
            "filetype": "video/mp4", 
>
            "filesize": 21136250,
>
            "offset": 60
>
        }
>
__JSON__
>
} | python -m json.tool

이는 Frame.io에 에셋이 60초 전(일시 중지 중)에 생성되었음을 알려주며, 이에 따라 Channel Paused 오류가 올바르게 트리거됩니다. 정확한 offset 값을 제공하는 것은 보호 대상 지식 재산, 민감한 영상물, 기타 제한된 자료를 포함하여 사용자의 의도에 반하여 민감한 콘텐츠가 업로드되는 것을 방지하는 데 필수적입니다.

특정 채널로 업로드하기

디바이스에 채널이 여러 개 있는 경우, 사용할 채널을 지정할 수 있습니다.

$
{
>
curl -X POST https://api.frame.io/v2/devices/assets \
>
    --header 'Authorization: Bearer [access_token]' \
>
    --header 'Content-Type: application/json' \
>
    --header 'x-client-version: 2.0.0' \
>
    --data-binary @- <<'__JSON__' 
>
        {
>
            "name": "C2C_TEST_CLIP.mp4", 
>
            "filetype": "video/mp4", 
>
            "filesize": 21136250,
>
            "offset": -10,
>
            "channel": 2
>
        }
>
__JSON__
>
} | python -m json.tool

지정하지 않으면 기본 채널은 0이 됩니다. 대부분의 통합에서는 이 값을 변경할 필요가 없습니다.

사용자 지정 청크 수 요청하기

기본적으로 Frame.io의 백엔드는 파일을 약 25MB 크기의 청크로 나눕니다. 네트워크 혼잡도가 높은 환경에서는 더 작은 크기의 청크를 선호할 수 있습니다. parts 매개변수를 사용하여 특정 개수의 청크를 요청할 수 있습니다.

$
{
>
curl -X POST https://api.frame.io/v2/devices/assets \
>
    --header 'Authorization: Bearer [access_token]' \
>
    --header 'Content-Type: application/json' \
>
    --header 'x-client-version: 2.0.0' \
>
    --data-binary @- <<'__JSON__'
>
        {
>
            "name": "C2C_TEST_CLIP.mp4",
>
            "filetype": "video/mp4",
>
            "filesize": 21136250,
>
            "offset": 0,
>
            "parts": 4
>
        }
>
__JSON__
>
} | python -m json.tool

응답에는 4개의 업로드 URL이 포함됩니다.

1
{
2
    ...
3
    "upload_urls": [
4
        "https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-01-path]",
5
        "https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-02-path]",
6
        "https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-03-path]",
7
        "https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-04-path]"
8
    ],
9
    ...
10
}

청크 크기는 다음과 같이 계산됩니다.

1
math.ceiling(float(21136250) / float(4))
2
# 5284063 bytes

마지막 청크는 5,284,061바이트가 됩니다(21136250 - 5284063 * 3으로 계산됨). 사용자 지정 청크 수를 요청할 때는 AWS S3 멀티파트 업로드 제한 사항을 숙지해야 합니다.

• 마지막 부분을 제외한 각 부분은 최소 5MiB(5,242,880바이트) 이상이어야 합니다.
• 부분의 개수는 10,000개를 초과할 수 없습니다.

요청이 이러한 제약 조건을 위반할 경우, 500: INTERNAL SERVER ERROR를 받게 됩니다.

{
    "code": 500,
    "errors": [
        {
            "code": 500,
            "detail": "There was a problem with your request",
            "status": 500,
            "title": "Something went wrong"
        }
    ],
    "message": "Something went wrong"
}

사용자 지정 부분 개수가 S3의 요구 사항을 충족하는지 항상 확인하세요.

효율적인 업로드 방법

C2C 디바이스는 종종 까다로운 네트워크 환경에서 작동하므로 효율성이 매우 중요합니다. 다음은 처리량을 극대화하기 위한 전략입니다.

TCP 연결 재사용/풀링

암호화된 연결을 설정하려면 상당한 협상 오버헤드가 발생합니다. 효율적인 작동을 위해 여러 요청을 할 때 TCP 연결을 재사용하세요. 대부분의 HTTP 라이브러리는 영구 연결을 유지하는 Client 또는 Session 추상화를 제공합니다.

새로운 HTTPS 연결을 위한 협상 프로세스에는 암호화 핸드셰이크와 인증서 검증이 포함됩니다. 연결을 재사용하면 각 요청마다 이 작업을 수행하는 대신 이 오버헤드를 한 번만 수행하면 됩니다.

curl을 사용한 연결 재사용을 시연해 보려면, 먼저 기본 업로드 가이드에 설명된 대로 Frame.io에 새 에셋을 생성하세요.

다음으로, 테스트를 위해 파일을 별도의 청크로 나눕니다.

$
head -c 10568125 ~/Downloads/C2C_TEST_CLIP.mp4 > "C2C_TEST_CLIP-Chunk01"
$
tail -c 10568125 ~/Downloads/C2C_TEST_CLIP.mp4 > "C2C_TEST_CLIP-Chunk02"

이제 curl의 --next 매개변수를 사용하여 단일 TCP 연결을 통해 두 청크를 모두 업로드합니다.

$
curl -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-1-path] \
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk01 \
>
--next -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-2-path] \
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk02

이를 별도의 연결 방식과 비교해 보세요.

$
curl -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-1-path] \
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk01 \
>
&& curl -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-2-path] \
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk02

테스트 결과에 따르면 연결을 재사용할 경우 일반적으로 순차 업로드 성능이 15-20% 향상됩니다.

병렬 업로드

처리량을 더욱 높이려면 여러 청크를 동시에 업로드하세요.

$
curl -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-1-path] \
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk01 \
>
& \
>
curl -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-2-path]\
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk02 \
>
&

대역폭이 충분할 경우, 병렬 업로드는 가장 느린 단일 업로드와 거의 같은 시간에 완료됩니다.

최적의 병렬 처리를 위한 일반적인 기준은 CPU 코어당 두 개의 동시 업로드를 할당하는 것입니다. 이 비율을 초과하면 리소스 경합이 발생하여 효율성이 저하될 수 있습니다.

두 접근 방식 결합하기

효율성을 극대화하려면 연결 풀링과 병렬 업로드를 결합하세요. 각각 자체적인 업로드 시퀀스에 대해 연결 풀링을 사용하는 다중 프로세스를 생성합니다.

$
curl -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[asset01-chunk01] \
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk01 \
>
--next -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[asset01-chunk02] \
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk02 \
>
& \
>
curl -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[asset02-chunk01] \
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk01 \
>
--next -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[asset02-chunk02] \
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk02 \
>
&

업로드 진행률 추적하기

통합 시 사용자에게 기본적인 진행 상태 표시를 제공해야 합니다. 청크 수준의 단위로도 무방하며, 3개의 청크로 구성된 업로드의 경우 각 청크가 완료될 때마다 진행률이 0% → 33% → 66% → 100%로 증가할 수 있습니다.

이보다 세밀한 진행률 보고는 사용 중인 HTTP 라이브러리의 기능에 따라 달라집니다. 더 상세한 진행률 추적을 구현하는 데 지침이 필요하다면 저희 팀에 문의해 주세요.

안정적인 업로드 방법

강력한 오류 처리를 구축하려면 저희의 오류 가이드를 검토하세요. 다음 섹션에서는 해당 가이드에 설명된 오류 처리 전략을 이미 구현했다고 가정합니다.

프로덕션 품질의 업로더를 구축하려면 개별 요청 오류를 처리하는 것 이상의 추가적인 고려 사항이 필요합니다.

업로드 대기열 생성

실제 시나리오에서는 디바이스가 업로드 속도보다 미디어를 더 빨리 생성하거나 연결이 장기간 끊길 수 있습니다. 대기열 시스템을 구현하면 미디어 생성 과정과 업로드 관리를 분리할 수 있습니다.

다음과 같은 이중 대기열 아키텍처를 고려해 보세요.

1. 로컬 파일을 Frame.io에 등록하기 위한 미디어 대기열
2. 개별 파일 청크를 업로드하기 위한 청크 대기열

간단한 구현 예시는 다음과 같습니다.

1
# Where we are going to queue new files.
2
FILE_QUEUE = Queue()
3
4
# Where we are going to queue new chunks.
5
CHUNK_QUEUE = Queue()
6
7
# The http session that will handle TCP 
8
# connection pooling for us.
9
HTTP_SESSION = http.Session()
10
11
def take_picture():
12
    """Snaps a picture for the user."""
13
14
    image = MY_DEVICE.capture()
15
    file_path = MY_DEVICE.write_image(image)
16
    FILE_QUEUE.add(file_path)
17
18
def task_register_assets():
19
    """
20
    Pulls snapped pictures from the FILE_QUEUE, registers
21
    with Frame.io, and adds the chunks to the CHUNK_QUEUE.
22
    """
23
    while True:
24
        # Get the latest file added to the queue and register 
25
        # a C2C Asset for it.
26
        new_file = FILE_QUEUE.get()
27
        asset = c2c.crete_asset_for_file(HTTP_SESSION, new_file)
28
29
        # Calculate the size for each chunk
30
        chunk_size = c2c.calculate_chunk_size(asset, new_file)
31
32
        # Create a message for each chunk with it's parameters 
33
        # and add it to the 
34
        # queue.
35
        chunk_start = 0
36
        for chunk_url in asset.upload_urls:
37
            message = {
38
                "file_path": new_file,
39
                "chunk_url": chunk_url,
40
                "chunk_start": chunk_start,
41
                "chunk_size": chunk_size,
42
            }
43
44
            # Put the message in the queue and 
45
            CHUNK_QUEUE.put(message)
46
            chunk_start += chunk_size
47
48
def task_upload_chunk():
49
    """Takes a chunks and uploads them."""
50
51
    while True:
52
        info = CHUNK_QUEUE.get()
53
        c2c.upload_chunk(HTTP_SESSION, info)
54
55
def launch_upload_tasks():
56
    """Lauches our Frame.io upload tasks."""
57
    # Create a list to hold all of our tasks.
58
    tasks = list()
59
60
    # Create one task for registering assets.
61
    asset_task = run_task_in_thread(task_register_assets)
62
    tasks.append(asset_task)
63
64
    # Create 2 tasks per CPU core for uploading chunks.
65
    for _ in range(0, GET_CPU_COUNT() * 2):
66
        chunk_task = run_task_in_thread(task_upload_chunk)
67
        tasks.append(chunk_task)
68
69
    # Run these tasks until shutdown
70
    run_forever(tasks)

전원 주기 전반에 걸친 영구적인 대기열 보존

메모리 내 대기열 방식은 디바이스의 전원이 켜져 있는 동안에는 잘 작동하지만, 업로드가 완료되기 전에 전원이 끊어지면 어떻게 될까요? 진정으로 복원력이 뛰어난 통합을 구축하려면, 디바이스가 재시작된 후에도 중단된 부분부터 다시 시작할 수 있도록 보장해야 합니다.

이를 위해서는 전원 주기 간에 스토리지에 대기열 상태를 영구적으로 저장해야 합니다. SQLite와 같은 내장형 데이터베이스는 이러한 기능에 훌륭한 기반을 제공합니다.

영구 대기열 구현은 다음과 같은 핵심 작업을 지원해야 합니다.

• 업로드 대기열에 새로 생성된 파일 추가
• Frame.io에서 에셋이 성공적으로 생성되는 시점 추적
• 오류로 인해 에셋 생성이 실패한 경우 기록
• 업로드 작업을 위한 파일 청크 정보 저장
• 업로드할 다음 청크 검색
• 청크를 성공적으로 업로드된 것으로 표시
• 청크 업로드 실패 기록
• 사용자에게 표시할 파일 상태 정보 제공

영구 스토리지 시스템을 사용하도록 이전 예제를 조정하는 방법은 다음과 같습니다.

1
# Our persistence layer for queuing uploads, potentially using SQLite 
2
# or another embedded database
3
C2C_UPLOAD_STORE = NewC2CUploadStore()
4
5
# HTTP session for connection pooling
6
HTTP_SESSION = http.Session()
7
8
def take_picture():
9
    """Captures an image and adds it to the upload queue."""
10
    image = MY_DEVICE.capture()
11
    file_path = MY_DEVICE.write_image(image)
12
13
    # Register the file with our persistent store
14
    C2C_UPLOAD_STORE.add_file(file_path)
15
16
def task_register_assets():
17
    """
18
    Processes files from persistent storage and registers
19
    them with Frame.io for upload.
20
    """
21
    while True:
22
        # Get the next available file from our store
23
        file_record = C2C_UPLOAD_STORE.get_file()
24
25
        try:
26
            # Register the asset with Frame.io
27
            asset = c2c.create_asset_for_file(HTTP_SESSION, file_record)
28
            chunk_size = c2c.calculate_chunk_size(asset, file_record)
29
30
            # Create entries for each chunk in our persistent store
31
            chunk_start = 0
32
            for chunk_url in asset.upload_urls:
33
                message = {
34
                    "file_path": file_record,
35
                    "chunk_url": chunk_url,
36
                    "chunk_start": chunk_start,
37
                    "chunk_size": chunk_size,
38
                }
39
                
40
                C2C_UPLOAD_STORE.new_chunk(message)
41
                chunk_start += chunk_size
42
                
43
        except BaseException as error:
44
            # Record the error in our persistent store
45
            C2C_UPLOAD_STORE.file_asset_create_error(file_record, error)
46
        else:
47
            # Mark the asset as successfully created
48
            C2C_UPLOAD_STORE.file_asset_created(file_record)
49
50
def task_upload_chunk():
51
    """Uploads individual file chunks from the persistent queue."""
52
    while True:
53
        # Get the next chunk, marking it as "in progress" to prevent 
54
        # other tasks from processing it simultaneously
55
        chunk_record = C2C_UPLOAD_STORE.get_chunk()
56
57
        try:
58
            c2c.upload_chunk(HTTP_SESSION, chunk_record)
59
        except BaseException as error:
60
            # Record the error for potential retry
61
            C2C_UPLOAD_STORE.chunk_error(chunk_record, error)
62
        else:
63
            # Mark successful completion
64
            C2C_UPLOAD_STORE.chunk_success(chunk_record)
65
66
def launch_upload_tasks():
67
    """Launches Frame.io upload processing tasks."""
68
    tasks = []
69
70
    # Asset registration task
71
    asset_task = run_task_in_thread(task_register_assets)
72
    tasks.append(asset_task)
73
74
    # Multiple parallel chunk upload tasks
75
    worker_count = GET_CPU_COUNT() * 2
76
    for _ in range(worker_count):
77
        chunk_task = run_task_in_thread(task_upload_chunk)
78
        tasks.append(chunk_task)
79
80
    # Run indefinitely
81
    run_forever(tasks)

이러한 영구 스토리지 접근 방식을 통해 통합은 전원 중단에 대한 복원력을 갖게 됩니다. 디바이스가 다시 시작되면 마지막으로 저장된 상태부터 처리를 계속합니다. 또한 이 아키텍처는 오류 추적 및 지연된 업로드 감지와 같은 고급 기능을 구현하기 위한 토대를 제공합니다.

업로드 오류 추적

강력한 업로드 시스템은 오류를 주의 깊게 추적해야 합니다. 오류 가이드의 전략을 사용하여 작업을 다시 시도한 후 영구 저장소에 이러한 실패를 기록하세요. 이를 통해 시스템은 다음을 수행할 수 있습니다.

1. 문제가 있는 업로드의 우선순위를 낮춰 전체 대기열을 차단하는 것을 방지
2. 사용자에게 정확한 상태 정보 제공
3. 지속적인 문제에 대한 관리자의 개입 허용

치명적인 오류가 발생하면 불필요한 재시도를 방지하기 위해 해당 항목을 표시하세요.

지연된 업로드 관리

무기한 지연된 업로드에 대한 보호 장치를 구현하세요. 청크 업로드 작업을 종료하고 다시 시작해야 하는 최대 기간(예: 30분)을 설정하세요. 이렇게 하면 응답 없는 작업으로 인해 모든 업로드 작업자가 차단되는 시나리오를 방지할 수 있습니다.

알림 없는 오류에서 복구

시스템 크래시, 전원 손실, 또는 프로세스 종료는 정상적인 오류 보고를 방해할 수 있습니다. 대기열에서 항목을 검색할 때 체크아웃 시간을 기록하세요. 성공 또는 실패를 보고하지 않은 상태로 항목이 적절한 임계값(예: 30분)을 초과하여 “진행 중” 상태로 유지되면, 다른 작업자가 처리할 수 있도록 사용 가능한 풀로 자동 반환하세요.

손상된 업로드 완화

“손상된” 대기열 항목은 데이터나 환경의 근본적인 문제로 인해 지속적으로 실패합니다. 이러한 항목이 계속해서 다시 대기열에 추가되면 전체 업로드 시스템이 차단될 수 있습니다. 이러한 사례를 처리하려면 다음 전략을 고려하세요.

• 여러 번 실패한 후 해당 항목의 우선순위를 낮춰 최신 콘텐츠를 계속 진행할 수 있도록 함
• 명시적 오류와 처리 시도 횟수 모두 추적
• 연결 및 인증 모범 사례를 따라 일시적인 환경 문제와 본질적인 파일 문제 구분
• 점진적 재시도 제한 구현(예: 3번의 작업 시도 각각에 대해 개별 작업을 10회 재시도하여 총 30회 시도)
• 환경 문제가 해결된 후 문제가 있는 업로드를 수동으로 재설정할 수 있는 사용자 인터페이스 제공

손상된 업로드는 다음과 같은 이유로 발생할 수 있습니다.

• I/O 오류를 일으키는 손상된 파일 데이터
• 오류 보고를 방해하는 치명적인 프로세스 실패
• 영구적인 근본 조건에 의해 트리거되어 보통 재시도 가능한 오류

시스템 재시작 후 재시도

문제가 있는 업로드를 영구적으로 포기하기 전에, 다음 시스템 재시작 후 마지막으로 한 번 더 재시도하도록 플래그를 지정하세요. 이는 메모리, 드라이버, 또는 리소스 할당과 관련된 일시적인 시스템 상태 문제로 인해 업로드가 실패하는 사례를 해결합니다. 완전히 재시작한 후에도 업로드가 계속 실패하면 더 확신을 가지고 영구적으로 문제가 있는 것으로 표시할 수 있습니다.

대기열 지우기

대기열에서 사용할 수 없는 파일을 제거해야 합니다. 미디어가 물리적으로 제거되거나 파일이 삭제되면 불필요한 오류를 방지하기 위해 업로드 대기열에서 해당 항목을 삭제하세요.

중요한 것은 새 프로젝트에 연결할 때 업로드 대기열을 지워야 한다는 점입니다. 한 프로젝트를 위해 대기열에 있는 미디어가 다른 프로젝트에 나타나서는 안 됩니다. 사용자가 디바이스를 다른 프로젝트와 페어링할 때 프로젝트가 변경되었는지 확인하고, 변경된 경우 기존 대기열을 완전히 지우세요.

다음 단계

궁금한 점이 있으면 저희 팀에 문의해 주시고, 고급 업로드 가이드로 진행하시기 바랍니다. 귀하의 통합 진행 과정을 지원할 수 있기를 기대합니다.