support the ytube_music_player home assistant plugin

[mogorman]

when i try to use the plugin it seems to get a 403 forbidden. this does not happen when i use other media players. the only thing that jumps out to me is the user-agent being set the way it is. Is there a way i can control the headers i send on http requests? I grepped code base and vlc didnt show up.

[sle118]

I think you will need to provide more background to this. Describe your environment, the firmware release you're using, how you initiate playback, etc.

Assume we don't know home assistant or the ytube_music_player at all and we have no idea how it's used to describe the probkem you're facing. Also, you should paste logs enclosed in "code" markup symbols as it makes things easier to read and copy/paste.

thank you

[philippe44]

I'd guess the http connection is attempted to be upgraded to SSL, this is what google typically does and that will fail as HTTPS is not supported

[mogorman]

i think you are right as to why it wasnt working, the https. ytube_music_player also has a proxy mode, where it just redirects the mp4 stream out over the local network. when i attempt using that i get 1 second of corrupted audio.

00:03:40.310] stream_sock:508 connecting to 10.0.2.2:8123
[00:03:40.315] stream_sock:582 header: GET /local/ytube_proxy.mp4?authSig=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI0ZTE3YWVjYTI2NjQ0YmU4OTQ3NWY5YjlhOTMzMjFjNiIsInBhdGgiOiIvbG9jYWwveXR1YmVfcHJveHkubXA0IiwicGFyYW1zIjpbXSwiaWF0IjoxNjgyNTM0ODM4LCJleHAiOjE2ODI2MjEyMzh9.ytDrOueCf4A42kIOoTfvchgN9-pWnIz16zbsPxIVBvI HTTP/1.0
Host: 10.0.2.2:8123
Connection: close
Accept: */*
Cache-Control: no-cache
User-Agent: VLC/3.0.9 LibVLC/3.0.9
Range: bytes=0-

[00:03:40.448] stream_thread:264 headers: len: 335
HTTP/1.0 206 Partial Content
Cache-Control: public, max-age=2678400
Content-Type: video/mp4
Etag: "175990857f92000c-4ea646"
Last-Modified: Wed, 26 Apr 2023 18:47:19 GMT
Content-Length: 5154374
Accept-Ranges: bytes
Content-Range: bytes 0-5154373/5154374
Date: Wed, 26 Apr 2023 18:47:18 GMT
Server: Python/3.10 aiohttp/3.8.4

[00:03:40.487] codec_open:283 codec open: 'm'
[00:03:40.894] output_thread_i2s:463 Output state is 1
[00:03:40.897] output_thread_i2s:529 Restarting I2S.
[00:03:40.906] equalizer_open:71 equalizer initialized 0
[00:03:51.471] mad_decode:247 setting track_start

squeezelite-esp32> [00:04:15.696] _output_frames:65 start buffer frames: 3695
[00:04:15.700] _output_frames:150 track start sample rate: 11025 replay_gain: 0
[00:04:15.702] output_thread_i2s:537 changing sampling rate 44100 to 11025
I (257187) I2S: APLL: Req RATE: 11025, real rate: 11024.997, BITS: 16, CLKM: 1, BCK_M: 8, MCLK: 2822399.250, SCLK: 352799.906250, diva: 1, divb: 0
[00:04:15.723] equalizer_open:71 equalizer initialized 0
[00:04:15.725] output_thread_i2s:463 Output state is 2

for the more background I am using this version of the firmware 2.1299-16 | 4/19/23, 6:23 PM | Muse | master-v4.3 | 16 on an espmuse luxe. I initiate playback by clicking on the plugin in home-assistant that triggers a media play event over lms to the device.

[mogorman]

also said stream plays back with out issue using mplayer.

[philippe44]

Also, the content-type and codec is inconsistent for LMS. It says 'm' which is mp3 and the file is an mp4 video, that squeezelite is not able to decode anyway. It can only do mp4 with with aac or alac (4 or l) or aac (a)

[sle118]

One thing you can try is, in the player/settings/Audio->Streaming method, change to Proxied Streaming. If this works as I think it does, then the LMS should handle TLS traffic and pass unencrypted traffic to the player.

I believe that the server typically falls back to proxying connections when you synchronize clients.

[philippe44]

I believe that the server typically falls back to proxying connections when you synchronize clients.

Indeed, it does

[sle118]

I'm going to close this for now