how to start at "live" on a Youtube livestream?

[Fchen48]

Hi,

I tried to get the stream of a Youtube livestream with this line of code:

stream = yt("https://www.youtube.com/watch?v=QHV9lnZuFaY", { range: {starts: 999999}});
const dispatcher = connection.playStream(stream);

Regardless of what I will enter in the starts parameter, the stream will start at beginning or 4h earlier if the stream is longer than 4 hours online.
Is there a way to start streaming at the current live position?

[fent]

The range and begin options are not currently supported for live streams. Will have to do some investigating.

[FireController1847]

@fent I can confirm that this issue still exists. Is there anything I can do to help? Would be awesome if we could get this fairly soon! ^-^

[braxton]

@fent Can confirm as well. This feature would be great! ^-^

[FireController1847]

@fent I've been poking around the internals of m3u8stream, miniget, and this module, and I think I've noticed something about YouTube livestreams:

When you request for the Miniget, it will send all of the data from previous up to now at once (if said livestream is an "archived livestream"). This will make m3u8stream go through EVERY SINGLE part of the response from the beginning to the end until requesting the information again. The issue is, when it requests this information again, it is then requesting all the way back up to the archived again, meaning that after said 4 hours is finished, it will jump back 4 hours into the past.

My solution that I have been unable to achieve so far is to take the miniget request and only read the last response from it, and accept a custom option in m3u8stream module called 'ytdl', and when set to true it will request ignore all the extra data from the miniget response, and only revieve the latest buffer.

You can see what I am talking about when you go into m3u8 stream and adding this in the requestPlaylist function:

    var req = miniget(playlistURL, requestOptions);
    req.on('error', onError);
    // log the data to see what it's recieving
    req.on('data', d => {
      console.log(d);
    });
    var parser = req.pipe(new m3u8());
    parser.on('tag', function(tagName) {

It will log once, instead of constantly, as it's logging the entire archived data. This archieved data is being queued up (via your custom queue system), meaning that this "chunk" of the stream will last 4 hours (the maximum YouTube archive time). The only time it will log again after this request is when the 4 hours has ended, and it will request another 4 hours, therefore jumping back in time.

I haven't sat for 4 hours and waited to see if this is true, but this is what seems to be the case from looking at all the data. Hope to hear back soon. If you don't understand anything I just said I'm willing to explain some more.

[fent]

Oh! I see what you mean. I didn't realize live streams contained only the last 4 hours. I've checked a few and it looks like for ones that have been up for a very long time, they only have the last x time, likely 4 hours like you said but I didn't check.

And the ones that were not up for that long, the playlist file contains the same contents, and starts at the same segment every time it's requested.

So now that we know playlist files contain everything up to now. Then as you did, we can choose to play the last item in the playlist, or we can choose to play from a segment inbetween. With this, we can enable begin to be specified, since the playlist gives the exact segment lengths. However, there is no information about byte lengths, so range still cannot be used.

We'd also have to decide how to specify playing the latest item in the playlist, or playing the video truly live. One idea is to let begin be the string now. And if begin is a negative number, then the video would begin playing at now + [that negative number]. What do you think?

[FireController1847]

I'm not exactly sure about other people, but I've livestreamed myself once or twice on YouTube and it's only let me archive up to four hours. Of course, after the stream ends, it will then re-upload the video for like 11 hours or however long it was, but while it was live afaik it only goes back 4 hours.

I've left my bot running for quite a while recently, and it actually seems that it requests for a new buffer every 30-45 minutes (but I'm not exactly sure, as I forgot to measure time lol). I still believe that it contains everything up to "live", though, as when I used the Postman app on chrome it gave me a list over 5000 lines long.

I believe that instead of having to specify whether it be live, it should be live by default, and adding a begin option will override the default. Of course, we could always use begin: "now", it'd just be set to now by default. It sounds like a great idea.

For going back in time, that also sounds like a great idea. When hovering over a YouTube livestream, you can see it says "-3h20m10s" or something like that, so a negative number sounds great. I'm going to continue testing and see if I can whip something up that will work.

Edit: Testing wise, I'm now logging the date of a new response from the buffer so we can find out how many are actually included in a request.

Edit 2: With my testing, I ended up getting stuck at the point where I'm not exactly sure how to only get the last item in the list. That's why I ended up coming here to let you know of my findings. I've stopped testing for now.

[PainteR]

Is there any progress on this issue?

[FireController1847]

All I know is my PR got closed previously because he said he was going to work on it next chance he got. So I'm not sure.