Closed justinh998 closed 7 months ago
Hello Justin,
Unfortunately, the formatting of your post seems to be a bit messed up and I am therefore having a hard time understanding what exactly your issue is. That said, I think you may have an issue with how your SSL certificate is configured. When I open https://isseutestgithub.youtube-music-alexa-test.de:4000/dl/ymNFyxvIdaM?f=bestaudio in Chrome, the audio downloads, but clicking on the info icon on the address bar shows the following pop-up.
Additionally, curl
also reports an SSL certificate issue:
david@David-PC:~$ curl -v https://isseutestgithub.youtube-music-alexa-test.de:4000/dl/ymNFyxvIdaM?f=bestaudio
* Trying 84.171.124.221:4000...
* Connected to isseutestgithub.youtube-music-alexa-test.de (84.171.124.221) port 4000 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS header, Unknown (21):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
Hi David Berik Thank your for the quick answer I've corrected the formatting. Not sure what happened, but it definitely shouldn't be like that.
The certificate error is strange; I can actually reproduce it in Chrome (no issues in Edge) only when requesting "/dl." If, for example, I request "/meta," the connection is secure.
I simply added my SSL certificates from Let's Encrypt to Unicorn to enable HTTPS.
ssl_keyfile="./key.pem", ssl_certfile="./cert.pem"
I'll take another look at that; there must be a way to solve it without needing a reverse proxy for this particular case.
My main issue is that Alexa isn't playing audio due to an unknown error (see the last entry in the large log at the end of the first message). This error doesn't seem to be related to the certificate because there would be another certificate error in the log if it were. I don't know where this error is coming from.
By the way, in your code, it states that my website accesses Alexa not as https://test.de:4000/dl/jfhs872?f?bestaudio
but rather as https://test.de:4000/api/dl/jfhs872?f=bestaudio
. However, when I include "api" in there, I always get a "not found" error. I don't see any "api" in the code (Server.py) either. The error was easily corrected by simply removing "api."
Thank your for the quick answer I've corrected the formatting. Not sure what happened, but it definitely shouldn't be like that.
You're welcome! Thanks for fixing it! It's much easier to read now, but unfortunately, I don't have anything to add to what I shared earlier.
I'll take another look at that; there must be a way to solve it without needing a reverse proxy for this particular case.
I am sure you probably can run it directly with some modifications, but since my setup uses a reverse proxy, I have never bothered to research it.
My main issue is that Alexa isn't playing audio due to an unknown error (see the last entry in the large log at the end of the first message). This error doesn't seem to be related to the certificate because there would be another certificate error in the log if it were. I don't know where this error is coming from.
What is the type of Alexa device that you're trying to use for playback?
By the way, in your code, it states that my website accesses Alexa not as
https://test.de:4000/dl/jfhs872?f?bestaudio
but rather ashttps://test.de:4000/api/dl/jfhs872?f=bestaudio
. However, when I include "api" in there, I always get a "not found" error. I don't see any "api" in the code (Server.py) either. The error was easily corrected by simply removing "api."
Would you mind linking me to the code you're referring to?
I am sure you probably can run it directly with some modifications, but since my setup uses a reverse proxy, I have never bothered to research it.
yes I will have a look, I had already looked yesterday but nothing really found. if not I have to create an isseu in the uvicorn github.
What is the type of Alexa device that you're trying to use for playback?
i use an echo dot (3 gen), but the error also occurs when i call up the skill in the alexa app on my cell phone. so it's not device-specific.
Would you mind linking me to the code you're referring to?
Of course! I am referring to this code snippet from lines 944 to 973, particularly line 973:
So this line :
return 'https://' + environ['ytdl_web_address'] + '/api/dl/' + id + '?f=bestaudio&preshared=' + environ['ytdl_preshared_key'], first_stream.title
The web address you return with this code is e.g. https://test.de:4000/api/dl/163Hudhs?f=bestaudio I'll leave out the preshared key now, I don't use it . But this UrL does not work, because I always get a not found (i.e. the server responds with json saying not found). but if I leave out the json and there : https://test.de:4000/dl/163Hudhs?f=bestaudio, it works. Also in @wes1993 code , is the api in the adress . Do you have any service running outside the server that you address with api?
i use an echo dot (3 gen), but the error also occurs when i call up the skill in the alexa app on my cell phone. so it's not device-specific.
Alright. The reason I asked about the device you're using is because, at least from what I have read elsewhere, older Alexa devices just don't work with this skill. That said, I have a 3rd gen Echo Dot that I use this with and it works just fine.
Of course! I am referring to this code snippet from lines 944 to 973, particularly line 973: So this line :
return 'https://' + environ['ytdl_web_address'] + '/api/dl/' + id + '?f=bestaudio&preshared=' + environ['ytdl_preshared_key'], first_stream.title
The web address you return with this code is e.g. https://test.de:4000/api/dl/163Hudhs?f=bestaudio I'll leave out the preshared key now, I don't use it . But this UrL does not work, because I always get a not found (i.e. the server responds with json saying not found). but if I leave out the json and there : https://test.de:4000/dl/163Hudhs?f=bestaudio, it works.
Ah, I see the issue. You're looking at an older version of that function. The branch in this repository with the most recent code changes as of this reply is add-video-thumbnail-to-title-card
. I significantly modified the code for this function as compared to what you shared. Take a look at the latest version here.
Also in @wes1993 code , is the api in the adress . Do you have any service running outside the server that you address with api?
The API component of the address is an artifact from youtube-dl-web, which is the project upon which the YouTube Stream Repeater is based. Basically, this project took the code from that project and stripped out most of the components that I did not need. The original project used /api/
as part of the URL for its reverse proxy configuration (see here), but I did not need it for this fork, so I removed it.
Ah, I see the issue. You're looking at an older version of that function. The branch in this repository with the most recent code changes as of this reply is add-video-thumbnail-to-title-card. I significantly modified the code for this function as compared to what you shared. Take a look at the latest version here.
Interesting, I'll put the code into kdiff (a tool for bit-by-bit comparisons). There, I can compare it with wes1993's code and my current code. After a quick look, it seems that only the get_url_and_title_ytdl_web function has been changed, and now the video title is pulled through the YouTube Data API. The part about thumbnails and the title card (whatever that is, the title card) sounds interesting, but it doesn't matter to me since it only makes sense and works on devices with displays. However, the branch seems to be one version behind wes1993's code or one commit behind the master branch. In the new version by wes1993, progressive play has definitely been added, which is likely useful, and apparently, YouTube DL has been updated. I'll merge both locally and examine the exact differences later this afternoon. I could also imagine that the device might encounter a playback error because it wants to download the file from my server (it's not a stream but a file), but that could fail due to a certificate error. Although, there would certainly be an error, similar to when I try to access /meta.One thing definitely supports this, namely, when I try to play a song using Alexa, there are no incoming requests at the server that you could actually see in the log. Although I'm not even entirely sure if the server actually downloads the audio file from the YouTube servers and forwards it to me, or if it's indeed a stream that VLC, for example, interprets incorrectly. However, that is an entirely different topic and has nothing to do with this issue.
Ok, I have solved the problem, it was actually the certificate. I simply changed the ssl certfile from cert.pem to Fullchain.pem. It works for now except for a few things like the fast forward function / jump function which leads to problems / errors in several ways. But I will investigate again where the errors are (will be a combination of lambda programming and missing checks in the server code) and then create an isseu or solve it myself. I think my biggest problem is that I am currently training to become an IT specialist in application development (3 months ago) and although I can write and read code, the code seems a bit more complicated. Well, what are ki tools like chat gpt for, which help you in places where you don't know what to do. Thank you for your help.
After a quick look, it seems that only the get_url_and_title_ytdl_web function has been changed, and now the video title is pulled through the YouTube Data API. The part about thumbnails and the title card (whatever that is, the title card) sounds interesting, but it doesn't matter to me since it only makes sense and works on devices with displays.
My changes to the code to support the title card is just a minor cosmetic change that I made so that when I use the YouTube skill on my Echo Show, it will show the name of the video as well as the thumbnail for the video on the display instead of using a generic title card for everything. Unless you have an Alexa device with a screen, it's not of any value.
However, the branch seems to be one version behind wes1993's code or one commit behind the master branch. In the new version by wes1993, progressive play has definitely been added, which is likely useful, and apparently, YouTube DL has been updated.
I am not sure what "progressive play" refers to, but whatever it is, it sounds like it has the potential to be useful, so I guess I'll have to check it out! As for youtube-dl
getting updated, it's a good thing that he updated it, but for my use case, it's irrelevant since I use the YouTube Stream Repeater instead. Of course, the YouTube Stream Repeater uses youtube-dl
(actually, it uses the yt-dlp
fork) for its functionality as well, but the point is that the Lambda function is not using it directly. Rather, it just tells Alexa to access YouTube via the YouTube Stream Repeater, and when Alexa connects to the repeater, the repeater itself uses it instead of the Lambda function doing it directly.
I could also imagine that the device might encounter a playback error because it wants to download the file from my server (it's not a stream but a file)
This has never been an issue for me. Although it is true that directly accessing a URL through the stream repeater via a browser causes a file download, you can pass that URL to Alexa and it will stream its content. Similarly, you can use VLC Media Player to open the URL and it will stream it instead of downloading.
One thing definitely supports this, namely, when I try to play a song using Alexa, there are no incoming requests at the server that you could actually see in the log.
Well, the server does log requests that are made to it, which means that for whatever reason, Alexa is not accessing your server.
Although I'm not even entirely sure if the server actually downloads the audio file from the YouTube servers and forwards it to me, or if it's indeed a stream that VLC, for example, interprets incorrectly. However, that is an entirely different topic and has nothing to do with this issue.
The server is essentially acting as a proxy between your client and YouTube. Whenever a client connects to the YouTube Stream Repeater, it reaches out to YouTube on your behalf and starts downloading the content from YouTube and serving it to you directly from YouTube. It's not downloading the content and then playing it from a local cache of the content or anything like that.
Ok, I have solved the problem, it was actually the certificate.
Great!
It works for now except for a few things like the fast forward function / jump function which leads to problems / errors in several ways.
Yeah, this feature has been broken for quite a while. I know about it, but I haven't had time to look in to properly fixing it, and I don't really use it very often, so I've just dealt with it. If you manage to find a solution for it, that would be awesome!
I think my biggest problem is that I am currently training to become an IT specialist in application development (3 months ago) and although I can write and read code, the code seems a bit more complicated.
Just enjoy the journey! Learning how to work with code that you aren't familiar with can be fun! 😁
Thank you for your help.
You're welcome!
Hello, I hope someone can help me here. I'm currently quite desperate as I've been dealing with this problem for about 4 weeks. I have this server (youtube-stream-repeater) running in Docker, and it seems to be working fine. For example, when I access https://isseutestgithub.youtube-music-alexa-test.de:4000/dl/ymNFyxvIdaM?f=bestaudio, I get a downloadable file that can be played. However, AWS keeps giving me this error all the time: {'message': 'Device playback error', 'type': 'MEDIA_ERROR_UNKNOWN'}. Is it possible that AWS/Alexa cannot handle the fact that it's not receiving a direct stream (like in pytube for example an pytube link : pytube link ? If there are issues with this, have there been numerous issues reported here, or are people modifying their code accordingly? Here is my code that I changed; everything else corresponds to the current version from wes1993.
I always pass a fixed title:
return stream_ext, "freestyler"
Since when I try to execute the code:I always encounter an error:
No other thing has an issue with my website, only Python. I believe this is a general Python problem, and I maybe will come up with a solution for it. Pytube, as used by @DavidBerdik , is rather unreliable. Here is the entire log from AWS of a failed attempt:
I hope somebody can help me