# Connect iCouldPlay to S3-compatible storage

Language: en
Canonical: [Connect iCouldPlay to S3-compatible storage](<https://allluckly.cn/en/guides/icouldplay-s3-compatible-source-setup/>)
中文：[中文 HTML](<https://allluckly.cn/guides/icouldplay-s3-compatible-source-setup/>)
English: [English HTML](<https://allluckly.cn/en/guides/icouldplay-s3-compatible-source-setup/>)
Published: 2026-11-05T00:00:00+08:00
Modified: 2026-11-05T09:38:59+08:00
Author: Bison

Verify an S3 endpoint, bucket, region, access style and credentials with an authorized sample before checking listing and playback.

English translation of the [Chinese original](<https://allluckly.cn/guides/icouldplay-s3-compatible-source-setup/>), translated on 2026-11-05. Original publication dates, attribution, code and version notes are retained.

A storage management console and an S3 object endpoint are usually different addresses, and a website password is not an API credential. iCouldPlay 1.1.1 publicly adds S3-compatible storage. Begin with limited reading from an existing service rather than purchasing one, creating long-term keys or migrating a library. Ask its administrator for authorized read configuration and one working video sample. Without them, prepare the required field list instead of testing random online endpoints or somebody else’s keys.

## Obtain the complete authorized configuration

Collect the endpoint, bucket, region, access-key identifier, secret access key, temporary-session status and permitted object prefix. The administrator should also identify path-style or virtual-hosted-style access and the sample’s complete object key. Viewing does not require obtaining a service-wide administrator account for troubleshooting. Transfer secrets through the existing trusted method; the checklist needs only field completeness and an identity identifier. If supplied only a temporary download URL, clarify that this exercise needs source configuration rather than guessing credentials from that URL.

## Distinguish the endpoint from the management console

Choose S3 when adding a source and enter the supplied HTTP or HTTPS API base endpoint. The illustrative `https://objects.example.com` must be replaced with your trusted service. A console login page, a particular film URL or an `s3://` object identifier is not that field. The current S3 form accepts an origin consisting of scheme, host and any required port, without a service subpath, bucket or object key. A deployment requiring a subpath may not fit this entry; ask its administrator for a compatible endpoint rather than substituting the object-prefix field for a service prefix. Recheck scheme, host and necessary port. For HTTPS failure, verify the address and certificate rather than disabling validation.

## Match bucket and region independently

Enter only the actual bucket name, without scheme, slash or film name. Use the service’s documented signing region rather than assuming a default fits every compatible provider. The region participates in request signing, and a geographical label on a website may differ from the accepted configuration string. Compare bucket and region exactly without changing region and account together. Record a fixed-region requirement as specific to this source, not universal to S3. A generic test failure does not establish whether the bucket actually exists.

## Enter one complete credential set

Put the access-key identifier and secret in their respective fields; they are not a username and website password. Temporary credentials also require the session token from the same set. Do not combine yesterday’s token with today’s keys. Check for surrounding spaces, truncation and keyboard substitutions without exposing values in recordings or public screenshots. Do not invent a token for long-term credentials. For incomplete temporary credentials, obtain the full authorized set rather than bypassing it. This exercise checks existing read access, without generating new keys or broadening permissions.

## Set the access style and sample prefix

Set path-style access to the service-supported mode rather than simultaneously changing scheme and bucket by trial and error. The [AWS virtual-hosting guide](<https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html>) explains address structures; a compatible deployment’s requirements still govern. Narrow browsing to an existing sample prefix such as `practice/clips/`, without repeating the bucket name there. A browsing prefix is not an authorization policy: narrowing the interface does not restrict the credential itself. Use only an already authorized scope and verify actual object visibility afterward.

## Verify both listing and one file

Use the current connection and folder-selection flow to locate the administrator-confirmed sample before scanning a whole bucket. Compare its name, visible size and hierarchy, then play beginning and middle anchors. Listing and reading media are different requests: seeing an object does not ensure access to its contents. Conversely, one working download link does not establish bucket-list permission. Record normal listing and failed playback separately and ask about the sample’s read scope. A listed filename does not mean a complete offline copy exists on the phone.

## Change one configuration category at a time

For complete listing failure, check endpoint/access style, bucket/region, credential completeness and validity, then permitted prefix. Changing all categories together makes even a success unexplained. For one failing file, hold the connection configuration fixed and verify that object and its readability on the service. Compatible implementations, encryption requirements and object types can differ; an S3 label does not guarantee universal direct use. For help, provide field categories, service name and failure stage while concealing keys, tokens, signed URLs and private object names.

## Keep a maintainable source description

Record a service identifier, sanitized bucket/prefix description, region, access style, sample results and date, while managing credentials separately. Restore the test position and preserve objects without moving or deleting them during setup. After credential rotation, configuration changes or migration, rerun connection, listing and playback on the same sample before normal use. Distinguish saved configuration, visible items and actual playback, rather than treating one source card as acceptance of every file and device.

## Related tutorials and sources

[Check prefixes and keys](<https://allluckly.cn/en/guides/icouldplay-s3-object-prefix-identity/>), [Compare S3 access styles](<https://allluckly.cn/en/guides/icouldplay-s3-path-style-endpoint-check/>).

Checked on November 5, 2026 against the [official iCouldPlay App Store listing](<https://apps.apple.com/cn/app/id6755653178>) and [Apple public lookup](<https://itunes.apple.com/lookup?id=6755653178&country=cn>): version 1.1.1, requiring iOS / iPadOS 15.0 or later. The public 1.1.1 release notes list Kodi, OpenList / AList and S3-compatible storage, with improvements to source switching and captions after seeking. The tasks use this public scope and existing playback capabilities. Check controls in your installed version. Self-made samples, manual records and external file preparation are workflows, not newly promised automatic features. No physical-device or private-server test is claimed.