[In progress] [Feature Request] Add "Cine.Ar" Steaming Site Support

[ElCho]

Hello, would you please add support to download freely available streaming content over such site? As far as I know, content isn't not protected/encrypted, but is one of those sites whose streamed content is delivered via a lot of little chunks of video parts (.TS files). Some programs like IDM, are currently able to download said video "chunks", but it seems a playlist or something else would be needed to download the whole file at once.

Free registration is needed in order to play the content. I could provide you an account's credentials, in case you need it.

Example links:

**External links are only visible to Support Staff****External links are only visible to Support Staff**
**External links are only visible to Support Staff****External links are only visible to Support Staff**
**External links are only visible to Support Staff****External links are only visible to Support Staff**

Thanks.

[Jiaz]

@ElCho: Have you tested this method, https://support.jdownloader.org/Know...aming-websites

[Jiaz]

Originally Posted by ElCho

As far as I know, content isn't not protected/encrypted

Can you open developer tools and switch to network tab and filter for m3u8, then refresh the website and then copy url to clipboard and see if JDownloader can handle it. In doubt, just send the m3u8 file(s) to support@jdownloader.org and we can check.
But I highly doubt that those streams are not protected.

[ElCho]

Originally Posted by Jiaz

@ElCho: Have you tested this method, **External links are only visible to Support Staff**...

I have tried it, but it only detects a short video file, which acts as a common "introduction logo" for all the reproduced videos; it has this link:

**External links are only visible to Support Staff****External links are only visible to Support Staff**

Originally Posted by Jiaz

Can you open developer tools and switch to network tab and filter for m3u8, then refresh the website and then copy url to clipboard and see if JDownloader can handle it. In doubt, just send the m3u8 file(s) to support@jdownloader.org and we can check.
But I highly doubt that those streams are not protected.

I did it, but no "m3u8" links are detected. Chunks themselves are of the "XHR" type in the developer tools. With links like these:

**External links are only visible to Support Staff****External links are only visible to Support Staff**

**External links are only visible to Support Staff****External links are only visible to Support Staff**

**External links are only visible to Support Staff****External links are only visible to Support Staff**

The video files are unprotected, since I have downloaded some of the chunks and they can be played just normally.

Thanks.

[Jiaz]

@ElCho: Thanks for the feedback. Please share your logins with us, support@jdownloader.org and we can check it.
What country/location are you from? so we can use correct vpn for testing

[ElCho]

@Jiaz

You can use the next "spare" login:

LOGINS_REMOVED_BY__MODERATOR_PSPZOCKERSCENE

And you won't need to use a VPN, it's free to all. Just in case, I already checked it, and it worked with a VPN from a Germany location.

By the way, what I'm trying to download is "stored" content, not "live" streams.

[pspzockerscene]

I've removed the logins from your post.
Please do not post any login credentials publicly, not even test credentials.

I'll analyze it and answer here shortly.

[pspzockerscene]

Using generic methods this will not be possible with JDownloader.
Also they're hiding their usually named "master.m3u8" URL so common browser addons won't find it.
However once you got that URL you can download it e.g. using the open source tool "yt-dlp".

Instructions:

1. Open a new tab in your browser and open the developer tools and navigate to the "Network" tab.
2. Now open a video and start playing (wait until the 2 second preroll video is over and the real clip starts).
3. Enter "convert.php" in the "filter" field in the developer tools (top left field).
You should get exactly one result.
4. Copy that long URL. You can download it using yt-dlp or FFmpeg via commandline.
Out in the wild you might also be able to find user interfaces for the tools I've mentioned.

-psp-

[Jiaz]

@pspzockerscene: is it split video/audio? or just different url scheme? generic m3u8 handling could be updated that way, eg m3u8 protocol prefix

[ElCho]

Hello, thanks for your help. I was able to download a few streams so far, but I would like to know if the process
could be further improved somehow, by means of JD2's use. How I downloaded the streams so far:

Example stream with a "correct/usable" playlist

**External links are only visible to Support Staff****External links are only visible to Support Staff**

1- I followed the steps you mentioned previously, till I got the proper playlist's link.

2- I used an online "base64" website to decode the pertinent part of the next link:

**External links are only visible to Support Staff****External links are only visible to Support Staff**

3- I copied the decoded link to JD2, it detected all the different stream qualities from the playlist
(240p, 270p, 360p, 360p, 480p, 600p):

**External links are only visible to Support Staff****External links are only visible to Support Staff**

and I downloaded the best available one (600p - 1600k).

Since JD2 was able to detect the playlist's links once I copied the decoded "base64" link, I'm wondering why
it isn't being able to decode it by itself? I mean, doing the "base64" decoding of the above link, so there is
no need to use the third-party website.

Example stream with an "incorrect/unusable" playlist

**External links are only visible to Support Staff****External links are only visible to Support Staff**

1- Idem.

2- I used an online "base64" website to decode the pertinent part of the next link:

**External links are only visible to Support Staff****External links are only visible to Support Staff**

For some unknown reason, the above link was being decoded incorrectly, like this:

**External links are only visible to Support Staff**\^[\ۋ›L܎ۏY^Rš‘ٚSْ”Ԟ’LSšRŽK™^Rž˜Œ՞VL•ZSِZTԍQUQZSϚVLԞYTэ’PҐ•ZR\ѐҌXUӚSِZSš“LSӐL–‘՚“QӍŒ•]֑]Қ’›Uš’Z]ڒ[U�ђM’QL“š–M•MSU]SULϒL“ϚX̛њ›ړš˜ݒPҝוԔVVš•MZ•ԚSِZSš“LSӐL–•՛֔LL•]ӕš“‘š“Z“›[Œ˜ђ
˜[P͛Œ•Y›ѕ“ѓ^X�˜TMTS˜Ѝ͐ZŒٕ[UӖ[P›œSMUœžS”
֛]šŒYT݌ڑ��”V��‘™ʖSSŒ\ŽML‘ݐٓؐŽX’T]‘RXL�NTҒ]‘
ڛѓKLX”ԌM’Ӓœ܌�›؎›•\Wˌ“Œ™”ZQ””R�͜WԓӒ\Q‘�NV[ލқ،XVŒ̔ҐVY͖ST̑U˜דšԞ
Ց\ҘٍQU”œ“ڐ]“ZL”RґʕњY‘ڐ\NSS•MŒΜΘV“ז›™�Ք[ݘԔ�RQQM^šYY̜ەNM�όޚԕʌZ–R”̜٘\“ڎS“�P

Then, I compared it with the previously decoded link, added a "2" character, so it looked like this instead:

aHR0cHM6Ly81NjRkYzI3OTdlNzBiLnN0cmVhbWxvY2submV0L29kZW9uL19kZWZpbnN0Xy9zbWlsOm9tYy9JTkNBQS8Z2ny9tZWRpYS5zbWlsLw==&p=cGxheWxpc3QubTN1OD90PWV5SmhiR2NpT2lKU1V6STFOaUo5LmV5SnpiM1Z5WTJVaU9pQWlTVTVEU VVFaUxDQWlZM1J5ZVNJNklDSkJVaUlzSUNKMWFXUWlPaUFpTmpNMU9UQTJaR1ZqTUdRNE4yVXdaREF3TWpKbE1USmpJaXdnSW1WN GNDSTZJREUyTmpZNE5UUTVNVFV1TVRBME9ESTJMQ0FpYzJsa0lqb2dOamNzSUNKd2FXUlFZWEpoYlU1aGJXVWlPaUFpTmpNMU9UQ TJaV1ZsT1dRME0yVXdOVFpqTkRGak1qTmxJbjAuY0lIVDZhbGlDM24yVWZsd0NWTHBLTExJeWI2YVE1UU5jSDc2QWozY1VtV05Zb GlCbnFNNVRqcHhCeEVMQlA3Wm12ajFlUGNzMFAzakZ2dlFaQkJEZmctWFBlTG1MMDB6MXBmOTR5MGpHc0NjTGtlQjliSEFRdkVJY TBkVjU5U0pJdkQ3bW9MTHhVLTFiU1gxNHgySHBrUUpzbzJ2bEtiOGQyblVxXzQyTjJmUHVoSUZSUUp3NnAxX1hPVElwZUZGQThFW WxndzdQb2gxYVhEUjM1U0dBWWc2WU1TNURFVmNhTDh2a094N1ZFc1BjZjVFVlJyT2dBdk1pMlFLTUcwVDNMaWZHbUFxOU1OVTYzN 3M3YVpPYVpuZndZUHBFb3ljT1AyNUlETURBNXppZWc4c3RUUTk0ZDI3RDBzd2tSVExjMDFqWUpTY2M4cXJPZzhhTk50VE1B

And since it still wasn't completely correct:

**External links are only visible to Support Staff**

I added the missing "67/media.smil/" part of the link after "INCAA" (I took the "67" from the movie's page title),
so once decoded, it looked like this:

**External links are only visible to Support Staff****External links are only visible to Support Staff**

3- I copied the corrected link to JD2, it detected all the different stream qualities from the playlist
(240p, 270p, 360p, 360p, 480p, 600p, 720p). And I downloaded the best available one (720p - 2350k).

Finally, I noticed that with some movie links, once the decoded "base64" playlist's link is pasted, despite
JD2 detects the streams (sometimes it misses a few qualities, which are detected only after a few retries),
it lists them incorrectly, with duplicated quality values. Example:

**External links are only visible to Support Staff****External links are only visible to Support Staff**

That movie has "5" different quality streams, namely 240p, 270p, 360p, 360p, 480p and 600p; but JD2 lists them like this:

Spoiler:

While the correct quality of the streams is this:

Spoiler:

[pspzockerscene]

@ElCho
Good findings.
Using that decoded URL which then also contains the ".m3u8" part makes JD handle that URL using our generic m3u8 parser.

Originally Posted by ElCho

I'm wondering why
it isn't being able to decode it by itself? I mean, doing the "base64" decoding of the above link, so there is
no need to use the third-party website.

I'll try to explain:
Indeed our generic parser and even pre-parser does decrypt base64 Strings and look for URL(s) inside them but there is simply no generic logic that can be applied to put those two strings together.
First as a generic example to undermine my statement, here is a base64 encoded string that contains http...google.com/:

aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8

Now copy that and go into the Linkgrabber -> Add Links -> "Add links dialog" opens
You will see that JD will auto decrypt this base64 String and show the "google.com" URL there.

Now why doesn't that also work with your example URL?
Even though the link is not valid for streaming anymore, as example it's still fine.
I will highlight important parts:

player.cine.ar/odeon/convert.php?b=aHR0cHM6Ly81NjRkYzI3OTdlNzBiLnN0cmVhbWxvY2submV0L29kZW9uL19kZWZpbnN0Xy9zbWlsOm9tYy9JTkNBQS82Ny9tZWRpYS5zbWlsLw==&p=cGxheWxpc3QubTN1OD90PWV5SmhiR2NpT2lKU1V6STFOaUo5LmV5SnpiM1Z5WTJVaU9pQWlTVTVEUVVFaUxDQWlZM1J5ZVNJNklDSkJVaUlzSUNKMWFXUWlPaUFpTmpNMU9UQTJaR1ZqTUdRNE4yVXdaREF3TWpKbE1USmpJaXdnSW1WNGNDSTZJREUyTmpZNE5UUTVNVFV1TVRBME9ESTJMQ0FpYzJsa0lqb2dOamNzSUNKd2FXUlFZWEpoYlU1aGJXVWlPaUFpTmpNMU9UQTJaV1ZsT1dRME0yVXdOVFpqTkRGak1qTmxJbjAuY0lIVDZhbGlDM24yVWZsd0NWTHBLTExJeWI2YVE1UU5jSDc2QWozY1VtV05ZbGlCbnFNNVRqcHhCeEVMQlA3Wm12ajFlUGNzMFAzakZ2dlFaQkJEZmctWFBlTG1MMDB6MXBmOTR5MGpHc0NjTGtlQjliSEFRdkVJYTBkVjU5U0pJdkQ3bW9MTHhVLTFiU1gxNHgySHBrUUpzbzJ2bEtiOGQyblVxXzQyTjJmUHVoSUZSUUp3NnAxX1hPVElwZUZGQThFWWxndzdQb2gxYVhEUjM1U0dBWWc2WU1TNURFVmNhTDh2a094N1ZFc1BjZjVFVlJyT2dBdk1pMlFLTUcwVDNMaWZHbUFxOU1OVTYzN3M3YVpPYVpuZndZUHBFb3ljT1AyNUlETURBNXppZWc4c3RUUTk0ZDI3RDBzd2tSVExjMDFqWUpTY2M4cXJPZzhhTk50VE1B

As we can see that URL contains two separate base64 encoded Strings that need to be decrypted and merged:
b=...
--->

564dc2797e70b.streamlock.net/odeon/_definst_/smil:omc/INCAA/67/media.smil/

p=...
-->

playlist.m3u8?t=eyJhbGciOiJSUzI1NiJ9.eyJzb3VyY2UiOiAiSU5DQUEiLCAiY3RyeSI6ICJBUiIsICJ1aWQiOiAiNjM1OTA2ZGVjMGQ4N2UwZDAwMjJlMTJjIiwgImV4cCI6IDE2NjY4NTQ5MTUuMTA0ODI2LCAic2lkIjogNjcsICJwaWRQYXJhbU5hbWUiOiAiNjM1OTA2ZWVlOWQ0M2UwNTZjNDFjMjNlIn0.cIHT6aliC3n2UflwCVLpKLLIyb6aQ5QNcH76Aj3cUmWNYliBnqM5TjpxBxELBP7Zmvj1ePcs0P3jFvvQZBBDfg-XPeLmL00z1pf94y0jGsCcLkeB9bHAQvEIa0dV59SJIvD7moLLxU-1bSX14x2HpkQJso2vlKb8d2nUq_42N2fPuhIFRQJw6p1_XOTIpeFFA8EYlgw7Poh1aXDR35SGAYg6YMS5DEVcaL8vkOx7VEsPcf5EVRrOgAvMi2QKMG0T3LifGmAq9MNU637s7aZOaZnfwYPpEoycOP25IDMDA5zieg8stTQ94d27D0swkRTLc01jYJScc8qrOg8aNNtTMA

Decoded b + p will reveal the final URL that we want:

http...564dc2797e70b.streamlock.net/odeon/_definst_/smil:omc/INCAA/67/media.smil/playlist.m3u8?t=eyJhbGciOiJSUzI1NiJ9.eyJzb3VyY2UiOiAiSU5DQUEiLCAiY3RyeSI6ICJBUiIsICJ1aWQiOiAiNjM1OTA2ZGVjMGQ4N2UwZDAwMjJlMTJjIiwgImV4cCI6IDE2NjY4NTQ5MTUuMTA0ODI2LCAic2lkIjogNjcsICJwaWRQYXJhbU5hbWUiOiAiNjM1OTA2ZWVlOWQ0M2UwNTZjNDFjMjNlIn0.cIHT6aliC3n2UflwCVLpKLLIyb6aQ5QNcH76Aj3cUmWNYliBnqM5TjpxBxELBP7Zmvj1ePcs0P3jFvvQZBBDfg-XPeLmL00z1pf94y0jGsCcLkeB9bHAQvEIa0dV59SJIvD7moLLxU-1bSX14x2HpkQJso2vlKb8d2nUq_42N2fPuhIFRQJw6p1_XOTIpeFFA8EYlgw7Poh1aXDR35SGAYg6YMS5DEVcaL8vkOx7VEsPcf5EVRrOgAvMi2QKMG0T3LifGmAq9MNU637s7aZOaZnfwYPpEoycOP25IDMDA5zieg8stTQ94d27D0swkRTLc01jYJScc8qrOg8aNNtTMA

There is no way to JD to know this in beforehand.
Also when trying to simply add that "convert.php" link via "Add links dialog" you will notice that JD does in fact show the decrypted "b" part.
Now this is simply because JD does decrypt all base64 Strings and look for URLs -> The content of parameter "b" is an URL but it can't be used without the "p" part.

Originally Posted by ElCho

That movie has "5" different quality streams, namely 240p, 270p, 360p, 360p, 480p and 600p; but JD2 lists them like this:

Looks like a possible bug.
Please provide example URLs that can be used to reproduce this issue.

Originally Posted by ElCho

I would like to know if the process
could be further improved somehow, by means of JD2's use.

For now:
If you want to use JD:
You could use some kind of script that does exactly what you've already found out to build those .m3u8 URLs or as explained
Without JD:
Use 3rd party tools like yt-dlp or FFmpeg so you can download the "convert.php" URL without the need to modify it.

With JD possibly in the future:
I've created a ticket which is about adding a feature to add the ability to our deep-parser to auto recognize HLS content even if the source URL does not contain ".m3u8".
This would take away the decrypt part you did by hand so you'd simply have to find- and add the "convert.php" link to JD.
Ticket:


EDIT

Originally Posted by ElCho

For some unknown reason, the above link was being decoded incorrectly, like this:
...
Then, I compared it with the previously decoded link, added a "2" character, so it looked like this instead:

You shouldn't need to do that.
Instead of some webtool, I recommend using a powerful text editors like the open source software "Notepad++".
Notepad++ can also crypt/decrypt base64 Strings: Simply highlight the relevant String -> Rightclick -> Plugin commands -> Base64 Decode/Encode

[ElCho]

@pspzockerscene

Looks like a possible bug.
Please provide example URLs that can be used to reproduce this issue.

It seems the issue only occurs with certain movie links only, since most will be detected fine.
Besides that one I already provided, here I leave you a few more:

5 streams, JD2 detects only 4, with one dupe (270p):

**External links are only visible to Support Staff**...

5 streams, JD2 detects 5, with two dupes (270p/480p):

**External links are only visible to Support Staff**...

5 streams, JD2 detects 5, with two dupes (270p/480p):

**External links are only visible to Support Staff**...

You shouldn't need to do that.
Instead of some webtool, I recommend using a powerful text editors like the open source software "Notepad++".
Notepad++ can also crypt/decrypt base64 Strings: Simply highlight the relevant String -> Rightclick -> Plugin commands -> Base64 Decode/Encode

I see, but the thing is, there is no problems at all with the decoding tool, but with some specific links themselves. For some reason, that kind of links will not be decoded correctly at the first attempt, but only after deleting some additional characters. I don't know exactly why that happens with certain links, while others get decoded fine straightforwardly (after deleting just the "convert.php" part).

I will keep looking for a way of automatizing the links parsing with one tool like those you mentioned before, thanks.

[pspzockerscene]

Originally Posted by ElCho

It seems the issue only occurs with certain movie links only, since most will be detected fine.
...

I'm sorry but due to a rare forum bug the URLs you've included in your post got lost.
Please either try to post them again or put them into a .txt file and attach that to your next post.
Thanks in advance.

Originally Posted by ElCho

I will keep looking for a way of automatizing the links parsing with one tool like those you mentioned before, thanks.

Good luck!
I have to say that Cine.ar didn't do a lot to "break" common tools but certainly enough to make it a little bit more complicated for beginners to download their content.

[ElCho]

It takes a lot of time to find the problematic links, and it happened again with this post. Luckily enough, I had noted the links' codes this time. It seems using the "code" function will preserve them. Otherwise you can use any movie link, but with the specific codes I noted to the right.

5 streams, JD2 detects only 4, with one dupe (270p):

I couldn't find the link again.

5 streams, JD2 detects 5, with two dupes (270p/480p): (13)

**External links are only visible to Support Staff**

5 streams, JD2 detects 5, with two dupes (270p/480p): (46)

**External links are only visible to Support Staff**

5 streams, JD2 detects 5, with two dupes (270p/480p): (19)

**External links are only visible to Support Staff**

I gave them just one attempt, but if I remember correctly, the erratic behavior could make
the missing qualities from the above links get detected, after more than one try, although
"dupes" will keep being detected nonetheless.

I have to say that Cine.ar didn't do a lot to "break" common tools but certainly enough to make it a little bit more complicated for beginners to download their content.

As you said, I think they have no intention to "protect" their content at all, but to avoid making it that easy how to anyone with a very popular download tool like "IDM" could download the movies with just one click.

By the way, I bet you already saw the message the web developer left into the console (in big red letters):

(app.js:2580) ¿Qué pretende usted de mi? Sacá la mano de acá!!

That means something like "What do you want from me? Get yours hands out of here!!"

[pspzockerscene]

Originally Posted by ElCho

It takes a lot of time to find the problematic links, and it happened again with this post.

Sorry for that.

Originally Posted by ElCho

5 streams, JD2 detects 5, with two dupes (270p/480p): (19)

This is the only link that worked for me in browser.
All others are broken?
Either way I was able to reproduce the issue.
I haven't looked deeper into it so my guess is that it is indeed the same resolution but with different bitrates(?)
If that wass the case we should include the bitrate in the filenames if during the crawl process, we can find any resolution twice.

I've created a ticket for now:

Originally Posted by ElCho

As you said, I think they have no intention to "protect" their content at all, but to avoid making it that easy how to anyone with a very popular download tool like "IDM" could download the movies with just one click.

Agree.

Originally Posted by ElCho

That means something like "What do you want from me? Get yours hands out of here!!"

:)

[pspzockerscene]

Update:
It looks to be like I thought:
Both of the downloaded files have a video resolution of 360*270 so technically the filenames are correct and those files are not dupes.
They got different video bandwidths though.

Once we find the time we'll update the parser to include the bitrate in the filenames whenever the same resolution exists multiple times but for now you can only see the difference by looking at the filesize in JDownloader.
EDIT

Yes I know those streams are labled differently in the .m3u8 file but the real video resolution appears to be the same.
That label though is nothing else than a string and is currently not used for the filenames.

[ElCho]

This is the only link that worked for me in browser.
All others are broken?

The links work fine here. The one I posted before with snapshots (177), has the same issue. But as you
said, despite what the playlist information shows, it seems they have the same resolution, but with a
different bitrate. So, I guess in those cases were JD2 shows them the same way as informed in the playlist,
must be because there are no "resolution" duplicate videos involved.

Having said that, there isstill the issue about specific links not being detected sometimes, although that seems to happen rarely, and trying one more time seems to be enough to make the missing link finally appears.

[pspzockerscene]

Originally Posted by ElCho

Having said that, there isstill the issue about specific links not being detected sometimes, although that seems to happen rarely, and trying one more time seems to be enough to make the missing link finally appears.

Please provide log- and example URLs for this case.

I've put some notes into said tickets.
Improving those filenames won't be too easy except if we either always include the bandwith in the filenames.

We'll find something but we could as well leave it like that because as said resolutions are the same and filenames do already differ at this moment though it would be nice to be able to see this situation more easily when simply looking into the linkgrabber in JDownloader.
We're open for suggestins.

[ElCho]

Please provide log- and example URLs for this case.

I will keep testing, and post the link/s here, in case I find one of those cases.

Improving those filenames won't be too easy except if we either always include the bandwith in the filenames.

It's alright, at first I thought JD2 was missing to detect some bigger resolution files (600p, for example), but it seems it isn't, so for the cases of videos with the same resolution but a different bitrate, I think it would be enough to look for their sizes, if needed. I don't care for that, since I will always go for the bigger available one.

Thanks.

[pspzockerscene]

On the way of adding that "simple" setting to add the bandwidth to filenames, we've refactored quite some stuff in our HLS crawler resulting in a significant crawler speed improvement.
Here is a quick overview of what has changed:

• fixed: Sometimes the chosen file-extension might have been wrong
• new:
• Bandwidth value is automatically included for video items where no resolution is given and/or if you enable setting under Settings -> Plugins -> m3u8
• A lot of DownloadLink properties extracted from the m3u8 files and via FFmpeg are now available to be used in Packagizer. These include: height, width, hlsBandwidth, hlsBandwidthAverage, bitrate, framerate, ffmpeg_codec_type, ffmpeg_codec_name, m3u8_codecs, m3u8_name, duration_estimated_millis
• Added setting for "Crawler speed mode" which is now by default much faster then so far

Bitte auf das nächste CORE-Update warten!

Please wait for the next CORE-Update!

Wartest du auf einen angekündigten Bugfix oder ein neues Feature?
Updates werden nicht immer sofort bereitgestellt!
Bitte lies unser Update FAQ! | Please read our Update FAQ!
---
Are you waiting for recently announced changes to get released?
Updates to not necessarily get released immediately!
Bitte lies unser Update FAQ! | Please read our Update FAQ!

-psp-

[ElCho]

Excellent, I will keep testing it and keep you informed in case something interesting shows up.

Thanks.

[ElCho]

Originally Posted by pspzockerscene

Please provide log- and example URLs for this case.

I've put some notes into said tickets.
Improving those filenames won't be too easy except if we either always include the bandwith in the filenames.

We'll find something but we could as well leave it like that because as said resolutions are the same and filenames do already differ at this moment though it would be nice to be able to see this situation more easily when simply looking into the linkgrabber in JDownloader.
We're open for suggestins.

Hi, to give you an example of the aforementioned situation, I have just tried with one movie and it showed up:

**External links are only visible to Support Staff**

I decoded its link like this:

**External links are only visible to Support Staff**

And right after letting JD2's clipboard observer gets the dl links, I get only "4" of "5" video qualities: 270p, 360p, 480p
and 600p. Then, after enabling/disabling the clipboard observer (with the original dl link still in the clipboard), I get all
the previously mentioned video qualities, besides the one who was initially missing: "240p".

07.11.22 22.15.19 <--> 10.11.22 20.36.00 jdlog://2201311370661/

The links from the initial attempt starts like this:

chunklist_w1534686124

while those from the second attempt, like this:

chunklist_w1029971639

By the way, is there a way you can make JD2 replaces the gibberish from dl links, and takes the
movies' titles out of the pages' titles? I mean, for example with this particular movie, getting a filename like this:

La muerte camina en la lluvia (600p_aac).mp4

Thanks.

[pspzockerscene]

Originally Posted by ElCho

And right after letting JD2's clipboard observer gets the dl links, I get only "4" of "5" video qualities: 270p, 360p, 480p
and 600p. Then, after enabling/disabling the clipboard observer (with the original dl link still in the clipboard), I get all
the previously mentioned video qualities, besides the one who was initially missing: "240p".

We've changed so many things that I'm not going to investigate this until we've released the next set of updates.
Please either wait for the update and test again or test in our developer build:
https://support.jdownloader.org/Know...up-ide-eclipse

Originally Posted by ElCho

By the way, is there a way you can make JD2 replaces the gibberish from dl links, and takes the
movies' titles out of the pages' titles? I mean, for example with this particular movie, getting a filename like this:

In this case it's not so eas because:
- The source-URL does not contain any title/filename-hint in this case
- When adding the .m3u8 URL there is no way for JD to have any of the "play.cine.ar" html in context

The best way would be to have something which can grab the title in context, put the title into the .m3u8 URL with an anchor and from there on, work with a Packagizer rule similar to this one:
https://support.jdownloader.org/Know...ame-via-anchor

This case is especially hard because the website html itself doesn't even contain any info as everything is loaded via an API.
E.g. the popular title tag doesn't contain any useful information:

<title ng-bind-template="{{::app}} - {{ Page.title() }}">Cine.ar Play</title>

Looking into the requests, the title-information can be found here:
play.cine.ar/api/v1.7/INCAA/prod/...
and here:
player.cine.ar/odeon/?i=..&p=..&s=INCAA&t=...

[ElCho]

Originally Posted by pspzockerscene

We've changed so many things that I'm not going to investigate this until we've released the next set of updates.
Please either wait for the update and test again or test in our developer build:
**External links are only visible to Support Staff**...

That's not a problem to me, I just mentioned it in case it could be useful to you, whenever you might try
to find the cause of the issue.

Originally Posted by pspzockerscene

The best way would be to have something which can grab the title in context, put the title into the .m3u8 URL with an anchor and from there on, work with a Packagizer rule similar to this one:
**External links are only visible to Support Staff**...

This case is especially hard because the website html itself doesn't even contain any info as everything is loaded via an API.
E.g. the popular title tag doesn't contain any useful information:

<title ng-bind-template="{{::app}} - {{ Page.title() }}">Cine.ar Play</title>

Looking into the requests, the title-information can be found here:
play.cine.ar/api/v1.7/INCAA/prod/...
and here:
player.cine.ar/odeon/?i=..&p=..&s=INCAA&t=...

I see, but just out of pure ignorance, I'm wondering if JD2 wouldn't be able to "emulate" a browser's
behavior, so provided it gets a base movies' link like this:

**External links are only visible to Support Staff**

it manages to get the download links, resembling the generic behavior that's needed to start playing the movies,
and then start snooping into the obtained data, in order to get the download links. I know it might seem like an easy task, but looking at how the "IDM's" monitoring module does it, it's basically that; it even gets the movies' filenames almost perfectly (like this: "CINE.AR PLAY - Reproduciendo- La muerte camina en la lluvia.ts"). The only thing it lacks is doing a proper process of the playlist, so it can join all the chunks together, and offer single download links.

[pspzockerscene]

Originally Posted by ElCho

I'm wondering if JD2 wouldn't be able to "emulate" a browser's
behavior, so provided it gets a base movies' link like this:

No and that is currently not planned.
It was initially planned to add similar functionality like "Video DownloadHelper" into our myjdownloader addon but if you ask me, I doubt it's ever gonna happen.

Originally Posted by ElCho

I know it might seem like an easy task, but looking at how the "IDM's" monitoring module does it, it's basically that; it even gets the movies' filenames almost perfectly (like this: "CINE.AR PLAY - Reproduciendo- La muerte camina en la lluvia.ts").

Sure it can do that as it waits for the browser to load/render everything and then starts to extract that information.
I'm sorry but at this stage we simply do not have the needed tools/software-features to provide such a functionality.
You will need to continue to work with other browser addons in such cases.

There is another open source browser extension which might be able to help you to do this task a bit easier:
github.com/venukbh/http-tracker
With some script magic you could probably extract the site title and send everything to JDownloader to set "proper" filenames.

Originally Posted by ElCho

The only thing it lacks is doing a proper process of the playlist, so it can join all the chunks together, and offer single download links.

JD can't do that either.
Our "magic" is using FFmpeg for that

[ElCho]

Alright, I will keep downloading the streams as I'm doing it now, and it isn't really
a problem at all but I had to ask, since I think, whenever possible, getting things
well done in an automatic way, will be the best in most cases. Thanks.

[pspzockerscene]

No worries I was just trying to provide more input.
What's also theoretically possible is to create a custom Greasemonkey script which fetches the filename, decrypts the link and sends all the relevant info to JD whenever a play.cine.ar link is accessed in your browser.
You might even be able to skip the need to start playing the video with such a script.

Unfortunately I won't be able to provide any further help as I'm really not into JS.

[pspzockerscene]

CORE-Updates have been released!
All announced bugfixes and features are live!
Please update your JDownloader and report any issues you find asap.
If this thread gets marked as "[Solved]" by our forum staff you can still post in it and we will read- and reply to it!

CORE-Updates wurden released!
Alle angekündigten Bugfixes/Features sind nun verfügbar!
Bitte JDownloader updaten und eventuelle Bugs schnellstmöglich an uns melden.
Falls dieser Thread vom Team als "[Erledigt]" markiert wird, kannst du weiterhin darin antworten und wir lesen/beantworten auch solche Threads!

-psp-

[pspzockerscene]

*
This means that the mentioned new settings for our HLS crawler are now available under Settings -> Plugins -> m3u8

[ElCho]

I will try it.

Thanks.