I'm not sure if this is should be discussed under a pCP thread or under LMS. Anyway, If the pCP squeezelite was supposed to handle direct streaming to Tidal, it doesn't ...
Please note that this "issue" is easily fixed by setting "Proxied streaming" for the player in LMS! I'm just curious since squeezelite reports HTTPS=1 to LMS, but it still hangs with "Connecting" and is not stoppable from LMS when trying to play a Tidal track. I assume that https is relevant somehow in this case, given the changes in both Tidal and LMS. When this happens, if the page in the LMS Default skin is reloaded, the player disappears from the list of attached players. (But the pCP admin page is still working.) After that only a reboot of the pCP will restore the LMS connection and control.
I usually only stream Tidal to my main system Touch and both of my Touch'es have proxied streaming set (which has always worked brilliantly), so I am unsure if Tidal direct streaming has ever worked.
This time I tried to stream Tidal to one of my pCP players on the secondary system (I had the pCP players set to Direct streaming), but that failed as described above. The current LMS 8 (1604223200 @ Sun Nov 1) has this behaviour, but also the version before - mentioned because it may be an issue with how stream parameters are transferred? I use my secondary system (LMS on Linux MX 19.2) to check new versions of LMS, before I update my main system. (Although there's never been a showstopper problem on any LMS update that I'm aware of. Incredibly stable given the amount of changes that is being released this last year.)
I updated my main system to the same version and could verify that behaviour (ie, no direct streaming to Tidal on a pCP squeezelite) is identical on this system.
Again, please note that this is not a real issue since proxied streaming works perfectly. At the most, perhaps a note in the pCP documentation?
My (secondary) system:
Logitech Media Server Version: 8.0.0 - 1604223200 @ Sun Nov 1 10:53:00 CET 2020
Hostname: intel-nuc
Server IP Address: 192.168.20.19
Server HTTP Port Number: 9000
Operating system: Debian - EN - utf8
Platform Architecture: x86_64-linux
Perl Version: 5.28.1 - x86_64-linux-gnu-thread-multi
Audio::Scan: 1.02
IO::Socket::SSL: 2.060
Database Version: DBD::SQLite 1.58 (sqlite 3.22.0)
Total Players Recognized: 2
Arbetsrum
Player Model: Squeezebox Touch
Player Type: fab4
Firmware: 7.8.0-r16754
Player IP Address: 192.168.20.7
Player MAC Address: 00:04:20:22:ee:9e
piCoreAnalog
Player Model: SqueezeLite
Player Type: squeezelite
Firmware: v1.9.7-1278-pCP
Player IP Address: 192.168.20.43
Player MAC Address: b8:27:eb:96:96:3b
pCP version: piCorePlayer v6.1.0 | www v0009 | linux 4.19.122-pcpCore_v7 | piCore v10.3pCP | Squeezelite v1.9.7-1278-pCP
Please note that this "issue" is easily fixed by setting "Proxied streaming" for the player in LMS! I'm just curious since squeezelite reports HTTPS=1 to LMS, but it still hangs with "Connecting" and is not stoppable from LMS when trying to play a Tidal track. I assume that https is relevant somehow in this case, given the changes in both Tidal and LMS. When this happens, if the page in the LMS Default skin is reloaded, the player disappears from the list of attached players. (But the pCP admin page is still working.) After that only a reboot of the pCP will restore the LMS connection and control.
I usually only stream Tidal to my main system Touch and both of my Touch'es have proxied streaming set (which has always worked brilliantly), so I am unsure if Tidal direct streaming has ever worked.
This time I tried to stream Tidal to one of my pCP players on the secondary system (I had the pCP players set to Direct streaming), but that failed as described above. The current LMS 8 (1604223200 @ Sun Nov 1) has this behaviour, but also the version before - mentioned because it may be an issue with how stream parameters are transferred? I use my secondary system (LMS on Linux MX 19.2) to check new versions of LMS, before I update my main system. (Although there's never been a showstopper problem on any LMS update that I'm aware of. Incredibly stable given the amount of changes that is being released this last year.)
I updated my main system to the same version and could verify that behaviour (ie, no direct streaming to Tidal on a pCP squeezelite) is identical on this system.
Again, please note that this is not a real issue since proxied streaming works perfectly. At the most, perhaps a note in the pCP documentation?
My (secondary) system:
Logitech Media Server Version: 8.0.0 - 1604223200 @ Sun Nov 1 10:53:00 CET 2020
Hostname: intel-nuc
Server IP Address: 192.168.20.19
Server HTTP Port Number: 9000
Operating system: Debian - EN - utf8
Platform Architecture: x86_64-linux
Perl Version: 5.28.1 - x86_64-linux-gnu-thread-multi
Audio::Scan: 1.02
IO::Socket::SSL: 2.060
Database Version: DBD::SQLite 1.58 (sqlite 3.22.0)
Total Players Recognized: 2
Arbetsrum
Player Model: Squeezebox Touch
Player Type: fab4
Firmware: 7.8.0-r16754
Player IP Address: 192.168.20.7
Player MAC Address: 00:04:20:22:ee:9e
piCoreAnalog
Player Model: SqueezeLite
Player Type: squeezelite
Firmware: v1.9.7-1278-pCP
Player IP Address: 192.168.20.43
Player MAC Address: b8:27:eb:96:96:3b
pCP version: piCorePlayer v6.1.0 | www v0009 | linux 4.19.122-pcpCore_v7 | piCore v10.3pCP | Squeezelite v1.9.7-1278-pCP