Access errors on https streams

[jordandalley]

Firstly, love your work! This project rocks :)

I figure this is the limitation of the amp (Yamaha RX-V677) but https streams don't load. The amp appears to buffer then it returns a "Access Error" message.

I'm going to try some kind of reverse proxy for that and see how I go, but the particular stream i'm working with serves an m3u8 file containing a https address so it might be difficult.

This is the stream I'm referring to: http://digitalstreams.mediaworks.nz/chx_net_high/playlist.m3u8

Cheers!

[coffeegreg]

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. 🎶

[coffeegreg]

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

[jordandalley]

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.

[coffeegreg]

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.

[jordandalley]

I actually managed to find a URL that presents http only, and the same issue occurs.

URL is: http://digitalstreams-master1.mediaworks.nz:80/chx_net_high/playlist.m3u8?listeningSessionID=65534790bfeb2bb6_4903108_gk5yQ4pi__000000000cu&downloadSessionID=0

Interestingly from packet captures, the amp doesn't really do anything with it. I don't know enough about everything works to speculate but it could be a codec incompatibility.

Below shows the request and the response, after which the amp just gives up and displays the "Access error".

192.168.50.46.1239 > server-65-8-33-67.mel50.r.cloudfront.net.http: Flags [P.], cksum 0xab11 (correct), seq 1:286, ack 1, win 65535, length 285: HTTP, length: 285
    GET /chx_net_high/playlist.m3u8?listeningSessionID=65534790bfeb2bb6_4903108_gk5yQ4pi__000000000cu&downloadSessionID=0 HTTP/1.1
    Host: digitalstreams-master1.mediaworks.nz
    Icy-MetaData: 1
    Connection: close
    transferMode.dlna.org: Streaming
    User-Agent: WinampMPEG/2.8
    Accept: */*

server-65-8-33-67.mel50.r.cloudfront.net.http > 192.168.50.46.1239: Flags [P.], cksum 0xfb82 (correct), seq 1:1424, ack 286, win 65535, length 1423: HTTP, length: 1423
    HTTP/1.1 200 OK
    Content-Type: application/vnd.apple.mpegurl
    Content-Length: 594
    Connection: close
    Date: Wed, 10 Jan 2024 05:23:53 GMT
    Pragma: no-cache
    Expires: Mon, 26 Jul 1997 05:00:00 GMT
    Instance-id: f3f926cbf003ad56298bc62e64ed91da
    Server: AIS Streaming Server 9.1.1
    Accept-Ranges: bytes
    Cache-Control: no-cache
    Set-Cookie: ListenerInfo=ZjNmOTI2Y2JmMDAzYWQ1NjI5OGJjNjJlNjRlZDkxZGE7MDs7NTs7MTcwNDg2NDIwNDI3MzswLzEwMDA7NTk5ODk7dCwxNzA0ODY0MTg5Mjc2O3QsMTcwNDg2NDE5NDI2ODt0LDE3MDQ4NjQxOTkyODE7dCwxNzA0ODY0MjA0Mjcz; Path=/; Domain=digitalstreams-master1.mediaworks.nz; Max-Age=40; Expires=Wed, 10 Jan 2024 05:24:33 GMT
    X-Cache: Miss from cloudfront
    Via: 1.1 d1d963d1b987e74904429c900aa75fd2.cloudfront.net (CloudFront)
    X-Amz-Cf-Pop: MEL50-C2
    X-Amz-Cf-Id: PakZWVkRuC1dfYoxupaIOOMYCvF_21fhONLHC4Xm0fB6jZpUzzCh9g==

    #EXTM3U
    #EXT-X-VERSION:3
    #EXT-X-TARGETDURATION:6
    #EXT-X-MEDIA-SEQUENCE:5
    #EXT-X-DISCONTINUITY-SEQUENCE:0
    #EXTINF:4.992,title="ROVA ADS END 0 sec - AW_END",artist="ROVA ADS END 0 sec - AW_END"
    1oZQfbNMsfKp-340972837-4992.aac
    #EXTINF:5.013,title="ROVA ADS END 0 sec - AW_END",artist="ROVA ADS END 0 sec - AW_END"
    jXVVJohspVep-340972838-5013.aac
    #EXTINF:4.992,title="ROVA ADS END 0 sec - AW_END",artist="ROVA ADS END 0 sec - AW_END"
    kwtRnSeuncEp-340972839-4992.aac
    #EXTINF:4.992,title="ROVA ADS END 0 sec - AW_END",artist="ROVA ADS END 0 sec - AW_END"
    i4UVKnTPDF8p-340972840-4992.aac

[coffeegreg]

Looks like this URL http://digitalstreams-master1.mediaworks.nz:80/chx_net_high/playlist.m3u8 is recursively nested inside http://digitalstreams-master1.mediaworks.nz:80/chx_net_high/playlist.m3u8 😉
In my case, the problem with an unsupported codec generates the message "Unable to play", but it may look different on different devices with different firmware versions.
.m3u8 file contains CODECS="mp4a.40.2". This is MPEG-4 AAC Profile (ISO/IEC 23000-19 Annex A.3)
1oZQfbNMsfKp-340972837-4992.aac ... it appears to be an AAC codec and your RX-V677 support AAC.
I also sometimes encounter this error on my RX-V671 and RX-V673 and I only use the http protocol. Perhaps I come across stations like in your case but I have never thoroughly analyzed each case.

[jordandalley]

I'm beginning to think that the amp simply doesn't support hls..