Open jriker1 opened 3 years ago
In the future, please remember to format the log properly
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['--ap-mso', 'Comcast_SSO', '--ap-username', 'PRIVATE', '--ap-password', 'PRIVATE', 'https://cbs.com/shows/seal-team/video/a4Af8ptKlr5gthauHnde5C9JdeJcNnWa/seal-team-god-of-war-forever-war/', '--verbose']
[debug] Encodings: locale cp1252, fs utf-8, out utf-8, pref cp1252
[debug] youtube-dl version 2020.12.02
[debug] Python version 3.9.0 (CPython) - Windows-10-10.0.19041-SP0
[debug] exe versions: ffmpeg 4.3.1-2020-10-01-full_build-www.gyan.dev, phantomjs 2.1.1
[debug] Proxy map: {}
[CBS] a4Af8ptKlr5gthauHnde5C9JdeJcNnWa: Downloading XML
ERROR: Could not find XML element title; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see https://yt-dl.org/update on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
File "c:\users\jriker\appdata\local\programs\python\python39\lib\site-packages\youtube_dl\YoutubeDL.py", line 803, in wrapper
return func(self, *args, **kwargs)
File "c:\users\jriker\appdata\local\programs\python\python39\lib\site-packages\youtube_dl\YoutubeDL.py", line 824, in __extract_info
ie_result = ie.extract(url)
File "c:\users\jriker\appdata\local\programs\python\python39\lib\site-packages\youtube_dl\extractor\common.py", line 532, in extract
ie_result = self._real_extract(url)
File "c:\users\jriker\appdata\local\programs\python\python39\lib\site-packages\youtube_dl\extractor\cbs.py", line 112, in _real_extract
return self._extract_video_info(content_id)
File "c:\users\jriker\appdata\local\programs\python\python39\lib\site-packages\youtube_dl\extractor\cbs.py", line 62, in _extract_video_info
title = xpath_text(video_data, 'videoTitle', 'title', True)
File "c:\users\jriker\appdata\local\programs\python\python39\lib\site-packages\youtube_dl\utils.py", line 1910, in xpath_text
n = xpath_element(node, xpath, name, fatal=fatal, default=default)
File "c:\users\jriker\appdata\local\programs\python\python39\lib\site-packages\youtube_dl\utils.py", line 1903, in xpath_element
raise ExtractorError('Could not find XML element %s' % name)
youtube_dl.utils.ExtractorError: Could not find XML element title; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see https://yt-dl.org/update on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
@jriker1: Unfortunately, CBS is yet another media portal which has shifted (for newly made available VOD) to Google's Widevine DRM, for stream protection... 💢
Using a whitelisted US IP address and loading your linked episode in a browser, https://cbs.com/shows/seal-team/video/a4Af8ptKlr5gthauHnde5C9JdeJcNnWa/seal-team-god-of-war-forever-war/ ... one finds - via URL sniffing - that the playlist API URI is:
https://link.theplatform.com/s/dJ5BDC/ZnDazI1Etrz8?format=SMIL&manifest=m3u&Tracking=true&mbr=true
(requires a US IP); this request returns ONLY URIs to cenc MPEG-DASH MPDs (aka playlist manifests), where cenc = Common Encryption
, IOW pure DRM...
<video src="https://vod-gcs-cedexis.cbsaavideo.com/intl_vms/2020/11/20/1822084675943/383378_cenc_dash/stream.mpd" system-bitrate="1000" height="1440" width="1280"/>
... and when you load that .mpd you can clearly see:
<?xml version="1.0" encoding="UTF-8"?>
<!--Generated with https://github.com/google/shaka-packager version 562040e000-release-->
<MPD xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:cenc="urn:mpeg:cenc:2013" xmlns:mspr="urn:microsoft:playready" xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" profiles="urn:mpeg:dash:profile:isoff-live:2011" minBufferTime="PT2S" type="static" mediaPresentationDuration="PT5118.822265625S">
<Period id="0">
<AdaptationSet id="0" contentType="audio" lang="DD+" segmentAlignment="true">
<ContentProtection value="cenc" schemeIdUri="urn:mpeg:dash:mp4protection:2011" cenc:default_KID="f6809f4e-2080-4047-a3bc-adaf30a885b6"/>
<ContentProtection schemeIdUri="urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
<cenc:pssh>AAAAVnBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAADYIARIQ9oCfTiCAQEejvK2vMKiFtiIgYTRBZjhwdEtscjVndGhhdUhuZGU1QzlKZGVKY05uV2E=</cenc:pssh>
</ContentProtection>
<ContentProtection value="MSPR 2.0" schemeIdUri="urn:uuid:9a04f079-9840-4286-ab92-e65be0885f95">
<cenc:pssh>AAADqHBzc2gAAAAAmgTweZhAQoarkuZb4IhflQAAA4iIAwAAAQABAH4DPABXAFIATQBIAEUAQQBEAEUAUgAgAHgAbQBsAG4AcwA9ACIAaAB0AHQAcAA6AC8ALwBzAGMAaABlAG0AYQBzAC4AbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQAvAEQAUgBNAC8AMgAwADAANwAvADAAMwAvAFAAbABhAHkAUgBlAGEAZAB5AEgAZQBhAGQAZQByACIAIAB2AGUAcgBzAGkAbwBuAD0AIgA0AC4AMAAuADAALgAwACIAPgA8AEQAQQBUAEEAPgA8AFAAUgBPAFQARQBDAFQASQBOAEYATwA+ADwASwBFAFkATABFAE4APgAxADYAPAAvAEsARQBZAEwARQBOAD4APABBAEwARwBJAEQAPgBBAEUAUwBDAFQAUgA8AC8AQQBMAEcASQBEAD4APAAvAFAAUgBPAFQARQBDAFQASQBOAEYATwA+ADwASwBJAEQAPgBUAHAAKwBBADkAbwBBAGcAUgAwAEMAagB2AEsAMgB2AE0ASwBpAEYAdABnAD0APQA8AC8ASwBJAEQAPgA8AEwAQQBfAFUAUgBMAD4AaAB0AHQAcAA6AC8ALwBjAGIAcwBpAC4AbABpAHYAZQAuAG8AdAB0AC4AaQByAGQAZQB0AG8ALgBjAG8AbQAvAHAAbABhAHkAcgBlAGEAZAB5AC8AcgBpAGcAaAB0AHMAbQBhAG4AYQBnAGUAcgAuAGEAcwBtAHgAPwBDAHIAbQBJAGQAPQBjAGIAcwBpACYAYQBtAHAAOwBBAGMAYwBvAHUAbgB0AEkAZAA9AGMAYgBzAGkAJgBhAG0AcAA7AEMAbwBuAHQAZQBuAHQASQBkAD0AYQA0AEEAZgA4AHAAdABLAGwAcgA1AGcAdABoAGEAdQBIAG4AZABlADUAQwA5AEoAZABlAEoAYwBOAG4AVwBhADwALwBMAEEAXwBVAFIATAA+ADwARABTAF8ASQBEAD4ARABmAEMAbQBCAFgAdwBLAGEARQB5AFQAbAA3ADgAcgBRAEkAOQB1AHEAUQA9AD0APAAvAEQAUwBfAEkARAA+ADwAQwBIAEUAQwBLAFMAVQBNAD4AZgBKACsAbwA1AGMAOQBOAE8AOABrAD0APAAvAEMASABFAEMASwBTAFUATQA+ADwALwBEAEEAVABBAD4APAAvAFcAUgBNAEgARQBBAEQARQBSAD4A</cenc:pssh>
<mspr:pro>iAMAAAEAAQB+AzwAVwBSAE0ASABFAEEARABFAFIAIAB4AG0AbABuAHMAPQAiAGgAdAB0AHAAOgAvAC8AcwBjAGgAZQBtAGEAcwAuAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBvAG0ALwBEAFIATQAvADIAMAAwADcALwAwADMALwBQAGwAYQB5AFIAZQBhAGQAeQBIAGUAYQBkAGUAcgAiACAAdgBlAHIAcwBpAG8AbgA9ACIANAAuADAALgAwAC4AMAAiAD4APABEAEEAVABBAD4APABQAFIATwBUAEUAQwBUAEkATgBGAE8APgA8AEsARQBZAEwARQBOAD4AMQA2ADwALwBLAEUAWQBMAEUATgA+ADwAQQBMAEcASQBEAD4AQQBFAFMAQwBUAFIAPAAvAEEATABHAEkARAA+ADwALwBQAFIATwBUAEUAQwBUAEkATgBGAE8APgA8AEsASQBEAD4AVABwACsAQQA5AG8AQQBnAFIAMABDAGoAdgBLADIAdgBNAEsAaQBGAHQAZwA9AD0APAAvAEsASQBEAD4APABMAEEAXwBVAFIATAA+AGgAdAB0AHAAOgAvAC8AYwBiAHMAaQAuAGwAaQB2AGUALgBvAHQAdAAuAGkAcgBkAGUAdABvAC4AYwBvAG0ALwBwAGwAYQB5AHIAZQBhAGQAeQAvAHIAaQBnAGgAdABzAG0AYQBuAGEAZwBlAHIALgBhAHMAbQB4AD8AQwByAG0ASQBkAD0AYwBiAHMAaQAmAGEAbQBwADsAQQBjAGMAbwB1AG4AdABJAGQAPQBjAGIAcwBpACYAYQBtAHAAOwBDAG8AbgB0AGUAbgB0AEkAZAA9AGEANABBAGYAOABwAHQASwBsAHIANQBnAHQAaABhAHUASABuAGQAZQA1AEMAOQBKAGQAZQBKAGMATgBuAFcAYQA8AC8ATABBAF8AVQBSAEwAPgA8AEQAUwBfAEkARAA+AEQAZgBDAG0AQgBYAHcASwBhAEUAeQBUAGwANwA4AHIAUQBJADkAdQBxAFEAPQA9ADwALwBEAFMAXwBJAEQAPgA8AEMASABFAEMASwBTAFUATQA+AGYASgArAG8ANQBjADkATgBPADgAawA9ADwALwBDAEgARQBDAEsAUwBVAE0APgA8AC8ARABBAFQAQQA+ADwALwBXAFIATQBIAEUAQQBEAEUAUgA+AA==</mspr:pro>
</ContentProtection>
cenc has not been reverse-engineered (at least not publicly), and even if it had, yt-dlc
and other publicly available tools wouldn't have adopted it (see also https://github.com/blackjack4494/yt-dlc/issues/234) . Pretty soon, the CBS plugin will become totally useless; big US (and other multinational) studios will always have the upper hand... ðŸ˜
Related upstream issues: https://github.com/ytdl-org/youtube-dl/issues/26993 https://github.com/ytdl-org/youtube-dl/issues/27028 https://github.com/ytdl-org/youtube-dl/issues/27039
Despite the fact that I am aware of @blackjack4494's comment, I must give my opinion about the relation between yt-dlc and DRM. I don't really see why we couldn't support DRM. Sooner or later, all media websites (including all YT videos!) will use DRM or some other media protection algorithm. We really should reconsider adding DRM support.
If a video is not playable in some region or country, then, of course, yt-dlc can do nothing about that, because the IP check is performed on the server side (the only workaround would be to use VPN or Travis-CI to download the video and upload somewhere so that you can download it safely, I used secret Travis-CI scripts to do that and I can comfirm that it is the best free way to avoid DRM).
However, if the video is playable in a browser, then it must be possible to write a script in yt-dlc to download the video on the same machine. Think about that: if the browser is able to play the video, then what prevents yt-dlc to download the video on the same machine? I am talking about spotify music and other DRM protected videos and media files that are playable in my browser, but yt-dlc is not able to download them. I am really having troubles understanding what exactly prevents yt-dlc from downloading such media?
I suggest the following algorithm: for any media file playable in the browser, yt-dlc can fetch the webpage content (optionally providing cookies for my account) and send the exact same request headers that would be sent from a browser. Then yt-dlc can use Electron or some other headless browser to execute webpage scripts and obtain media files (audio and video). Then we can write an Electron script that redirects audio+video data to ffmpeg which can encode them and save as a mkv or some other file. I don't see what the problem with this approach is and why exactly would it be illegal? How can a website know whether you redirected the received media directly to your graphic & sound card, or whether you send it to a ffmpeg process? In general, it is not detectable by the remote server. If I had more free time, I could implement it as a proof of concept, but unfortunately, I am lacking free time, but I assure you that this algorithm would fork just fine.
Any opinions regarding this idea?
@SlavKing98 Yes, it is probably possible. But imo it is way beyond the scope of this project. If you are interested in making such an app, it makes sense to keep it completely seperate from youtube-dl. Except that both would be tools to download videos, there is basically no relationship b/w the two. I dont even think any of the existing code is usefull for such a project.
Ofc, then there is also the legal issues. I am not saying whether it is actually illegal or not, but a DRM workaround would defenitely put youtube-dl in hot water irrespective of its actual legality.
@jriker1: Unfortunately, CBS is yet another media portal which has shifted (for newly made available VOD) to Google's Widevine DRM, for stream protection... 💢
Using a whitelisted US IP address and loading your linked episode in a browser, https://cbs.com/shows/seal-team/video/a4Af8ptKlr5gthauHnde5C9JdeJcNnWa/seal-team-god-of-war-forever-war/
...except that I just successfully downloaded this same 'Seal Team' URL. I can't see that CBS would have used Widevine for a URL, then changed it later.
On the other hand, older links produce the error @jriker1 describes above, while newer links for just-aired shows do not. I would say that @Vangelis66's diagnosis is incorrect, as not all new shows are protected. Here are two examples:
Older link that fails:
Much newer link that succeeds:
https://www.cbs.com/shows/magnum-pi/video/o_eBPsGoVAeXvXg_fozxT88bfunT_HqP/magnum-p-i-easy-money/
Other new episodes that succeed are Young Sheldon and Bob Hearts Abishola. On the other hand, NCIS fails. I would like to report my link as a new issue, but I don't know if that is appropriate at this stage. I just signed up. Opinions?
Wow, they actually are literally changing it from DRM to no DRM over time and I hope since I've been using the last Seal Team URL to test a bunch of code I wrote, that it actually does work. Try the new URL, for the last episode youtube-DLC itself fails now:
https://www.cbs.com/shows/seal-team/video/slEle6qBeOEKwknUxvJA9TKzRhPQX48I/seal-team-the-new-normal/
So apparently they are literally removing DRM from the episodes after they get to a certain age. Must be like Fox that isn't posting content on their website until 8 days after it shows up on TV. All this protection and games around public broadcast shows is confusing. I can see it in general for a paid broadcast but these aren't.
Haven't looked at what is the difference in finding the segments to download physically before and after that youtube-dlc can download the content when DRM is removed but can't when it is still applied because technically it should be able to download the segments either way, just when DRM is there the resulting file would still be encrypted.
By the way, programmatically would it be possible to have the exit error level be something other than 1 if it's related to DRM? Be nice to have a way programmatically when using youtube-dlc as a supporting app to another app, to know it's erroring because of DRM and then take some action vs it errored out because of something else.
No, it is not related ot the age of the video; at least, not consistently. What I'm hoping to impress on everyone is that the "Could not find XML Element" error, being reported so often from CBS.com, cannot be a DRM issue. It just makes no sense, for these reasons:
CBS would not add DRM then take it off later. The list below shows links that "didn't work" then "did work" a few days later.
I can't see why CBS would add DRM to OTA videos but not to Subscription videos. The list below shows that the latest episode of "Star Trek: Discovery" works.
If youtube-dl updates solved the problem, then all videos would now work. Some still don't. I am not adding the full bug report for these, because I think the problem's been reported to death. If someone thinks I should, then I will.
The error message does not mention DRM. It says that the downloader "Could not find the XML element.' I'm inclined to take that message at face value, and conclude that the script is sometimes missing the metadata that the downloader needs.
Examples of CBS videos that youtube-dl/c could not download before, but now can. It would be weird in the extreme for CBS to add DRM, then remove it days later.
https://www.cbs.com/shows/the-neighborhood/video/hybfwzvq_TWhJJSE4FXfT_vQB9Ky3Sr_/the-neighborhood-welcome-to-the-movement/ https://cbs.com/shows/seal-team/video/a4Af8ptKlr5gthauHnde5C9JdeJcNnWa/seal-team-god-of-war-forever-war/ https://www.cbs.com/shows/ncis-new-orleans/video/_2DEJoZKRPsStgPJrekAJ5wMph_qM2jO/ncis-new-orleans-something-in-the-air-part-2/
Examples of CBS videos that youtube-dl/c can't download today. These show that the youtube-dl patch mentioned by @october262 has not addressed this issue. Also, youtube-dlc downloads the list above, but not below.
https://www.cbs.com/shows/ncis/video/656bTfET07GnL8vgDviQnyaOwGKdaF2W/ncis-sturgeon-season/ https://www.cbs.com/shows/ncis/video/JJqb_JEapMBMVdn7FYsQMqBamGyQhaTQ/ncis-everything-starts-somewhere/ https://www.cbs.com/shows/ncis/video/HAvQcadOM_QgDzFd6yK8BZm5iTgkZCta/ncis-blood-and-treasure/ https://www.cbs.com/shows/the-unicorn/video/ZlEfHIHOKkLTDAOQb5YSz8m_wdiKiCZw/the-unicorn-there-s-something-about-whoever-she-was/ https://www.cbs.com/shows/the-unicorn/video/UqeHafhusoogPFU_YGNbfDxUYE4wkm6Z/the-unicorn-it-s-complicated/ https://www.cbs.com/shows/the-unicorn/video/72nFb7mACKi28mWkfV09uMsIKqfmkdqT/the-unicorn-it-s-the-thought-that-counts/
Examples of CBS videos that work just fine today. Notice that one of these is subscription-only. It would be weird in the extreme for CBS to add DRM to OTA video, but not subscription. Notice also that this video and the others are newer than the failures above. It would be weird in the extreme for CBS to add DRM to older videos, but not newer.
https://www.cbs.com/shows/bob-hearts-abishola/video/e3Dis09PuIcoec0ADzv7XKJGsEtw9vhw/bob-hearts-abishola-camp-bananas/ https://www.cbs.com/shows/magnum-pi/video/o_eBPsGoVAeXvXg_fozxT88bfunT_HqP/magnum-p-i-easy-money/ https://www.cbs.com/shows/young-sheldon/video/Fmt0hKA3hj05An8XK3hl_ZGmw_xgvKKp/young-sheldon-bible-camp-and-a-chariot-of-love/ https://www.cbs.com/shows/star-trek-discovery/video/73BJ1N0qerkG0WPoUKNuDPcvBdvD6fEX/star-trek-discovery-terra-firma-part-1/
The only logical conclusion is that this is not, in fact, a DRM issue. It seems like stamping a problem "DRM" is always the simplest answer, but it just makes no sense, here. I wish I was better with Python so that I could be more help, but I hope that someone who is can see the logic of my argument.
It may be that DRM is applied for a few hours of days, most likely depending on their distribution rights (ie exclusive right for first run & later window, they need to protect the stream from first shown till first rerun where they then lose the exclusivity).
That's a reasonable theory, @WolfganP, but ytdl/c couldn't download The Neighborhood and Seal Team (and others), and then just a few days later could do so again. There was no time for syndication rights to kick in during such a short period. In addition, many shows above (and one below) simlply download correctly, right from the very first day they're posted. Finally, many of the problem files above are still problems months later. It's not DRM. The sniffer is failing to find some of the XML files on CBS, probably due to changes in their site. I'm very concerned that if we keep finding reasons that problems "must be DRM," it will discourage efforts to fix them.
Although I'd love to think it's NOT DRM, I believe it is. Why? Not getting into the MDP or whatever it was XML file shows it is encrypted, going after the content manually, when you get the XML error and download the video or audio segments and put them together, the file is encrypted. When youtube-dlc can download the show with no issue, manually downloading the same segments or same streams works fine. Are there two separate streams, one DRM and one not, and after a period they point to the non DRM version? Haven't checked on that yet.
@jriker1 makes the most reasonable argument for DRM I have seen so far. However, it still does not compute, for this reason:
I found this episode on CBS, posted yesterday. Ytdl/c both download it perfectly, right from day one (no waiting, no application and later removal of DRM, etc.). Just to be clear, Ytdl finds the XML file, extracts the metadata, downloads the file and then I watch it.
However, when I go after the segments manually, as @jriker1 describes above, the result is encrypted. The encryption results in exactly the same way for manual downloads that do or do not experience the XML error when using ytdl/c. This is more evidence that the CBS/XML error is not caused by DRM.
Encryption often appears in files for reasons other than DRM (e.g. to make the file play in a proprietary web player). That is one reason for the metadata; to interpret the encryption. ytdl/c is simply failing to do so in some cases. I was thinking about some of the shows above (The Neighborhood, Seal Team) that suddenly "started working." The time that this happened could coincide with the latest ytdl update in December.
https://www.cbs.com/shows/magnum-pi/video/7UnTVBHiwEOURls04js_dxihuZkZIC6n/magnum-p-i-no-way-out/
Downloading this episode 5 minutes after it was posted. Can't be DRM.
We need to stick with one show. Can't assume all shows will be handled the same. I know Keith you content this isn't DRM so try and work around that word. Since I started this with Seal Team will stick with it. Not sure right now, but the next episode of Seal Team after the original one I posted, was not downloadable or was but not thru YouTube-DLC and couldn't be played. But the original episode I posted became downloadable by YouTube-DLC and playable. I'm going to guess if it hasn't already, the latest episode of Seal Team is downloadable again. Plus that word that shall not be spoken or not, the MPD file associated with it at least when it wasn't playable contains things that elude to something like:
<ContentProtection value="cenc" schemeIdUri="urn:mpeg:dash:mp4protection:2011" cenc:default_KID="f6809f4e-2080-4047-a3bc-adaf30a885b6"/>
<ContentProtection schemeIdUri="urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
<cenc:pssh>AAAAVnBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAADYIARIQ9oCfTiCAQEejvK2vMKiFtiIgYTRBZjhwdEtscjVndGhhdUhuZGU1QzlKZGVKY05uV2E=</cenc:pssh>
</ContentProtection>
<ContentProtection value="MSPR 2.0" schemeIdUri="urn:uuid:9a04f079-9840-4286-ab92-e65be0885f95">
<cenc:pssh>AAADqHBzc2gAAAAAmgTweZhAQoarkuZb4IhflQAAA4iIAwAAAQABAH4DPABXAFIATQBIAEUAQQBEAEUAUgAgAHgAbQBsAG4AcwA9ACIAaAB0AHQAcAA6AC8ALwBzAGMAaABlAG0AYQBzAC4AbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQAvAEQAUgBNAC8AMgAwADAANwAvADAAMwAvAFAAbABhAHkAUgBlAGEAZAB5AEgAZQBhAGQAZQByACIAIAB2AGUAcgBzAGkAbwBuAD0AIgA0AC4AMAAuADAALgAwACIAPgA8AEQAQQBUAEEAPgA8AFAAUgBPAFQARQBDAFQASQBOAEYATwA+ADwASwBFAFkATABFAE4APgAxADYAPAAvAEsARQBZAEwARQBOAD4APABBAEwARwBJAEQAPgBBAEUAUwBDAFQAUgA8AC8AQQBMAEcASQBEAD4APAAvAFAAUgBPAFQARQBDAFQASQBOAEYATwA+ADwASwBJAEQAPgBUAHAAKwBBADkAbwBBAGcAUgAwAEMAagB2AEsAMgB2AE0ASwBpAEYAdABnAD0APQA8AC8ASwBJAEQAPgA8AEwAQQBfAFUAUgBMAD4AaAB0AHQAcAA6AC8ALwBjAGIAcwBpAC4AbABpAHYAZQAuAG8AdAB0AC4AaQByAGQAZQB0AG8ALgBjAG8AbQAvAHAAbABhAHkAcgBlAGEAZAB5AC8AcgBpAGcAaAB0AHMAbQBhAG4AYQBnAGUAcgAuAGEAcwBtAHgAPwBDAHIAbQBJAGQAPQBjAGIAcwBpACYAYQBtAHAAOwBBAGMAYwBvAHUAbgB0AEkAZAA9AGMAYgBzAGkAJgBhAG0AcAA7AEMAbwBuAHQAZQBuAHQASQBkAD0AYQA0AEEAZgA4AHAAdABLAGwAcgA1AGcAdABoAGEAdQBIAG4AZABlADUAQwA5AEoAZABlAEoAYwBOAG4AVwBhADwALwBMAEEAXwBVAFIATAA+ADwARABTAF8ASQBEAD4ARABmAEMAbQBCAFgAdwBLAGEARQB5AFQAbAA3ADgAcgBRAEkAOQB1AHEAUQA9AD0APAAvAEQAUwBfAEkARAA+ADwAQwBIAEUAQwBLAFMAVQBNAD4AZgBKACsAbwA1AGMAOQBOAE8AOABrAD0APAAvAEMASABFAEMASwBTAFUATQA+ADwALwBEAEEAVABBAD4APAAvAFcAUgBNAEgARQBBAEQARQBSAD4A</cenc:pssh>
<mspr:pro>iAMAAAEAAQB+AzwAVwBSAE0ASABFAEEARABFAFIAIAB4AG0AbABuAHMAPQAiAGgAdAB0AHAAOgAvAC8AcwBjAGgAZQBtAGEAcwAuAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBvAG0ALwBEAFIATQAvADIAMAAwADcALwAwADMALwBQAGwAYQB5AFIAZQBhAGQAeQBIAGUAYQBkAGUAcgAiACAAdgBlAHIAcwBpAG8AbgA9ACIANAAuADAALgAwAC4AMAAiAD4APABEAEEAVABBAD4APABQAFIATwBUAEUAQwBUAEkATgBGAE8APgA8AEsARQBZAEwARQBOAD4AMQA2ADwALwBLAEUAWQBMAEUATgA+ADwAQQBMAEcASQBEAD4AQQBFAFMAQwBUAFIAPAAvAEEATABHAEkARAA+ADwALwBQAFIATwBUAEUAQwBUAEkATgBGAE8APgA8AEsASQBEAD4AVABwACsAQQA5AG8AQQBnAFIAMABDAGoAdgBLADIAdgBNAEsAaQBGAHQAZwA9AD0APAAvAEsASQBEAD4APABMAEEAXwBVAFIATAA+AGgAdAB0AHAAOgAvAC8AYwBiAHMAaQAuAGwAaQB2AGUALgBvAHQAdAAuAGkAcgBkAGUAdABvAC4AYwBvAG0ALwBwAGwAYQB5AHIAZQBhAGQAeQAvAHIAaQBnAGgAdABzAG0AYQBuAGEAZwBlAHIALgBhAHMAbQB4AD8AQwByAG0ASQBkAD0AYwBiAHMAaQAmAGEAbQBwADsAQQBjAGMAbwB1AG4AdABJAGQAPQBjAGIAcwBpACYAYQBtAHAAOwBDAG8AbgB0AGUAbgB0AEkAZAA9AGEANABBAGYAOABwAHQASwBsAHIANQBnAHQAaABhAHUASABuAGQAZQA1AEMAOQBKAGQAZQBKAGMATgBuAFcAYQA8AC8ATABBAF8AVQBSAEwAPgA8AEQAUwBfAEkARAA+AEQAZgBDAG0AQgBYAHcASwBhAEUAeQBUAGwANwA4AHIAUQBJADkAdQBxAFEAPQA9ADwALwBEAFMAXwBJAEQAPgA8AEMASABFAEMASwBTAFUATQA+AGYASgArAG8ANQBjADkATgBPADgAawA9ADwALwBDAEgARQBDAEsAUwBVAE0APgA8AC8ARABBAFQAQQA+ADwALwBXAFIATQBIAEUAQQBEAEUAUgA+AA==</mspr:pro>
</ContentProtection>
That's a good strategy to stick with one show. However, I feel I've already done that: "The Unicorn" and "NCIS" have (so far, at least) not become downloadable for months, so that is inconsistent with your "Seal Team" and "The Neighborhood" experience. Still, it's a good strategy to keep an eye on what happens with a show that failed and then later succeeded. Can you check each week whether "Seal Team" is blocked, then check each week after that whether it becomes available?
I remind you that the direct-MPD downloads I've tried on perfectly downloadable files result in the same content protection that you are describing. That includes the Magnum, P.I. episode I downloaded yesterday. It played right away (and still plays) after downloading with youtube-dl/c, but seems encrypted after a direct download. Unless that symptom is exclusive to the files throwing errors, then it is not a sign of DRM. Try your direct method with a known working file.
I'm amused by 'that word that shall not be spoken.' Thanks for the chuckle.
----- Original message ----- From: jriker1 notifications@github.com To: blackjack4494/yt-dlc yt-dlc@noreply.github.com Cc: keith-leitch keith_leitch@warpmail.net, Comment comment@noreply.github.com Subject: Re: [blackjack4494/yt-dlc] CBS download issue (#275) Date: Sunday, December 20, 2020 4:42 AM
We need to stick with one show. Can't assume all shows will be handled the same. I know Keith you content this isn't DRM so try and work around that word. Since I started this with Seal Team will stick with it. Not sure right now, but the next episode of Seal Team after the original one I posted, was not downloadable or was but not thru YouTube-DLC and couldn't be played. But the original episode I posted became downloadable by YouTube-DLC and playable. I'm going to guess if it hasn't already, the latest episode of Seal Team is downloadable again. Plus that word that shall not be spoken or not, the MPD file associated with it at least when it wasn't playable contains things that elude to something like:
`
`
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/blackjack4494/yt-dlc/issues/275#issuecomment-748509954, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASDR7DSRIRSLZ5RSKV6FQQLSVTXXVANCNFSM4UMR5K3Q.
Just found another CBS issue that seems unrelated to the above.
I'm sure someone will just call it DRM and move on.
I've replied more helpfully in https://github.com/blackjack4494/yt-dlc/issues/295
Trying to access a URL with youtube-dl 12.2 on Windows Python and getting an error.
[CBS] a4Af8ptKlr5gthauHnde5C9JdeJcNnWa: Downloading XML ERROR: Could not find XML element title; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see https://yt-dl.org/update on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Command is youtube-dl --ap-mso Comcast_SSO --ap-username --ap-password https://cbs.com/shows/seal-team/video/a4Af8ptKlr5gthauHnde5C9JdeJcNnWa/seal-team-god-of-war-forever-war/
Extended Logging: [debug] System config: [] [debug] User config: [] [debug] Custom config: [] [debug] Command-line args: ['--ap-mso', 'Comcast_SSO', '--ap-username', 'PRIVATE', '--ap-password', 'PRIVATE', 'https://cbs.com/shows/seal-team/video/a4Af8ptKlr5gthauHnde5C9JdeJcNnWa/seal-team-god-of-war-forever-war/', '--verbose'] [debug] Encodings: locale cp1252, fs utf-8, out utf-8, pref cp1252 [debug] youtube-dl version 2020.12.02 [debug] Python version 3.9.0 (CPython) - Windows-10-10.0.19041-SP0 [debug] exe versions: ffmpeg 4.3.1-2020-10-01-full_build-www.gyan.dev, phantomjs 2.1.1 [debug] Proxy map: {} [CBS] a4Af8ptKlr5gthauHnde5C9JdeJcNnWa: Downloading XML ERROR: Could not find XML element title; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see https://yt-dl.org/update on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output. Traceback (most recent call last): File "c:\users\jriker\appdata\local\programs\python\python39\lib\site-packages\youtube_dl\YoutubeDL.py", line 803, in wrapper return func(self, *args, **kwargs) File "c:\users\jriker\appdata\local\programs\python\python39\lib\site-packages\youtube_dl\YoutubeDL.py", line 824, in __extract_info ie_result = ie.extract(url) File "c:\users\jriker\appdata\local\programs\python\python39\lib\site-packages\youtube_dl\extractor\common.py", line 532, in extract ie_result = self._real_extract(url) File "c:\users\jriker\appdata\local\programs\python\python39\lib\site-packages\youtube_dl\extractor\cbs.py", line 112, in _real_extract return self._extract_video_info(content_id) File "c:\users\jriker\appdata\local\programs\python\python39\lib\site-packages\youtube_dl\extractor\cbs.py", line 62, in _extract_video_info title = xpath_text(video_data, 'videoTitle', 'title', True) File "c:\users\jriker\appdata\local\programs\python\python39\lib\site-packages\youtube_dl\utils.py", line 1910, in xpath_text n = xpath_element(node, xpath, name, fatal=fatal, default=default) File "c:\users\jriker\appdata\local\programs\python\python39\lib\site-packages\youtube_dl\utils.py", line 1903, in xpath_element raise ExtractorError('Could not find XML element %s' % name) youtube_dl.utils.ExtractorError: Could not find XML element title; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see https://yt-dl.org/update on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.