Access errors on https streams about ytuner HOT 4 CLOSED

Thank you for appreciate my work.
I'm afraid that your RX-V677 as my RX-V671 and RX-V673 do not support the https protocol. In many cases, the same station offers the same audio stream using the http protocol. As you probably already know after reading README.md and the contents of AVR.ini file you can use Protocol parameter in Configuration section and use default all-as-http. But ... in your case with m3u8 file mentioned option will apply to the address http://digitalstreams.mediaworks.nz/chx_net_high/playlist.m3u8 and not to the addresses contained in this m3u8 file because YTuner is not able to modify the content of this file on-the-fly because it is downloaded by your AVR directly from digitalstreams.mediaworks.nz.
Solution? Don't use m3u/m3u8 files with https links. Use direct link(s) from m3u files with http/https and YTuner strip "s" from your links automatically.
The best part of YTuner is yet to come. Full caching of radio-browser.info resources and ultra-fast performance (if it's not already there). 😉
Have fun. 🎵 May the sound be with you. 🎶

from ytuner.

May I add your Yamaha RX-V677 to Confirmed working list ?

from ytuner.

Hey! Absolutely you may mark the RX-V677 as working.. you can assume that the RX-V777 will work also. It's basically the same.

There is a caveat to these receivers. I'm running firmware version 1.98 (which is the latest) and when it makes an HTTP connection to YTuner, it doesn't include the host header in the HTTP request. If placing Nginx or any other HTTP server over the front of it, you need to specify the IP address as the servername as opposed to *.vtuner.com.

Regardings HTTPS, I did a packet capture, and I have seen the amp attempt to reach out to the target over https which is interesting. I suspect (but haven't had the time to check yet) it might be using an out of date SSL version eg TLS 1.0 or SSL3 which may be rejected by the headend. In which case, you could reverse proxy it at a lower SSL version, however the issue would remain if it does certificate validation.

The easiest thing to do would be to create something that terminates the HTTPS session with the source, and presents it as HTTP to the receiver. It would need to be able to rewrite the contents of the m3u8 files to point to itself. You could do this using PHP or something like that. You could then make the streaming url something like http://yourproxy/proxy.php?url=https://digitalstreams.mediaworks.nz/chx_net_high/playlist.m3u8 for example.

I'll have a play around and see what I can come up with.

from ytuner.

Regardings HTTPS, I did a packet capture, and I have seen the amp attempt to reach out to the target over https which is interesting. I suspect (but haven't had the time to check yet) it might be using an out of date SSL version eg TLS 1.0 or SSL3 which may be rejected by the headend. In which case, you could reverse proxy it at a lower SSL version, however the issue would remain if it does certificate validation.

Yes, please try to capture Client Hello and Server Hello TLS Handshake packets and look at TLS.ProtocolVersion but I'm afraid in our case it's not a problem of outdated SSL 3.0 or TLS 1.0-1.1. Client should accept at least TLS 1.2 (major/minor = 0x03/0x03).

The easiest thing to do would be to create something that terminates the HTTPS session with the source, and presents it as HTTP to the receiver. It would need to be able to rewrite the contents of the m3u8 files to point to itself.

Yes, some kind of reverse proxy with SSL termination and URL modification/redirection or TCP packets modification ability. 🤔 The question is whether it makes sense? If you come up with a good idea, let me know. 👍

This is a good topic for discussion, so I'm moving it to Discussions.

from ytuner.