[PR #483] [MERGED] Don't send kPlayStatusLoading. #945

New issue

Closed

opened 2026-02-27 20:00:33 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 20:00:33 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/librespot-org/librespot/pull/483
Author: @kaymes
Created: 5/26/2020
Status: ✅ Merged
Merged: 5/27/2020
Merged by: @ashthespy

Base: dev ← Head: dont-send-kPlayStatusLoading

📝 Commits (1)

351e206 Don't send kPlayStatusLoading.

📊 Changes

1 file changed (+2 additions, -1 deletions)

View changed files

📝 connect/src/spirc.rs (+2 -1)

📄 Description

It seems like Spotify changed the way the app behaves for kPlayStatusLoading. When I wrote this code, I tested it quite a bit with the desktop client (Linux) and the Android app. The behaviour for kPlayStatusLoading was that the desktop client would grey out the progress bar and the Android app just ignored it.
My understanding of kPlayStatusLoading was that it should be sent while loading a track but not yet playing it, so that's what I programmed.

With the new behaviour of the app, it seems like my interpretation of kPlayStatusLoading was wrong because the way the app behaves is indeed annoying and doesn't make sense when loading a track. Maybe it is intended to be sent during the start-up phase of a user-controlled client. I don't know.

In any case, librespot should probably refrain from using kPlayStatusLoading for now.

This PR changes the behaviour such that instead of kPlayStatusLoading a kPlayStatusPlay or kPlayStatusPaused is sent. When the track is actually loaded, the status is sent again (as before) so the timing is corrected.

The behaviour is that when you start to play a track, the progress bar in the client starts moving even though librespot is still loading. Once the track is loaded the bar jumps back to the correct position.

Not 100% clean but this was the behaviour of the app before Spotify changed it. Thus it should solve #461.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/librespot-org/librespot/pull/483 **Author:** [@kaymes](https://github.com/kaymes) **Created:** 5/26/2020 **Status:** ✅ Merged **Merged:** 5/27/2020 **Merged by:** [@ashthespy](https://github.com/ashthespy) **Base:** `dev` ← **Head:** `dont-send-kPlayStatusLoading` --- ### 📝 Commits (1) - [`351e206`](https://github.com/librespot-org/librespot/commit/351e20653d68bfdfd2098141d92c61f92bedd2f8) Don't send kPlayStatusLoading. ### 📊 Changes **1 file changed** (+2 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `connect/src/spirc.rs` (+2 -1) </details> ### 📄 Description It seems like Spotify changed the way the app behaves for kPlayStatusLoading. When I wrote this code, I tested it quite a bit with the desktop client (Linux) and the Android app. The behaviour for kPlayStatusLoading was that the desktop client would grey out the progress bar and the Android app just ignored it. My understanding of kPlayStatusLoading was that it should be sent while loading a track but not yet playing it, so that's what I programmed. With the new behaviour of the app, it seems like my interpretation of kPlayStatusLoading was wrong because the way the app behaves is indeed annoying and doesn't make sense when loading a track. Maybe it is intended to be sent during the start-up phase of a user-controlled client. I don't know. In any case, librespot should probably refrain from using kPlayStatusLoading for now. This PR changes the behaviour such that instead of kPlayStatusLoading a kPlayStatusPlay or kPlayStatusPaused is sent. When the track is actually loaded, the status is sent again (as before) so the timing is corrected. The behaviour is that when you start to play a track, the progress bar in the client starts moving even though librespot is still loading. Once the track is loaded the bar jumps back to the correct position. Not 100% clean but this was the behaviour of the app before Spotify changed it. Thus it should solve #461. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

kerem

2026-02-27 20:00:33 +03:00

closed this issue
added the
pull-request
label

kerem referenced this issue

2026-02-27 20:01:23 +03:00

[PR #945] [MERGED] Add more connectivity.proto fields #1155

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/librespot#945

No description provided.

Rows
Columns