mirror of
https://github.com/lox-audioserver/lox-audioserver.git
synced 2026-04-26 06:45:47 +03:00
[GH-ISSUE #160] Radio Paradise playback Error on Rock mix #88
Labels
No labels
bug
enhancement
pull-request
released
released on @beta
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/lox-audioserver#88
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Holzmusik on GitHub (Feb 12, 2026).
Original GitHub issue: https://github.com/lox-audioserver/lox-audioserver/issues/160
When starting playback of the Radio Paradise Rock stream, the error shown in the log file occurs very frequently. It's strange that it sometimes works. Could the problem be with Radio Paradise itself?
lox-audioserver-logs-2026-02-12T22-39-50-092Z.txt
@Holzmusik commented on GitHub (Feb 13, 2026):
Another thing I noticed today: When I start a Radio Paradise stream via the Loxone app, only one track plays, followed by the short announcement "You are listening to Radio Paradise Rock Mix...". After that, the next track sometimes plays, but most of the time playback stops completely. The announcement described above usually only comes after a whole block of tracks, not after a single track.
For testing purposes, I added the stream URL from the Loxone Audio Server source code as a custom stream. When I start this stream, everything works as expected with Radio Paradise. Could it possibly be related to the metadata query?
@rudyberends commented on GitHub (Feb 13, 2026):
The issue isn’t in the stream itself, but in how blocks/tracks are skipped. That’s why direct stream playback works fine, but you lose proper station control (skip/revert).
I believe I have a working fix that handles block/track skipping in a better way. I’ll include it in the next beta.
@Holzmusik commented on GitHub (Feb 13, 2026):
Okay, yes, that makes sense; I hadn't even considered the interactive controls. That also explains why the stream restarts when I fast-forward to the next track. I'm looking forward to the fix and will gladly continue testing. 👍😉
@rudyberends commented on GitHub (Feb 13, 2026):
You do see the player controls, correct? Even without the fix, it should work better than you describe. Skipping tracks should work and should also resolve your initial playback issue.
The short announcement has a reported duration of roughly 90 minutes, which is why you don’t hear anything after it finishes. Skipping to the next track will resume normal playback.
The upcoming fix will address these issues more cleanly. However, if you do not see player controls or they are not functioning, then there is a different issue that needs to be investigated.
@Holzmusik commented on GitHub (Feb 13, 2026):
Unfortunately, it's not quite as you described. I start playback, the track plays through, an announcement comes, I skip to the next track, which plays for about 2 minutes, then the next announcement comes...
@rudyberends commented on GitHub (Feb 13, 2026):
That is not the intended behavior, even without the fix. It’s possible that an older version of the code was accidentally included in beta5.
Never mind. Just test the latest release when its available and see if it resolves you issues
@Holzmusik commented on GitHub (Feb 15, 2026):
I just installed the latest beta from this morning... Very cool! So far, everything is running really well!
One more question, maybe a silly one: does the FLAC stream arrive at the player as is, if it supports FLAC, or is it converted along the way? 🙈
Thanks so much for the great work! Is there any way I can support you?
@rudyberends commented on GitHub (Feb 15, 2026):
At the moment, the audio engine decodes the input FLAC to PCM (the internal engine format), and for Squeezelite it is then encoded back to FLAC. This means it is not bit-perfect. Whether this is actually audible is a separate question and will also depend on the player and speakers used.
I do have a separate branch focused purely on audio quality, using bitstream passthrough wherever possible. However, the priority is to release version 4 with a strong focus on stability and full feature completeness. After that, audio quality optimization will become the main focus.
@Holzmusik commented on GitHub (Feb 16, 2026):
Unfortunately, I have to reopen this bug report. I think it's just a minor issue, though. Playback now takes significantly longer than in the last version. It seems that the songs aren't playing smoothly to the end. Shortly before the end of each song, there's a jump to the next track. As I said, it's just a minor issue and not a huge problem, but perhaps you could check if there might be a timing issue.
@rudyberends commented on GitHub (Feb 16, 2026):
The specific cutoff at the end is already fixed in 52dffca. This also resolves the issue where the announcement duration was reported as over an hour.
I cannot reproduce the “significantly longer” startup time you’re seeing, even with a Squeezelite output. I did increase the Squeezelite buffer, which was necessary for more reliable group playback. That will cause a slightly slower start, but it should not be a significant delay.
@Holzmusik commented on GitHub (Feb 16, 2026):
Hello, I think there's been a misunderstanding in the translation. I didn't mean that playback takes longer to start, but rather that the music now plays significantly longer across multiple tracks without stopping. However, the end of each track is still a few seconds shorter. It has also happened again that the announcement displays over 90 minutes, and the next track is delayed for that long.
To summarize briefly:
@rudyberends commented on GitHub (Feb 16, 2026):
Ah, yes then I can confirm that exact behaviour. 😁
This is exactly what was fixed in 52dffca.
This patch is on the dev branch and is not part of the current beta. It will be included in the next one.
If you want to try it you can pull the dev branch, or I can create a testing container containing the specific patch if that's more convenient for you.
@Holzmusik commented on GitHub (Feb 16, 2026):
No problem, I'll install the latest development version as soon as I have time.