Crashing with my lms server #2
Comments
|
What version of the app - built from git or F-Droid? Did you try restarting the server? What server version? |
|
And most importantly: can you provide output of |
|
Running the F-Droid Build Here are the logs |
|
Also I'm trying to just get the controls of the Music assistant server in my mobile phone which the squeezer app could do but it has a lot of delay issues |
|
I've been looking for an android client for Music Assistant also. I don't have a LMS up currently, does this act as a client/endpoint for any slim protocol/squeezelite server, or is it perhaps a wrapper around a LMS server's web interface? I'm currently sharing files to MA from a NAS. |
Well i just enabled the "Slimproto (Squeezebox players)" So I think the music assistant server acts as a LMS server itself |
|
This app interacts as client to LMS' cometd server interface.
I hope for your understanding there ;-) I'll provide a test APK for making mediadirs optional, we'll see where this goes. |
|
I don't think it differs too much because it seems to be running all good in the squeezer app except for the fact that there is a bit of a delay Alright waiting for the APK |
|
I appreciate you taking the time to even make a test APK. I totally understand the complications as well as your limited time. Good luck on this project either way! |
|
(File is just named .zip due to Github's file name restrictions) This makes mediadirs optional, which in turn renders the download folder structure option 'match server' useless. If all goes well, I'll improve things there to make that option become unavailable in that case. Please let me know if this works for you, or - in case it doesn't - provide a new log. |
|
Still crashing Here's the logs: |
|
Stupid me ... note to self: don't do stuff in a hurry, it leads to mistakes :-( |
|
Thanks for the test apk :) I think it may be a lot different to the way lms works I guess because it seems to be crashing at every little minor detail
|
|
One notable difference between Squeeze Client and Squeezer that was important to me is that I made the JSON consumer as rigid as possible to get a better understanding of what input data I can rely on and what data is optional. Squeezer is more lenient in that regard, at the expense of much more complicated code (because it needs special case handling for missing values everywhere). |
|
sorry provided the same log earlier
|
|
These are the logs right before the crash |
|
Hmm, what's strange is that that JSON seems fine. Both the JSON and the stack trace before suggest it's a Can you please provide a slightly fuller log of the debug app, including the fatal stack trace (basically including a full readable version of the log entries in your screenshot)? |
|
Debug log I got right before it And fatal stack trace logs:
|
|
OK, thanks. Strangely enough your new JSON also doesn't reproduce it, but looking at MA sources hopefully got me on the right track. (Built on another machine, so signing keys might be different ... just uninstall the previous debug APK in that case) Diff so far: diff --git a/app/src/main/java/de/maniac103/squeezeclient/cometd/response/PlayerStatusResponse.kt b/app/src/main/java/de/maniac103/squeezeclient/cometd/response/PlayerStatusResponse.kt
index 4a59509..cb84bae 100644
--- a/app/src/main/java/de/maniac103/squeezeclient/cometd/response/PlayerStatusResponse.kt
+++ b/app/src/main/java/de/maniac103/squeezeclient/cometd/response/PlayerStatusResponse.kt
@@ -34,14 +34,17 @@ import kotlinx.serialization.SerialName
import kotlinx.serialization.Serializable
import kotlinx.serialization.json.Json
import kotlinx.serialization.json.JsonObject
+import kotlinx.serialization.json.JsonPrimitive
import kotlinx.serialization.json.decodeFromJsonElement
+import kotlinx.serialization.json.int
·
// offset and item_loop are not returned when fetching non-existing pages
@Serializable
data class PlayerStatusResponse(
@SerialName("mode")
val state: PlayerStatus.PlayState,
- val offset: String? = null,
+ // might be a string or a number (LMS always sends strings, MA sends "-" or numbers)
+ val offset: JsonPrimitive? = null,
val count: Int,
@SerialName("item_loop")
private val items: List<JsonObject>? = null,
@@ -122,10 +125,10 @@ data class PlayerStatusResponse(
}
·
fun asModelPlaylist(json: Json, fetchOffset: Int): Playlist {
- val actualOffset = when (offset) {
- null -> fetchOffset
- "-" -> playlistCurrentIndex
- else -> offset.toInt()
+ val actualOffset = when {
+ offset == null -> fetchOffset
+ offset.content == "-" -> playlistCurrentIndex
+ else -> offset.int
}
val (playlist, reachableCount) = if (items != null) {
val playlist = items.mapNotNull {it.asModelPlaylistItem(json, base) }
diff --git a/app/src/main/java/de/maniac103/squeezeclient/cometd/response/ServerStatusResponse.kt b/app/src/main/java/de/maniac103/squeezeclient/cometd/response/ServerStatusResponse.kt
index e51c3ca..abc8431 100644
--- a/app/src/main/java/de/maniac103/squeezeclient/cometd/response/ServerStatusResponse.kt
+++ b/app/src/main/java/de/maniac103/squeezeclient/cometd/response/ServerStatusResponse.kt
@@ -25,7 +25,9 @@ import kotlinx.serialization.Serializable
data class ServerStatusResponse(
val version: String,
@SerialName("players_loop")
+ // players_loop is omitted if there are no players
val players: List<Player> = emptyList(),
@SerialName("mediadirs")
- val mediaDirectories: List<String>
+ // LMS sends those (with valid contents), MA doesn't
+ val mediaDirectories: List<String> = emptyList()
) |
|
Finally! It stopped crashing I don't think there is any point of trying to make it compatible with music assistant |
|
Also I get this message out of nowhere a lot of times |
|
Well, a log would help ;-) |
|
Here you go: |
|
Also, after playing around a bit, I can definitely say that the app is working way better than the Squeezer app. However, I'm not sure wheather the delay in updating the squeeze client app normal behaviour Like in this video when I pressed the play pause button it did work and paused the music but it never updated in the app until I forced tap and restarted the app screen-20240826-214514.mp4 |
|
This sounds like player status updates aren't sent as expected. Unlike Squeezer I'm not trying to 'predict' server responses to commands for updating the UI, but wait for the server sending an update event as kind of acknowledgement. |
|
The xonnection lost error I keep getting out of nowhere |
|
By log I was referring to the full log generated by the app, not only stack traces and warnings ;-) In particular, I'm interested in the messages exchanged between app and server.
I want to see the communication to confirm the assumptions. If they hold true, I guess that's a topic for the MA folks to solve; I don't want to adopt for that in the app because it means restructuring a lot of stuff. If they don't hold true, we'll need to see what else is off there. |
I fixed this one via 3229162 |
|
Hey sorry for the late response, I also noticed that if there is nothing playing or in the queue the app keeps crashing |
|
The crashing is because they omit parts of the player status response if a given player is not powered, unlike LMS (example). I'd consider this an MA bug, but I can work around that (and probably should review LMS code as well to see what properties actually might be optional). The larger issue is the update events, where, if I'm reading the code here correctly, determine the type of events to be sent (and whether to send events at all) by interpreting the channel names the client subscribed for instead of looking at the subscription itself. In particular, they seem to expect the player ID as part of the channel name in its original MAC address form ( |
|
At this point I agree that a rollup of this thread should be posted to the MA Git issues. Perhaps some modifications to the Lyrion "light" server should be made. I wonder if it has been tested with many squeezebox devices. I agree out of all the protocols offered by MA, slimproto is the most feature complete. And it could spark interest in the squeezebox used market. I haven't been involved in the testing of the client so I'm not the person to bring their attention to it. If further assistance in testing is needed message me. I've got several "ThinkView Smart"s running lineageOS that i need a simple solution like this for. |
haha, i also got 3 thinksmart view devices to run this, but the app is crashing as soon as i try to connect to home assistant. (slimproto integration) There is a well working SB Player app in the play store thats just 4 euro or so, however it disconnects and wont reconnect after some time, even with all settings to prevent the app from closing. i want to use this for notification sounds, so disconnects are sad. |
|
Which SB app are you referring to? |
Thats literary the name of it. SB Player. It also connects to home assistant slimproto. but it disconnects quite often at seemingly random times, and does not try to reconnect. |
Did you try using Music Assistant? Check their documentation for player, you cannot have the slimproto integration cannot run side by side with MA. Strangely MA doesn't use LMS as a music source, so I'm not sure what is going on with that. |
|
it seems this issue is a lot less common with the slimproto in music assistant, compared to slimproto without using music assistant. weird. |
Crashing constanly
The text was updated successfully, but these errors were encountered: