Diagnose a visible Kodi item that will not play in iCouldPlay

Kodi titles and posters are metadata; playback still needs the corresponding media. Listing an item in iCouldPlay, playing it on Kodi and delivering it to a phone are separate results. This exercise starts after browsing succeeds, using known local media as a control before checking the failing item. It does not bypass add-on authorization, extract protected content or turn Kodi into a universal transcoding server. Preserve original files and viewing records.

Fix the identity of one failing item

Choose one permitted item whose failure repeats. Record title, year, duration and Kodi media type. For a series page, select a season and actual episode: the collection is not the episode video. Avoid alternating among same-name editions, whose failures may involve different paths. Preserve the visible iCouldPlay details and note whether failure occurs immediately, after pictures appear or during seeking. This separates browsing from delivery and avoids changing matching metadata before establishing the item’s identity.

Check the original on Kodi itself

Open the same item on the Kodi host, checking that a surviving poster does not conceal a moved or disconnected file. For external storage or NAS media, verify that source is connected and play only the permitted sample; do not broaden an entire private share. If Kodi also fails, repair its file access first. Local Kodi success establishes host access, not direct phone access to an internal disk path. Record the source category without exposing full directories or real hostnames in public reports.

Establish delivery with ordinary local media

Use an ordinary self-made video already in Kodi’s library, preferably on readable local storage. Play it in iCouldPlay and check beginning and middle anchors. If it works while the target fails, basic connectivity and at least one delivery path are established; rewriting every server field is premature. If both fail, inspect shared HTTP service and delivery conditions. A short sample is sufficient without copying a real film. Reduce add-ons, remote mounts and format complexity so the comparison explains a meaningful difference.

Understand service-mediated file delivery

Kodi may store a drive path, network share or another source identifier. Pasting that text into a phone browser does not create a video URL. The Kodi JSON-RPC overview distinguishes metadata requests from download preparation; a client still needs a supported delivery result. This explains the boundary without requiring manual API calls or copied authentication headers. Preserve an unsupported-source result in iCouldPlay. Replacing a path prefix with HTTP cannot turn an undeliverable source into an accessible stream.

Separate add-on items from ordinary files

Some items depend on a Kodi add-on, login session or special playback instruction. Playback on the television does not guarantee handoff to another player. A small text pointer is not the video; renaming it to MP4 does not change that. Establish whether the item corresponds to ordinary authorized media, then whether iCouldPlay’s current route supports it. If uncertain, return to the known local sample instead of seeking someone else’s session, token or restricted link. Record an unsupported source type rather than attributing every failure to phone decoding.

Check compatibility after delivery begins

Correct picture and sound followed by a later failure differs from receiving no media. Record the time, repeatability at the same content and changes around seeking, then follow compatibility checks with the same file. Changing both engine and source prevents attribution. If only one remote mount fails, ask the administrator to check Kodi’s access stability. If that encoding fails across sources, retain evidence for a format issue. Artwork, buffering text or a spinner alone does not prove complete delivery to the phone.

Provide separated evidence for support

Create a small table for the local control and target, with columns for Kodi playback, iCouldPlay listing and iCouldPlay playback. Mark success, failure or untested instead of one global “normal”. Include app and Kodi versions, network and failure stage while concealing credentials, private paths and signed URLs. After an administrator changes a path or service, retest those same two samples before adding others. Avoid clearing the library or history for evidence collection; preserving a recoverable state helps identify what changed.

Choose the next route within verified limits

Keep a verified delivery route for ordinary files. If the target requires another environment, state that it cannot currently be watched through this route. For ordinary files you own, an already authorized SMB or local-import route can provide an independent comparison, without assuming its progress merges with Kodi’s. Restore the test position afterward and keep originals and both results. The goal is to identify usable stages and source limits, rather than letting an accidental success after renaming, rescanning or broadening access conceal unresolved conditions.

Related tutorials and sources

Connect to Kodi, Check playback compatibility.

Checked on November 5, 2026 against the official iCouldPlay App Store listing and Apple public lookup: 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.