fix: resume playback on non-empty queue regardless of transport state
Removes the strict `transport_state` condition and now triggers `api.resume(id)` solely based on a non-empty queue. This improves resilience against transient or unknown device states, such as post-sleep-timer or network errors, where transport state strings may mismatch expected values but playback should still proceed.
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
[package]
|
||||
name = "PMOMusic"
|
||||
version = "0.3.49"
|
||||
version = "0.3.50"
|
||||
edition = "2024"
|
||||
|
||||
[dependencies]
|
||||
|
||||
@@ -451,11 +451,11 @@ async function resumeOrPlayFromQueue(id: string) {
|
||||
return play(id);
|
||||
}
|
||||
|
||||
// Check if queue has content
|
||||
if (
|
||||
["STOPPED", "NO_MEDIA"].includes(state.transport_state) &&
|
||||
snapshot.queue.items.length > 0
|
||||
) {
|
||||
// If queue has items, always try to play from queue regardless of transport
|
||||
// state. After a sleep timer stop, the device may report an unknown/transient
|
||||
// state ("load", network error → "UNKNOWN", etc.) that doesn't match the
|
||||
// expected "STOPPED"/"NO_MEDIA" strings, yet the queue is non-empty.
|
||||
if (snapshot.queue.items.length > 0) {
|
||||
return api.resume(id);
|
||||
}
|
||||
|
||||
|
||||
@@ -1 +1 @@
|
||||
0.3.49
|
||||
0.3.50
|
||||
|
||||
Reference in New Issue
Block a user