gramps
5ad0106502
The logs answered the question and closed off a whole branch of investigation. The long run: broadcast inserted 14:17:04.577, ffmpeg to rtmp://a.rtmp.youtube.com/live2/5f6z-... at 14:17:05.686, and ffmpeg's own muxing summary at 14:18:56.473 reads video:101229KiB audio:1419KiB muxing overhead: 0.202949% ~99MB of real video plus audio over 112s, which is what 8000+128 kb/s is supposed to produce. No socket error, no 4xx from ingest, no reconnect. And the broadcast still never left `ready`; close-out 403'd invalidTransition again. The 8s run behaved the same way, so "YouTube needed longer" is disproven — 112s is longer. So the RTMP path is provably healthy. That is the finding worth keeping: it kills the entire "the push is broken" theory, which is where this had been heading for a week. The break is between ingest being accepted and the broadcast being told to start. Which puts the binding in frame, and the app was structurally blind to it. Google documents contentDetails.boundStreamId and says enableAutoStart fires "when you start streaming video on the bound live stream" — both valid on insert, neither restricted against reusable streams. But the migration guide also says a broadcast "is not bound to any streams at the time that it's created", and the failure that produces is invisible from the RTMP side precisely because a reusable stream will happily accept bytes for an unbound broadcast. Ingest succeeding proves nothing. Hence LogBroadcastDiagnosticsAsync, riding the existing health poll rather than adding a timer. One greppable line: lifecycle status, privacy, recording, boundStreamId *compared against the stream id we are actually pushing* (BoundMatches: yes / MISMATCH / NO-BINDING / unknown), boundStreamLastUpdate- TimeMs, autoStart/Stop, liveChatId presence, the stream's own streamStatus and activeLiveChatId, and the CDN settings we declared. Deliberately self-limiting: _broadcastSeenLive latches on live/liveStarting so the diagnostic shouts only while the broadcast is stuck and goes quiet once it is healthy. A permanent per-tick log line would be noise; this is the opposite. One test, per the Good Dog rule: BroadcastBindingTests pins the matrix and specifically pins `unknown` when there is no stream id to compare against, so a missing expectation can never be misreported as a match — that is the failure that would make this diagnostic lie. Suite 387/387, 0 warnings.
34 lines
1.7 KiB
C#
34 lines
1.7 KiB
C#
using Xunit;
|
|
using ytLive.Services;
|
|
|
|
namespace ytLive.Tests;
|
|
|
|
/// <summary>
|
|
/// Broadcast-binding diagnostics (2026-10-04). Two test streams proved the RTMP push
|
|
/// is healthy — ffmpeg delivered 101,229 KiB video + 1,419 KiB audio over 112 seconds
|
|
/// with no socket error — yet the broadcast never left `ready` and close-out returned
|
|
/// 403 `invalidTransition`. Google's docs say <c>enableAutoStart</c> fires "when you
|
|
/// start streaming video on the bound live stream", so the one thing worth asserting
|
|
/// about the request we send is that we know which stream we think we are bound to.
|
|
/// </summary>
|
|
public class BroadcastBindingTests
|
|
{
|
|
/// <summary>The comparison that decides whether the broadcast is even watching the
|
|
/// feed we are pushing. A reusable stream happily accepts bytes for an unbound
|
|
/// broadcast, so ingest succeeding proves nothing on its own — a MISMATCH or
|
|
/// NO-BINDING would look identical from the RTMP side and would hang forever.
|
|
/// "unknown" is the honest answer when the app has no stream id to compare against,
|
|
/// so a missing expectation is never silently reported as a match.</summary>
|
|
[Theory]
|
|
[InlineData("stream-abc", "stream-abc", "yes")]
|
|
[InlineData("stream-abc", "stream-xyz", "MISMATCH")]
|
|
[InlineData(null, "stream-abc", "NO-BINDING")]
|
|
[InlineData("", "stream-abc", "NO-BINDING")]
|
|
[InlineData("stream-abc", null, "unknown")]
|
|
[InlineData("stream-abc", "", "unknown")]
|
|
public void BoundMatches_ComparesTheBroadcastAgainstTheStreamWePush(string? bound, string? expected, string verdict)
|
|
{
|
|
Assert.Equal(verdict, YouTubeStreamService.BoundMatches(bound, expected));
|
|
}
|
|
}
|