Closed wazerstar closed 9 months ago
I think you must have a very interesting setup at your place. For my use I have 3 TVs all on the same network pulling the playlists, and they need unique, but repeatable, client IDs. That is, each time they request the playlist, the clientID should remain the same. As such, I'll not change the current behaviour but I could add a --random-clientid
option to get a completely random UUID - for as soon as a timestamp is added, the clientID will effectively be completely random.
done
done
Thanks, okay so There's a bug
--random-client-id cannot be run but --random-clientid can
also when I try to play http://localhost:port it does not regonize anything, what is the exact url when hosting via inbuilt server?
Thanks for that, the correct options are --unique-clientid
and --random-clientid
. I incorrectly added an extra hyphen in the help ouput, and subsequently copied it to other places. I've updated the help and readme.
Thanks for that, the correct options are
--unique-clientid
and--random-clientid
. I incorrectly added an extra hyphen in the help ouput, and subsequently copied it to other places. I've updated the help and readme.
Hey I tested again
while it accepts --random-clientid I checked and my client id is still "00000000-0000-0000-0000-000000000000"
I ran it like this
node ./index.js --mapping dk --exclude-channels "How to use Pluto TV" --chno 92 --random-clientid --x-tvg-url "https://path.com"
I guess you could allow us to generate a random id without running server too for each time we pull a request?
It works with while running as server.
--unique-clientid
and --random-clientid
are only used in web server mode (when --port
is provided) for it generates a new (unique or random) UUID as the m3u8 is requested. The m3u8 continues to contain the clientID configured.
I assume that unique-client-id will generate the caller ip as unique-client-id, if you have something like caddy as reserve proxy, it will always assume its the server calling the the shot so the unique-client-id will always be server ip, to overcome this we could add a %timestamp% in raw milliseconds or whatever the variable would be after ip to make it even more unique and avoid the reverseproxies getting back the original issue.
What do you think?