get progress

[amlwwalker]

any way to get the progress as the video is downloading?
For instance i want to show a progressbar/spinner...

[dzek69]

it shows a progress bar for me:

dzek@dzek-neon:~/Pobrane$ ./hlsdl_linux -u "https://some.domain/path/index.m3u8" -w 16
Downloading... 43s  1599 / 3359 [========================>--------------------------]  47.60% 00m48s

[amlwwalker]

yeah but its not exposed

[dzek69]

what do you mean "exposed" ?

[amlwwalker]

Thanks for responding!
I want to be able to access the percentage so that I can display it myself (for instance in a web app or some other way). Currently the library only outputs to stdout as you show above

What I'm after is the ability to retrieve the percentage download as a float or something so that I can then use that in my applications. Maybe even a choice between your progress bar or be able to retrieve the percentage so that I can do something with it.

I haven't looked into detail how you are calculating the percentage but if you can expose this so it can be requested from an application using your library (or a message that suggests complete) then the progress can be used by other applications.

Thank you

P.S I notice you have segments left, time left and percentage complete. These would all be very useful to be able to access from an application using your library.

[dzek69]

One clarification - it is not my project, i'm just a random person commenting here.

Anyway, can't you read the data from stdout in your app?

An example in node.js:

// index.mjs

import { spawn } from "child_process";

const url = "PUT_SUPPORTED_M3U8_LINK_HERE";

const child = spawn("./hlsdl_linux", ["-u", url]); // modify the path to the hlsdl

const extractElapsedTime = (data) => {
    const elapsedTimeMatch = data.match(/... ([^ ]+)/);
    if (!elapsedTimeMatch) {
        return null;
    }
    return elapsedTimeMatch[1];
}

const extractSegments = (data) => {
    const segmentsMatch = data.match(/(\d+) \/ (\d+)/);
    if (!segmentsMatch) {
        return {
            total: null,
            downloaded: null,
            left: null,
        }
    }
    const segmentsTotal = segmentsMatch[2];
    const segmentsDownloaded = segmentsMatch[1];
    const segmentsLeft = segmentsTotal - segmentsDownloaded;
    return {
        total: segmentsTotal,
        downloaded: segmentsDownloaded,
        left: segmentsLeft,
    }
}

const extractPercentage = (data) => {
    const percentageMatch = data.match(/([\d.]+)%/);
    console.log(data);
    if (!percentageMatch) {
        return null;
    }
    return Number(percentageMatch[1]);
}

const extractTimeLeft = (data) => {
    const percSignLocation = data.indexOf("%");
    if (percSignLocation === -1) {
        return null;
    }

    const afterPerc = data.slice(percSignLocation + 1);
    return afterPerc.trim() || null;
}


child.stdout.on("data", (data) => {
    const d = String(data).trim();
    if (!d.startsWith("Downloading")) {
        return;
    }

    const elapsedTime = extractElapsedTime(d);
    const segments = extractSegments(d);
    const percentage = extractPercentage(d);
    const timeLeft = extractTimeLeft(d);

    console.log({
        elapsedTime: elapsedTime ?? "unknown",
        segmentsDownloaded: segments.downloaded ?? "unknown",
        segmentsTotal: segments.total ?? "unknown",
        segmentsLeft: segments.left ?? "unknown",
        percentage: percentage ?? "unknown",
        timeLeft: timeLeft ?? "unknown",
    })
})

you need to wrap it up in some function (and rewrite to your app coding language), and instead of printing to console you of course should notify your web app user (idk, websockets maybe)

also i see the percentage calculated by hlsdl is basically just downloaded segments / total segments (not counted/guessed by bytes) so you probably can skip the percentage extraction and just do a little math

anyway - with current state of hlsdl it's totally possible to achieve what you need - i'm not saying having a flag that will keep outputting data in json for example wouldn't be nice :)

[amlwwalker]

Sure I can catch the output but that's not the nicest and I think this would be a nice touch to the library, I could always fork it and do this I just think it would be nice that the library supported it!
I think the major difference is you are calling this as a client/process whereas I'm using it as a library in my code but your suggestion is a possibility though for sure

[dzek69]

Development of this app looks a little bit stale, but I think @canhlinh (and me as well!) will actually appreciate it if you fork it, extend it to have an option to provide what you need and start a PR :)
so if you're only able to do it - go ahead.

[dzek69]

I think the major difference is you are calling this as a client/process whereas I'm using it as a library in my code but your suggestion is a possibility though for sure

oh yeah, i did not think about it

i actually like calling big jobs like that as a separate process:

• not everything is available natively for my environment of choice (node.js)
• it might have performance benefits (things living on their own threads, that's probably not really valid for a go app [?])
• it's sometimes much easier to abort a long-running jobs this way (i just kill the process), because author of the thing im using did not provide any way to abort the job

just few points, maybe you will actually consider doing things like i do :)

[amlwwalker]

yeah i mean an abort functionality in this pkg/library would be great too.
As you say - go has routines so its not difficult to run on a different process to the main thread in Go - so for your usecase you are doing probably the best you can...

[amlwwalker]

Development of this app looks a little bit stale, but I think @canhlinh (and me as well!) will actually appreciate it if you fork it, extend it to have an option to provide what you need and start a PR :)
so if you're only able to do it - go ahead.

I might get around to it! - I'll keep you posted

[canhlinh]

@amlwwalker @dzek69 Yes, Your request has a very narrow scope. Creating a fork and then customizing it to your specifications is preferable.

[amlwwalker]

ok happy to fork - i would say as this this is advertised in the README as being a library that can be used within Go code, exposing the progress would be something that the pkg should offer so that users have control over how progress is managed but if you don't want to i'll do it in a fork