Optimal config for daddylive

[DryKillLogic]

First of all, I want to thank you for the wonderful job done on HSL-Proxy.

I'm genuinely impressed by the level of detail and expertise in your responses. It's rare to see someone contribute to open-source projects with such dedication, and frankly, you've set the bar very high for the rest of us.

On that note, I do have a question for you (hopefully an easy one):

I'm in the process of setting up the proxy on Node to stream content from daddylive, but I’m running into an issue with buffering or intermittent drops, even though the same feed works fine on the website. I noticed your webmonkey script for this, so I’m assuming you're already familiar with the site.

Here’s my current configuration (the referer and origin are being passed in the URL):

const proxy = require('@warren-bank/hls-proxy/hls-proxy/proxy')({
  is_secure: true,
  host: HOSTNAME,
  copy_req_headers: false,
  req_headers: {
    'User-Agent':
      'Mozilla/5.0 (iPhone; CPU iPhone OS 17_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 Mobile/15E148 Safari/604.1'
  },
  req_options: null,
  hooks: null,
  prefetch: true,
  cache_segments: true,
  max_segments: 30,
  cache_timeout: 60,
  cache_key: 0,
  debug_level: 3,
  acl_ip: null,
  acl_pass: null,
  http_proxy: null,
  manifest_extension: null,
  segment_extension: null
});

Thanks, Warren, I appreciate your help very much!

[warren-bank]

some notes:

---

const proxy = require('@warren-bank/hls-proxy/hls-proxy/proxy')({
  is_secure: true,
  host: HOSTNAME,
  copy_req_headers: false,
  req_headers: {
    'User-Agent': 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 Mobile/15E148 Safari/604.1'
  },
  req_options: null,
  hooks: null,
  prefetch: true,
  cache_segments: true,
  max_segments: 30,
  cache_timeout: 60,
  cache_key: 0,
  debug_level: 3,
  acl_ip: null,
  acl_pass: null,
  http_proxy: null,
  manifest_extension: null,
  segment_extension: null
});

---

hlsd --tls --port 8081 --prefetch --max-segments 30 --useragent "Mozilla/5.0 (iPhone; CPU iPhone OS 17_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 Mobile/15E148 Safari/604.1" -v 3

---

https://daddylive.watch/24-7-channels.php

no channels appear to work
=> looks like my WebMonkey userscript needs to update its list of domains

https://daddylive.watch/stream/stream-52.php

CBS
=> doesn't play, but does show a video URL

https://d2.jisdeshmaiganga.com:999/hls/do52.m3u8?md5=CV44Nd8tEJ0Kl2ql5EsTAQ&expires=1736441214

video

https://smartermuver.com/embed3.php?player=desktop&live=do52

referer

https://localhost:8081/aHR0cHM6Ly9kMi5qaXNkZXNobWFpZ2FuZ2EuY29tOjk5OS9obHMvZG81Mi5tM3U4P21kNT1DVjQ0TmQ4dEVKMEtsMnFsNUVzVEFRJmV4cGlyZXM9MTczNjQ0MTIxNHxodHRwczovL3NtYXJ0ZXJtdXZlci5jb20vZW1iZWQzLnBocD9wbGF5ZXI9ZGVza3RvcCZsaXZlPWRvNTI=.m3u8

proxied video|referer
=> 404

---

https://dlhd.so/24-7-channels.php

=> 301

https://thedaddy.to/24-7-channels.php

all channels appear to work

https://thedaddy.to/stream/stream-52.php

CBS
=> stream plays OK

https://xyzdddd.mizhls.ru/lb/premium52/index.m3u8

video

https://cookiewebplay.xyz/premiumtv/daddylivehd.php?id=52

referer

https://localhost:8081/aHR0cHM6Ly94eXpkZGRkLm1pemhscy5ydS9sYi9wcmVtaXVtNTIvaW5kZXgubTN1OHxodHRwczovL2Nvb2tpZXdlYnBsYXkueHl6L3ByZW1pdW10di9kYWRkeWxpdmVoZC5waHA/aWQ9NTI=.m3u8

proxied video|referer
=> 200

https://warren-bank.github.io/crx-webcast-reloaded/external_website/4-clappr/index.html#/watch/aHR0cHM6Ly9sb2NhbGhvc3Q6ODA4MS9hSFIwY0hNNkx5OTRlWHBrWkdSa0xtMXBlbWhzY3k1eWRTOXNZaTl3Y21WdGFYVnROVEl2YVc1a1pYZ3ViVE4xT0h4b2RIUndjem92TDJOdmIydHBaWGRsWW5Cc1lYa3VlSGw2TDNCeVpXMXBkVzEwZGk5a1lXUmtlV3hwZG1Wb1pDNXdhSEEvYVdROU5UST0ubTN1OA==

video player w/ proxied video|referer
=> no buffering, all requests hit the cache

[warren-bank]

so.. to summarize..
I wasn't sure if your issue was the server configs, or the stream..
so I separated the two and looked at each individually:

• first, I wanted to start the proxy from the command-line and diagnose any streaming/buffering issues
  • once I found the current version of the DaddyLive website with working streams.. everything worked well
• second, your code appears to configure your options in the same way as the command-line parser
  • presumably, you're also good in starting a server and configuring its middleware..
    examples of which are given in that same file

let me know if this was helpful..
or if you're still having trouble using the code directly as an embedded library.

[DryKillLogic]

Thanks @warren-bank for the quick response and for troubleshooting my request.

Your findings match my current implementation:

const referer = 'https://cookiewebplay.xyz/'
.....
const proxifyUrl = (url, referer) =>
    `${BASE_URL}/proxy/${Buffer.from(`${url}|${referer}`, 'utf-8').toString('base64')}.m3u8`;

const updateDaddyLiveUrl = (id) =>
  `https://xyzdddd.mizhls.ru/lb/${id}/index.m3u8`; // premium or bet + channel ID

I initially considered a configuration issue, but you've confirmed that everything looks correct on that front.

Next, I'm focusing on the server and/or video player. Running the server locally and accessing the feed through VLC seems more stable than when using the public server (e.g., ESPN feed) It could be that the public server is getting overloaded. However, even locally, the issue still occurs after some time—although it can run smoothly for over an hour without issues. Eventually, the server stops responding, but there’s nothing in the logs to provide any clues as to what might be causing the failure.

logs: https://gist.github.com/DryKillLogic/5755b85f0d9482eb5a75d17cb7f79b7e

Thank you!

[warren-bank]

Personally, I've never tested this server at scale..
to be completely honest, the only time that I fire it up is when I stream live sporting events
(as a safeguard against buffering issues)..
but that's only to support a single client.

That being said, I've received reports of performance issues in the past..
from people who do attempt to use the server with a large number of concurrent clients.

• high RAM
• high CPU

But I haven't done anything to simulate heavy load.. to see how resources are managed.
If there is a memory leak, I don't see any indication of it..
garbage collection seems to be working well (with pre-fetch).
Likewise, it uses nearly no CPU locally.

If you happen to dig into performance and have any suggestions..
for optimizations or even micro-optimizations,
then please don't hesitate to share your observations and ideas.

[DryKillLogic]

I reviewed those reports thoroughly after going through all the documentation, examples, and issues prior to submitting my question. So far, I haven't encountered any memory leaks.

I don't believe the issue is related to high load, as hitting a single feed from the local environment produces the same result.

After some additional troubleshooting, I believe I've narrowed down the problem. It doesn't appear to be on the proxy side, but rather with DaddyLive itself. They might be implementing a mechanism to protect the feeds—such as encryption keys, domain changes, or something similar. Even other solutions, including streamlink, failed after a few minutes, typically within an hour at most.

I will continue investigating and will update you with any new findings.

Thank you! @warren-bank

[warren-bank]

Even other solutions, including streamlink, failed after a few minutes, typically within an hour at most.

I didn't run my test long enough to encounter this behavior.
This sounds like they use a strategy to whitelist IP addresses..
where a "heart beat" request needs to be made periodically to some endpoint..
so the IP of the client remains allowed to access video files.

In the README, search for the example that uses the request_intervals hook function.
Because this is such a common protection strategy, this hook is included as a helper to easily add such "heart beat" requests.