You can check the hashes and cryptographic signature if you prefer (all the packages are signed). But the error is about wget not understanding the web server’s headers correctly.
But you are downloading from the backup server, why not download from the primary server instead?
I set up a Raspberry Pi 4 with HQPlayer OS, and it seems to work.
This will be for my study, and I need only up to PCM 192/24.
I will have a Digi One Hat adaptor delivered tomorrow so that I will be able to use the coaxial digital output with the Pi 4.
I’ve just tested as trial, and I wonder whether it is possible to group music with the existing HQPe and the new HQP OS, possibly on roon.
Let me know if there’s a way.
If things work, I’ll purchase another license for the second device.
You can certainly have multiple HQPlayer zones in Roon, I have. But it is not possible to play to those simultaneously. So no multi-room that way from Roon side.
HQPlayer can play to multiple NAA’s though, but these need to use a common output format.
Here’s what I’d love to be able to do. I have one HQPlayer Embedded server. I’d like to have two NAA endpoints for two different DACs, with different HQPlayer configurations. Switching between the two endpoints would automatically switch HQPlayer configurations. Even better it would be if the HQPlayer server could present two different IP/port choices to Roon, so that the whole thing could be controlled by switching output devices on Roon.
That is already what you get with HQPlayer configuration profiles. When you switch the configuration, all configuration items are switched (including all matrix profiles). But the library remains the same.
Just a tip to everybody encountering dropouts and other issues like that. I have spent months tracking these… tested a ton of deferent hardware, the outcome is meh. Some distributions, particularly ubuntu 24.04 LTS do not have flow control enabled by default on the ethernet interface, can anyone believe that ?
Even if the entire network is IEEE 802.3x enabled, manual checking every ethernet interface would be a wise move.
Default setting for the flow control depends on the particular Ethernet interface driver. For example Intel drivers on Linux and Intel enable it by default. But not necessarily all others.
It is also good to remember that for the feature to become enabled, both ends of each cable must correctly participate on the low level hardware negotiation of the feature. For example if it is disabled from the switch settings, then computers connected to the switch won’t have the feature enabled since the negotiation fails.
Most common issue audiophiles encounter on this are misconfigured smart switches and optical SFP modules that lack support for the feature.
I am experiencing intermittent dropouts since I switched over to using an opticalrendu. How can I find out if this is being caused by my sfp modules?
Thanks
I bought a used optical rendu a few years ago. I would get random network drops. I tried different sfp cards, cables, switches, network tweaking etc. I gave up and it now sits unused in a closet. The Ultrarendu on the other hand works perfectly as NAA in the same spot.
It’s my contention that the earlier optical models had problems, not sure about newer ones. I ran the optical rendu on v2.8 and v2.9 software, no change to flakey network drops.
I even got root on the optical rendu to monitor things. From what I can recall, it seems it would reset it’s sfp/network after a period of time/usage indicating saturation of some type.
This is only my opinion and I spent way too much time looking at the issue.
Thanks for your reply. Part of my problem is that the stuttering dropouts are completely unpredictable. I am using HQPlayer so thought it might be related to the specific settings I am using but then I still get the dropouts without HQPlayer in the equation just as a Roon endpoint. Then this morning HQPlayer has been playing fine for about three hours after a short stutter after 15 minutes and a change of HQPlayer settings.
According to the above there may be some sort of flow control problem but I’m not sure what I could do about this. I have an unmanaged switch in the equation and I gather that the sfp modules cannot be altered. Your response has made me think about returning the orendu. I only purchased it before Christmas but surely we are not the only two people with this problem. Btw mine is the newest version hardware with 2.9 software. Anyone got any suggestions?
It is important to check that the SFP modules in question support 802.3x flow control handshake. Not all modules do, if the handshake fails the feature doesn’t work and causes network packet buffer overflows in Rendu, which in turn requires retransmission of the data, which increases amount of traffic, which increases packet buffer overflows, which in turn requires more retransmissions… This goes on until the connection stalls and then starts again from fresh.
The local bus inside the SoC used in Rendu that connects ethernet interface to the CPU is capable of max 400 Mbps bandwidth. While the ethernet controller is 1 Gbps. So it cannot pass full 1 Gbps worth of traffic to the CPU. Only hardware flow control inside the ethernet controller (802.3x) can avoid packet loss at this point, as it knows how many packets it has on buffer and can ask the switch to stop sending when it sees it’s buffer becoming full. It is also capable of reacting within the ethernet frame timing.
This same applies RJ45 copper ethernet connections, but there the Rendu’s ethernet controller doesn’t have SFP modules in between. So 802.3x flow control is equally important. Unmanaged switches quite systematically support 802.3x.
Ok, I got the optical rendu out of storage, set it up and am now using it usb out to AH90 → SDM 256. 5.1.5 NAA, OS up to date, Cisco switch, HQPe 5.16.1
Having used it for a couple of songs I got my first network drop and restart.
I notice RX errors slowly increasing and then a drop and reset. It didn’t take long, had two drops in 10 mins.
[root@OR ~]# dmesg
[ 1638.461760] fec 2188000.ethernet eth0: Link is Down
[ 1641.533863] fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
Back into storage it goes unless you have any ideas.
You can see flow control is active and I am using their recommended sfp card.
After last drop its playing fine but ifconfig now says:
RX errors 163 dropped 0 overruns 34 frame 129
It will eventually drop again.
Jussi thanks for your reply. I think my fsp modules are ok but I am checking further. The system has played faultlessly all day from 8 am this morning but then this afternoon I switched on Roon radio and a little later my mini dropouts, stuttering occurred so I tried to record them which I did. Normally I have been stopping playback as soon as this occurs but I let them continue through to the next track at which point there was a long pause and then the next track played perfectly. I think there may be a problem when the system is asked to change formats. I shall prepare a playlist with all sorts of different resolutions and see if that triggers the problem, if so any suggestions for settings in Roon or HQPlayer that might help resolve the problem?
System is Sonicorbiter - ee16 switch - fibre to optical converter- opticalrendu - src-dx - dual BNC - chord Hugo tt2
I only use pcm conversion to 705/768 and usually lns15 with sinc m & sincL
Hope this helps
For some reason, poly-sinc-xtr-short-lp and -mp are not working when trying to convert 44.1 → 512x48 in my setup. 48 → 512x44.1 works fine as do other integral and non-integral ratios.
All other 1x filters I tried work fine for 44.1 → 512x48, including ext2-xx, gauss-long, as well as the -2s two stage versions of poly-sinc-xtr-short-
As per below logs, it just hangs for a minute and then HQPe restarts. Am I missing something obvious here or is there a bug?!