For a 24/7 Gurbani YouTube stream, use YouTube Giving’s Donate button when the money is for an eligible nonprofit and your channel can access the feature. Otherwise, put a legitimate fundraiser destination in the stream description and use a brief on-screen cue to point viewers there.
A phone can control OBS from the same local network through a WebSocket client, but that is a way to manage the encoder, not a donation system. Keep OBS running on the encoding computer, secure its WebSocket password, and do not assume that phone control across different networks is safe or supported.
Choose the destination before adding a link
First decide who is meant to receive the money. A donation to an eligible nonprofit, a contribution to a gurdwara, and paid support for the channel are not interchangeable. The wording and destination should match the arrangement you can actually substantiate.
For an eligible nonprofit fundraiser, check whether YouTube Giving is available to your channel in YouTube Studio. YouTube’s setup guidance lists general criteria including YPP membership, supported location, at least 10,000 subscribers, and a channel not designated Made for Kids. Access and supported locations can change, so treat the current Studio fundraiser flow and Google for Nonprofits’ setup guidance as the deciding references rather than an old checklist.
If the fundraiser is accepted, attach it to the relevant video or scheduled live stream in Studio. YouTube says the Donate button appears on the watch page or in live chat after the fundraiser start date. Its YouTube Giving donation guidance explains how donations through that feature go to eligible nonprofits and that YouTube covers transaction fees. Nonprofit donations are non-refundable, so make the recipient clear before viewers contribute.
If the money supports the channel or its operator, do not label it a charitable donation unless there is a separate, accurately described charitable arrangement. YouTube distinguishes paid fan-funding features from nonprofit donations: Super Chat and Super Stickers are paid interaction tools, not donation tools under YouTube policy. Its Commerce Products monetisation policy is the place to check the current distinction.
For a nonprofit campaign that cannot use YouTube Giving, choose an external fundraiser that the intended viewers can access. YouTube’s fundraising guidance names services such as GoFundMe and JustGiving as examples for eligible nonprofit campaigns; that is not an endorsement of any particular campaign. If an institution such as a gurdwara is involved, confirm the recipient details and preferred wording with the organisation. YouTube’s rules do not settle community-specific practices.
Put the destination where viewers can find it
For a continuous stream, keep the fundraiser destination in the stream’s associated description. Add a short cue to the on-screen layout, for example: “Support [named recipient]’s langar programme — details in the description.” The text is a signpost, not a clickable overlay; viewers may need to open the description on their device.
Avoid filling the screen with a permanent appeal. A calm, occasional cue can tell a viewer what the link is for without competing with the Gurbani, translation, or other information that matters to the stream. State whether the destination is external and name the recipient and purpose. Do not claim that funds reach a nonprofit unless you can support that claim.
Check the link as a viewer, not only in the editor. Open the intended stream on a phone and a desktop, and check the description and any fundraiser button. YouTube’s live-stream guidance explains that support for clickable links varies by format: horizontal live streams allow clickable links in chat and the channel description, while vertical live feeds do not offer the same link support. The live-stream format comparison is worth checking if you intend to use a vertical feed.
Do not paste a raw URL into live chat. YouTube says URLs are not allowed in live-chat messages. A repeated chat message is not a workaround: viewers may not see it, and it can run against the platform’s rules. Direct them to the description or the native Donate button instead.
YouTube recommends end screens for linking to an external fundraiser in eligible video formats. That may help with a replay or another video placement, but an end screen is not a persistent element on a 24/7 broadcast. Do not rely on it as the only route for someone who joins mid-stream. See YouTube’s fundraising guidance for the formats and options it documents.
Keep OBS running on the encoding computer
If your stream uses an OBS scene for the Gurbani video, a donation cue, or both, OBS must remain open on the computer that is encoding and sending the broadcast. Closing the application, sleeping the computer, or losing its connection can interrupt the output. A phone used as a remote control does not take over the encoding work; it sends commands to OBS while that computer continues running.
A simple layout might have a main scene with the Gurbani video and a small, readable line directing viewers to the description. If you also need a holding screen, prepare it as a separate scene and test the transition before the stream begins. The practical considerations in setting up OBS for a nonstop Hindi prayer stream are relevant to keeping scenes and sources ready for a long broadcast.
Before you leave the stream unattended, test the entire chain: OBS output, YouTube’s live preview, the description link, and the wording shown on screen. Keep the text large enough for a phone, but do not put a full web address over the devotional image if viewers can use the description. A typed URL is easy to misread and may be difficult to use from a television.
If the encoding computer is at a fixed location, make power and sleep settings part of the plan. Prevent automatic sleep while streaming, ensure the computer has adequate cooling and power, and know how you will reach it if OBS stops. A stream that depends on someone being nearby to press a button is different from one that can recover without intervention. The Windows unattended-stream setup discussion covers the broader issue of not leaving a desktop session as a single point of failure.
Connect a phone WebSocket client on the local network
OBS WebSocket lets a compatible client send commands to OBS. For local phone control, the phone and encoding computer need to be on the same local network, such as the same home or office Wi-Fi. The phone is a control surface: it may let you switch scenes or trigger a prepared action, but it does not create the stream or keep OBS running when the computer is off.
The basic sequence is to enable the WebSocket server in OBS, confirm its port and authentication settings, then enter the encoding computer’s local network address and the configured port in the phone client. The exact labels and navigation depend on the OBS version and the client, so use the current OBS documentation and the client’s instructions rather than copying settings from an unrelated version. Do not guess an address from outside the local network; identify the encoder’s current local address on the network it is using.
Keep the first test modest. Connect while both devices are on the same Wi-Fi, verify that the client reaches OBS, and trigger a harmless scene change while watching the stream preview. Then disconnect and reconnect to see whether the control path comes back after a brief Wi-Fi interruption. If the phone switches to mobile data or a guest network isolated from other devices, it may no longer reach OBS. That is a network boundary, not proof that OBS has failed.
Use a distinct scene or button for the donation cue rather than building an elaborate control panel that is hard to understand under pressure. Give each scene a clear name, and make sure the normal broadcast scene remains available. A phone can be useful when the encoder is in another room, but a small screen and touch controls also make accidental taps easier. Keep a local keyboard or another recovery route available.
This approach is for control on a trusted local network. It does not change where the fundraiser link lives: keep that in the description or use YouTube Giving where available. Do not use a phone-control button as a substitute for checking the viewer-facing destination on YouTube.
Protect OBS WebSocket with a password
Enable authentication and use a password that is not reused for your Wi-Fi, email, YouTube account, or fundraiser account. Enter it only into a client you trust. Anyone who can connect to an exposed control interface may be able to change the OBS output, so treat the password as access to the broadcast controls rather than as a cosmetic setting.
Keep the WebSocket listener limited to the local network. Do not enable access from the public internet as a shortcut to control OBS while travelling. Avoid router port forwarding for this purpose, and do not share the password in a screenshot or a group chat. If you have shared it accidentally, change it and update the authorised client.
A local-network password is one layer, not the whole security plan. Use a trusted Wi-Fi network, keep the encoding computer and OBS updated, and remove client access you no longer need. If the phone is lost or replaced, review its saved credentials and rotate the OBS password if there is any doubt about who can use them.
Separate donation credentials from stream controls. OBS does not need access to a bank account or fundraiser login merely to show a text cue or change scenes. Keep the destination link in the description and use the creator’s normal account security for editing it. That separation reduces the consequences of a control mistake: a scene change should not grant access to donation handling.
Understand the limits of cross-network control
A phone on the same Wi-Fi can often reach the encoder’s local address; a phone across the internet is a different case. The public guidance reviewed for this article does not establish a safe, supported way to expose OBS WebSocket for remote-network access. Do not infer that opening a router port or weakening authentication is an appropriate solution.
When you are away from the site, use a method you have separately assessed and supported for your own network and devices, or arrange for a trusted person on location to check the computer. If you cannot establish a secure control path, accept that the phone will not change OBS scenes from a different network. It is better to have a clear boundary than to leave a broadcast control endpoint exposed in the hope that a password alone is sufficient.
Remote monitoring and remote control are also different tasks. A status page may tell you whether a stream appears live, but it does not necessarily let you fix OBS. Likewise, a phone client that works at home does not prove it will work over mobile data. For the distinction between observing and managing an always-on stream, see how to monitor an OBS stream remotely; assess any remote-access method on its own merits rather than treating a monitoring guide as permission to expose WebSocket.
If scene control from outside the premises is essential, document who is allowed to act, what access method is in use, and how to revoke it. Test recovery without changing the live output. Do not experiment with network exposure during a live broadcast, and do not assume that a feature mentioned in a forum post is a supported security design.
Plan for archives and streams over 12 hours
A continuous broadcast and its replay archive are not the same thing. Do not promise that YouTube will preserve a complete archive for a stream lasting more than 12 hours, and do not build a donation plan that depends on viewers being able to rewind a long stream. YouTube’s current guidance should be checked before you decide what replay access to promise.
Similarly, do not promise DVR availability on a long stream. Viewers’ ability to seek backwards can depend on the stream and YouTube’s handling of it. If a viewer asks where a prayer or programme segment can be found later, point them to a separately prepared recording when you have one, rather than claiming that the live player will retain every moment.
If you want a durable record, plan a local recording or create separate shorter uploads where appropriate. A local recording consumes disk space, so storage needs to be monitored and older files handled deliberately. The practical trade-off is that a recording can give you a source for clips or a later upload, but it adds a second job to manage while the live broadcast runs.
For an external fundraiser, keep the description destination current even if the live archive is unavailable or incomplete. A viewer who arrives later may still see the live page or a replay; the explanation should not imply a complete archive or a guaranteed rewind. Make a note of the stream’s start time and any planned handover so you can explain accurately what viewers can and cannot replay.
Prepare a local recording and failure plan
A failure plan should answer three questions before you go live: what happens if OBS closes, what happens if the internet drops, and what happens if the encoder’s disk fills. Decide who can restart the stream, how they can verify that it is live again, and what the on-screen message should say if the programme is temporarily unavailable. Keep the donation cue factual during an outage; do not leave viewers with an appeal that suggests the broadcast is continuing when it is not.
If local recording is useful, test it separately before relying on it. Confirm that the selected recording path is on the intended drive, that there is room for a long session, and that the file opens after a short test. Do not assume a drive will have space just because a previous stream fit. The guidance on avoiding a disk-limit failure for a continuous stream describes why recording and storage need active attention, even where your setup differs from its example.
Write down a short recovery sequence beside the encoder. It might include checking power and network, looking at OBS’s status, confirming YouTube’s preview, and restoring the intended scene. A phone client can help with a scene change when the local connection is available, but it cannot restore a failed internet connection or restart a computer that has powered off.
For unattended operation, test a failure while someone is present. Simulate a brief connection interruption or restart OBS before the planned broadcast, then confirm which parts recover and which require manual action. Do not rely on an untested automatic restart setting as your only plan. If a volunteer or staff member may need to step in, make sure they know which scene to select and where the legitimate fundraiser destination is documented.
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
Can I put a donation URL in YouTube live chat?
No. YouTube’s live-stream help says URLs are not allowed in live-chat messages. Put the destination in the associated description, or attach a YouTube Giving fundraiser if your channel and campaign qualify.
Can I use Super Chat as a charity donation?
Do not describe it as a charitable donation unless you have a separate arrangement that supports that description. YouTube treats Super Chat and Super Stickers as fan-funding features, and its policy says fan-funding features are not crowdfunding or donation tools. Explain plainly who receives any channel support and how it is used.
Can my phone control OBS when I am away from the local network?
The local-network method described here does not cover a safe, supported cross-network setup. Do not expose OBS WebSocket to the public internet by opening a router port or removing authentication. If remote operation matters, assess a separately supported and secured method rather than assuming the local phone client will work over mobile data.
Will YouTube keep the full archive or DVR for a stream longer than 12 hours?
Do not promise a complete archive or DVR access for a long stream. Check YouTube’s current guidance and plan a separate recording if you need a copy, with enough disk space and a process for verifying the resulting file.