A YouTube Content ID claim on an archived livestream can help you narrow down which video file may have triggered it. Open the claim details, note the claimed content and time range, then match that point in the stream to the relevant OBS scene and inspect its Media Source file paths.
YouTube’s claim details do not identify an OBS source by name or reveal a file path on your computer. The match is your own investigation: the claim identifies content and a segment, while your OBS scene collection and playback history help you find plausible files. Check more than one candidate if sources overlap or an asset appears in several scenes.
Open the archived stream’s claim details
This process starts with the archived video in YouTube Studio, not with a guess about which file in OBS looks suspicious. YouTube says Content ID claims on a live stream are made after the stream is completed if you choose to archive it. That is distinct from a live interruption, so first establish whether you are investigating a claim on the replay or a problem that happened while the stream was live. See YouTube’s guidance on copyright issues with live streams.
In Studio, open Content, find the affected archived stream, and check its copyright or claim details. If the list is long, use the available claim filter. Open the affected video’s details and record what Studio shows before changing anything. The interface can change, so rely on the current labels and help page rather than an old screenshot or a remembered menu location.
Write down the claimant, the content identified, any segment or time range, and the action attached to the claim. Note whether the archive is blocked, restricted in some territories, or otherwise affected, if Studio states that. A video can have different claimants for different segments, and an unfamiliar claimant is not by itself proof that a claim is wrong. YouTube explains what a Content ID claim can affect in its copyright claim overview.
Keep this information separate from what you think the OBS source was called. The claimant may identify a song, recording, or other matched material, but that label does not tell you whether it came from a Media Source, a browser source, another input, or an overlapping item in your scene. Treat it as a lead to investigate, not as a source name.
If you operate several channels or use several scene collections, confirm that you have the right archived stream and the collection used when it was broadcast. A useful record is a small table with the stream title, date, claim details and the collection you believe was active. It will help prevent you from tracing a similarly named scene from the wrong project.
Note the claimed content and timestamp
The claimed content and its time range are the two clues that make the file search manageable. Copy or write them down as displayed, including any start and end times. If Studio shows a specific track or work, preserve its spelling. Do not substitute a broad label such as “music” for a more specific identification, because you will need to compare that clue against actual audio or video in your files.
A claim can cover only a portion of a long archive. A timestamp is usually more useful than searching every file used during a day-long broadcast. It is still a clue rather than proof of which OBS item produced the material: the same audio could be mixed with another source, a playlist might have advanced, or a different scene may have been active at that time.
Make a note of how the time is presented and compare it with the replay timeline. If you are unsure whether the displayed point refers to the beginning of a segment or a different boundary, check the relevant portion on either side of it rather than treating one second as decisive. The aim is to find a window of playback to inspect, not to infer the local path from YouTube’s claim screen.
Keep the claim’s stated action in view while you investigate. A Content ID claim is not automatically a copyright strike or takedown, and the next step is not always to dispute it. You are gathering facts first: what material appears in the archive, what OBS was playing, and whether you have a valid basis and the necessary rights for that use.
Match the timestamp to stream playback
Open the archived stream and seek to the claimed time range. Listen as well as watch. A claim may concern audio that is difficult to notice under narration or other music, while a visual match may appear only briefly. If the replay is long, note what is audible and visible just before, during, and after the claimed interval. That context can show whether an asset began earlier, ended later, or continued across a scene change.
Do not assume that the file currently visible in OBS is the file that played when the stream was made. A source can be changed after a broadcast, a playlist can move to another item, and scene switching can alter what reaches the output. A YouTube replay is useful evidence of what the viewer-facing stream contained; it does not, on its own, tell you which local source supplied it.
Write a short playback log as you review: timestamp, visible scene or subject, audible material, and any transition. For example, if the claim covers a bhajan that starts just after a devotional title card changes, note the title card and the sound separately. The scene may contain several media sources, and the transition alone does not establish which one supplied the claimed recording.
If playback is unavailable, incomplete, or not clear enough to distinguish sources, mark that uncertainty rather than filling it in from memory. Check any local recording, operator notes, or playback records you kept. A clear record of uncertainty is more useful than an unsupported conclusion, especially if the same media was used in more than one scene.
The same discipline helps with scheduled or playlist-based streams. An asset’s position in a playlist does not necessarily correspond to the same timestamp every day if earlier items vary in duration or playback was interrupted. If your channel uses a recurring playlist, see how playlist scheduling affects a 24/7 music stream; for this claim, still match the actual archive and its timeline rather than relying on the intended schedule.
Identify the OBS scene collection used
Before opening source properties, identify which OBS scene collection was in use for the claimed broadcast. Scene collections hold scenes and their sources. Profiles are a separate OBS concept, associated with output settings; selecting a familiar profile does not establish that you have the collection that was live. The OBS scene collections guide describes the collection and its saved scenes.
If you keep separate collections for a devotional channel, a lofi station and a local news loop, record which one was active when the claim arose. Check the collection’s scenes against the stream’s on-screen sequence. If you do not remember, use any notes or screenshots from the session and inspect collections that plausibly fit. Avoid opening a file path from a similarly named source and assuming it belongs to the broadcast in question.
Within the likely collection, list the scenes that could have been active at the claimed time. A scene can contain nested scenes or multiple sources, so inspect relevant layers rather than just the top-level scene name. Sources may be hidden, inactive, or present for transitions; that means their existence is not proof that they contributed to the broadcast. You need to establish whether a candidate was actually visible or audible at the claimed point.
If the stream used multiple scenes, reconstruct the switch sequence from the replay and any operator notes. A source could have continued audio while a different scene was shown, depending on how the scenes and sources were configured. Conversely, a file may be present in a scene but not have played during the segment. Record these as candidate relationships, not certainties.
This is also where a concise scene map helps: note scene name, sources that might contain media, and the interval when the scene appears in the archive. If you have previously documented a setup for a lofi channel with an animated OBS scene, use that as a reminder to distinguish background visuals from audio-bearing media. Do not assume that the visual source is the source named in an audio claim.
Check Media Source Local File paths
In the relevant scene, select a likely Media Source and open its properties. OBS describes Media Sources as a way to add media files to scenes, and the properties include a Local File field. The path shown there is the direct clue to the file OBS is configured to use now. See the OBS Media Sources documentation for the source controls and properties.
Record the source name, scene, and Local File path for each plausible Media Source. Then inspect the file itself, not just its filename. A descriptive name such as morning-aarti-final.mp4 is helpful, but a renamed or copied asset may contain different material. Open or preview the candidate and compare its actual picture and sound with the claimed content and the archive interval.
The path may be absolute or may no longer resolve on the current computer. A missing file can mean a project was moved, a drive is disconnected, or the source was changed since the broadcast. It does not prove that the missing file caused the claim. Check backups or the machine used for streaming if they are available, and note when a path was observed so you do not confuse current settings with past ones.
OBS portable mode does not automatically package media files alongside a scene collection. If you copied a collection between computers, its JSON may need manual modification, or the media paths need to be common across devices. The OBS portable mode notes are relevant when paths have changed. A path that works today on another machine may differ from the one used during the claimed broadcast.
Media Source is only one possible source type. If no candidate in the scene fits, widen the search to other scenes and source types, and check whether another application or an external audio input contributed to the stream. The YouTube claim does not name an OBS source, and official documentation cannot identify your local file without your scene setup and playback history. If the channel plays playlists or changing source URLs, a source URL change in a radio stream can also make the current configuration a poor record of what played earlier.
Compare candidate files before deciding
Make a comparison table rather than choosing the first plausible filename. Include the claim’s content and time window, what the archive shows or sounds like, the OBS scene and source, the path, and what you verified in the file. Add a confidence note such as “matches audible melody; scene timing unconfirmed” rather than a percentage. This keeps observation and inference distinct.
| Evidence to compare | What to record | What it can establish |
|---|---|---|
| Claim details | Claimed content, claimant, segment and action | The material and time range YouTube associated with the claim |
| Archived stream | Audible and visible content around the segment | What reached the viewer-facing archive at that time |
| OBS scene collection | Collection, scene sequence and source state where known | Which sources were plausible in the broadcast setup |
| Local file | Path and the candidate’s actual content | Whether the candidate contains material matching the claim |
| Playback records | Notes, schedule or logs, if retained | Whether a candidate was likely playing at the relevant point |
A strong match needs more than a similar title. The file should contain the claimed material, and the timeline should make it plausible that this source supplied the segment. If two files contain the same recording, or two sources played together, you may not be able to identify one unique cause from the claim alone. Keep both candidates open until your records resolve the ambiguity.
If the file does not match, check whether another source could have contributed the content. Consider a second scene, a nested scene, an audio source not visible in the replay, or a playlist item that was not the one you expected. Compare against an original archive or local recording where available. Do not treat the absence of a matching file in the current collection as proof that YouTube made a mistake.
Once you have a supported conclusion, choose a response based on the facts and your goal. If the claim is valid and you lack a basis to use the material, you may leave it in place or consider removing or replacing the material, depending on the options Studio offers. If you replace a correctly claimed song or visual, use material whose licence covers the intended use; keep the licence and source records with the project.
Dispute only if you have a valid reason, such as the necessary rights, a copyright exception that applies, or a genuine misidentification. Giving credit, owning a copy, or choosing not to monetise does not by itself justify a dispute. YouTube’s dispute guidance explains the process and reasons; an appeal can carry further consequences, including the possibility of a removal request and strike if the claimant takes that route. Read the current official guidance before acting, and do not use a dispute as a routine way to test a theory.
If revenue is involved, check YouTube’s current explanation of how revenue is handled during disputes before choosing when to act. The process can affect held revenue and the timing of its release, so weigh that alongside your evidence and rights. The important point is not to rush into an appeal because a claim is inconvenient: make sure you understand the claim, the content, and the consequences of each available response.
Reduce uncertainty on the next broadcast
A simple broadcast log can make future investigations faster. For each session, note the date, active scene collection, major scene changes, and the files or playlist items expected to play. If you change a source path or replace an asset, record the change. These notes do not prevent claims or prove rights, but they help you reconstruct what was configured and when.
Keep media in clearly named folders and avoid reusing ambiguous filenames such as final.mp4. Include a short source or licence note alongside material you are authorised to use. If the same file appears in multiple scenes, list each use so you can check all of them against a claimed segment. For a small channel, a plain spreadsheet or text note is usually enough; consistency matters more than a complex system.
Before a long stream, verify the scene collection you intend to use and check that likely media paths resolve on the machine doing the broadcast. If a channel runs continuously, also decide who will review Studio notices and where the relevant collection notes are kept. This does not guarantee that a claim will not occur; it reduces the time spent reconstructing a past broadcast when one does.
If the main difficulty is keeping a loop running while your computer is off, separate that operational problem from claim diagnosis. StreamNeo can remove the need to keep a local computer running for an uploaded video broadcast, but it does not decide ownership, clear rights, or determine which asset caused a claim. Whatever playback arrangement you use, retain clear records of the content and permissions for the material you broadcast.
When the comparison shows that a file was used without a basis you can support, focus on replacing it with properly licensed material and preserving the new rights record. If the evidence remains ambiguous, avoid escalating the claim until you have checked the relevant scenes, paths and playback history. Keep the archive, Studio details and local notes together so you can explain your conclusion later.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does YouTube show which OBS source caused the claim?
No. YouTube’s claim details identify claimed content and a segment, not your local OBS source name or file path. You need to compare the archive with your scene collection and playback records.
Where do I find the file path in OBS?
Open the relevant scene, select a likely Media Source, and inspect its properties for Local File. Record the path and verify the file’s contents; the current path may not be the one used during an earlier stream.
Is a Content ID claim the same as a strike?
No. A Content ID claim is not automatically a takedown or copyright strike, though actions can vary by claim. Read the details in Studio and the current YouTube Help guidance before deciding what to do.
Should I dispute the claim if I own the video file?
Owning a copy of a file does not by itself give you the rights to broadcast its contents. Dispute only when you have a valid basis and the necessary rights, an applicable copyright exception, or evidence of misidentification.