8.5.0: "Bad Vorbis Header" or "Ran out of decoder memory" on MANY ogg/vorbis tracks that used to play fine on 8.3.1
GeldHades27355 opened this issue · 14 comments
Team, I just upgraded to 8.5.0, because my 8.3.1 Windows installation was ... acting up.
Other observations aside, I immediately found a vorbis track in my collection that fails playback with "Bad Vorbis Header" on my Squeeze Box Booms. Since Github doesn't seem to allow attaching .ogg files, please get the track in question from here: https://1drv.ms/u/s!AoQI5_3ipPc6pol67ohJNGRuj9YuTA?e=kHHj1O
The track instantly fails, before it begins playback. The log says
[24-04-05 13:53:55.5373] Slim::Player::Squeezebox2::statHandler (155) Error: 00:04:20:1f:7f:b8: Decoder does not support file format, code 104
Which is odd, because it is an ogg/vorbis file which played fine on 8.3.1, as well as any other player I have.
No transcoding, using native playback only.
Plays fine when transcoding to PCM.
That being said, I'm also getting:
24-04-05 13:55:38.1005] Slim::Utils::Firmware::downloadAsyncError (500) Warning: Firmware: Failed to download http://update.slimdevices.com/update/firmware/8.5.0/boom_57.bin (Couldn't resolve IP address for: update.slimdevices.com), will try again in 20 minutes
and
mysqueezebox.com returns connection refused right now.
somehow related?
Some additional info: turns out that fully 1/3-1/2 of my vorbis collection fails native playback now. The errors are various:
"Ran out of decoder memory"
"Bad vorbis header" or no error, except garbled/jumbled display.
I tried resetting the Xilinx as well as a factory reset with no change.
What about vorbis playback changed since 8.3.x?
Let me know what I can do help trace this.
@philippe44 Does that ring a bell?
As for the firmware download issue: what platform are you on?
@michaelherger I'm on Windows 10, latest release build 19045.4170.
update.slimdevices.com doesn't even resolve DNS right now, so I don't think it is a platform or device issue.
That being said, there shoudn't be any (newer) firmware do download anyways, should there? Booms have been out of support for... years.
Maybe to get started:
I recall discussions in the past regarding issues with embedded albumart and the legacy/native/firmware decoders being particularly ... picky about sizes and formats. Did something there change?
Oh, I didn't remember we no longer ship the firmware binaries... but would you have a Boom which wasn't on the latest firmware from 10-12 years ago? What firmwares are your boom using? And are the issues you're seeing with Ogg limited to those Booms?
The last update my Booms got was V57. And no, they're all on the latest, since LMS/Slimserver always immediately updated slimdevice players instantly with each new release. I remember they were so tightly integrated that you often couldn't even operate legacy squeezeboxes unless they updated in line with LMS.
Maybe I can find an old SB3 / Classic that still works. But I don't think that'll tell us much, since SB classic and Boom were very different in hardware and firmware.
AFAIK the player firmware was never open sourced, so development ended when Logitech ended the product line.
Did you double check the firmware version? LMS would NOT try to download the firmware image if the device already was up to date. If you're always getting the download error, please shut down the device, restart LMS, enable debug logging for player.firmware, then fire up the Boom again. It should then report the firmware version it's using and why LMS thinks it needed to download the firmware image.
@philippe44 Does that ring a bell?
As for the firmware download issue: what platform are you on?
No, not really because the modifications I did are in the audio:scan and in squeezelite. Can the OP share the file?
Did you double check the firmware version? LMS would NOT try to download the firmware image if the device already was up to date. If you're always getting the download error, please shut down the device, restart LMS, enable debug logging for player.firmware, then fire up the Boom again. It should then report the firmware version it's using and why LMS thinks it needed to download the firmware image.
I did, and they're on 57. Which is also what lms appears to attempt to download.
Enabling logging won't help imho since the domain it points to is unavailable.
@philippe44 Does that ring a bell?
As for the firmware download issue: what platform are you on?No, not really because the modifications I did are in the audio:scan and in squeezelite. Can the OP share the file?
I did. The link is in the first post.
I miss that. I'll have a look shortly
That file does not play on my Boom, on 8.3.0 (Linux) or 8.5.1 (Win64 or Linux). It plays on any squeezelite instance, Linux or embedded (esp32). The vorbis error code is : Negative or zero granulepos (-104) which means that indeed the vorbis decoder of the Boom fails. Most logical explanation is that you had a rule in the past that blocked Ogg to be natively sent to this player and it got kicked in the LMS upgrade.
That's odd. I'm very sure (although not 100%) that I forced native vorbis playback...
In any case, my library was encoded with the same encoder, same converter and same settings for years. Strange that all of a sudden a large number of them get rejected.
Am I right to assume tracing and fixing this will be between hard and impossible - due to player firmware being frozen ten years ago?
If this is (as it seems to be) a firmware issue, yes I'm not aware of any way to fix it. Again, I checked and on my Boom, it's just the transparent sending of the ogg file, nothing added / changed.
Thought so. Well, regardless of whether and what changed, it seems that transcoding to PCM works. Since I can't seem to find an important reason for native decoding, I'm willing to close this issue for now and use transcoding as a workaround. I'll re-open if something else comes up. Thanks for the help!