Forum Replies Created
-
Posted in: Allo USB Bundle
-
12. Juni 2019 at 10:59 #45691
Thanks for the reply.
Okay, well, the strange thing is that I could also reach it on the local network, despite this wifi only statement, but I couldn’t disable the write protection. Maybe I was just looking at a series of cached pages 🙂
Anyway, I hooked it up to the LAN and fixed it that way. So, problem (whatever it was) solved.
8. Oktober 2018 at 14:27 #38446Found it, while looking at the DEBUG output, I noticed the –initial-volume option for librespot.
Added--initial-volume 100
to the Command Line Options, didn’t turn back the volume on the receiver and was blown off my chair 😉Yes, it works now. Even after reboot, even after removing hw:1 from the command line options. All that was needed was the
--initial-volume
option. Case closed 🙂Update: fwiw, –initial-volume 90 brings it more in line with the DAB volume, but that’s fine-tuning.
- This reply was modified 6 years, 1 month ago by kraker.
8. Oktober 2018 at 14:06 #38440Okay, removed the automatic player switch, rechecked that no other audio player is running.
I was about to say: still no sound, when I noticed, far away in the distance, some sound. Turned up the volume, and yes, spotify IS playing (and may have been playing from the beginning), only the volume is absurdly low.So now the question becomes, why is that, and how can that be fixed? Again, if I try MPD, volume 12 on my receiver is already louder than I would normally play it. For Spotify, I can crank it up to about 50 to get to that same level.
8. Oktober 2018 at 13:02 #38434Hello Heiner,
Thanks for the response. Unfortunately, still no sound after trying that.
/opt/spotifyconnect/librespot –name max2play –disable-discovery –cache /tmp –bitrate 320 –username *** –password *** –device hw:sndrpihifiberry hw:0 –onevent /opt/spotifyconnect/onevent_switch.sh
This results in two hw: devices in the command line, by the way, which may not be what you had in mind?
Any other thoughts on this?
3. März 2018 at 13:23 #34192So, I decided to give that new beta a try, Version Beta-180301 on Raspberry PI B+, and have spent some hours pulling my hair out since then.
Even with the google DNS hack in place, I have no internet on the max2play after installing this beta.
Well, that means, no DNS, because I can connect to it via webinterface and ssh without a problem, so the connection is there, but pinging a server by name from the raspberry gives an „unknown host“ error.Did a full reinstall this morning, first trying to get it all working without installing a beta release, but all I got at first was the illegal instruction for librespot, and then, after following the instruction from arch above (https://www.max2play.com/en/forums/topic/spotify-connect-does-not-start/#post-33354), all I got when trying to start spotify connect was
hread ‚main‘ panicked at ‚called
Result::unwrap()
on anErr
value: WireError(„invalid value for enum: 13“)Googling for this doesn’t help me much, just a few hits on GitHub with too much tech details (even though I think of myself as tech savvy).
After the first reboot on the beta release, I get the no internet error, persistently…
So… basically, now I can start over again with installing, but then I will still not be able to use spotify connect, which for me was the whole point of using max2play…
Any hints welcome! Basically, without internet access (without a functioning DNS), this thing is useless…
If there’s any useful logging I can get, let me know.If only I hadn’t tried out the latest beta, I would still be enjoying spotify connect. Is there a way to go back to the previous beta?
- This reply was modified 6 years, 8 months ago by kraker. Reason: minor addition
6. Februar 2018 at 1:11 #33874Installing the latest Beta does NOT solve the issue for me. I’m on Version Beta-180131 on a Raspberry PI B+.
Luckily, the solution/workaround suggested by Arci (replacing librespot) works fine for me.
-