starred/librespot-android

Fork 0

mirror of https://github.com/devgianlu/librespot-android.git synced 2026-04-26 05:45:50 +03:00

[GH-ISSUE #19] Some error #13

New issue

Closed

opened 2026-02-28 14:24:03 +03:00 by kerem · 8 comments

kerem commented

2026-02-28 14:24:03 +03:00

Owner

Originally created by @JShaoLee on GitHub (Jul 1, 2022).
Original GitHub issue: https://github.com/devgianlu/librespot-android/issues/19

Hi, I use mobile phone A to connect to another mobile phone B through spotify, and mobile phone B has the current demo installed. When I use mobile phone A to cut songs, the demo program of mobile phone B will report an error and crash: I don't know how to solve it:

Originally created by @JShaoLee on GitHub (Jul 1, 2022). Original GitHub issue: https://github.com/devgianlu/librespot-android/issues/19 Hi, I use mobile phone A to connect to another mobile phone B through spotify, and mobile phone B has the current demo installed. When I use mobile phone A to cut songs, the demo program of mobile phone B will report an error and crash: I don't know how to solve it: ![1656668674753](https://user-images.githubusercontent.com/40627554/176870870-c3869547-8b7b-4027-98d9-d5f943bff60e.jpg)

kerem closed this issue

2026-02-28 14:24:03 +03:00

kerem commented

2026-02-28 14:24:04 +03:00

Author

Owner

@mitschwimmer commented on GitHub (Jul 2, 2022):

Hi @JShaoLee, I am assuming that phone A has the regular spotifiy client and phone B is using librespot-android and that you are on both phones logged in using the same premium spotify user.
So, the first question would be, is this usecase supported by librespot-java? Because the original spotify app has implemented some user interaction (and possibly session transfer workflow) to decide which player instance is dominant.
If this "transfer" is not supported by upstream librespot, than best you can do is make sure the app is not crashing.

@mitschwimmer commented on GitHub (Jul 2, 2022): Hi @JShaoLee, I am assuming that phone A has the regular spotifiy client and phone B is using librespot-android and that you are on both phones logged in using the same premium spotify user. So, the first question would be, is this usecase supported by librespot-java? Because the original spotify app has implemented some user interaction (and possibly session transfer workflow) to decide which player instance is dominant. If this "transfer" is not supported by upstream librespot, than best you can do is make sure the app is not crashing.

kerem commented

2026-02-28 14:24:04 +03:00

Author

Owner

@JShaoLee commented on GitHub (Jul 4, 2022):

Hi @mitschwimmer ,librespot-java supports this use case. phone A pushes the song to phone B for playback. phone A acts as the control terminal. It is no problem to pause the playback and seek the position, but as long as the song is cut, the above abnormal information will be reported.

@JShaoLee commented on GitHub (Jul 4, 2022): Hi @mitschwimmer ,librespot-java supports this use case. phone A pushes the song to phone B for playback. phone A acts as the control terminal. It is no problem to pause the playback and seek the position, but as long as the song is cut, the above abnormal information will be reported.

kerem commented

2026-02-28 14:24:04 +03:00

Author

Owner

@mitschwimmer commented on GitHub (Jul 4, 2022):

Hm. Can you give some context what you mean by "cut"? Stopping it? Picking another song to play?

@mitschwimmer commented on GitHub (Jul 4, 2022): Hm. Can you give some context what you mean by "cut"? Stopping it? Picking another song to play?

kerem commented

2026-02-28 14:24:04 +03:00

Author

Owner

@JShaoLee commented on GitHub (Jul 5, 2022):

@mitschwimmer sorry,my english not good, I mean Picking another song to play.

@JShaoLee commented on GitHub (Jul 5, 2022): @mitschwimmer sorry,my english not good, I mean Picking another song to play.

kerem commented

2026-02-28 14:24:04 +03:00

Author

Owner

@powerbling commented on GitHub (Dec 21, 2022):

I too encountered this issue.

When changing tracks, either by skipping or going back or by choosing another track, the app crashes with error:
A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 24868 (player-queue-84), pid 13729 (brespot.android)

@powerbling commented on GitHub (Dec 21, 2022): I too encountered this issue. When changing tracks, either by skipping or going back or by choosing another track, the app crashes with error: `A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 24868 (player-queue-84), pid 13729 (brespot.android)`

kerem commented

2026-02-28 14:24:04 +03:00

Author

Owner

@powerbling commented on GitHub (Dec 22, 2022):

I might have found a workaround.
By disabling lines 19 to 22 in LibrespotApp.java I don't encounter the problem anymore.
code:


        if (isArm()) {
            Decoders.registerDecoder(SuperAudioFormat.VORBIS, 0, TremoloVorbisDecoder.class);
            Log.i(TAG, "Using ARM optimized Vorbis decoder");
        }

It seems to be a problem in the arm optimized vorbis decoder.
I don't know how much of a performance improvement the hardware accelerated decoder brings but I don't think that it would be a big deal for the average user.
At least until someone comes around to fix it.
I don't have much time and sufficient knowledge both in the decoder implementation and in using Java/JNI to try and do it myself.
Hope this helps!

@powerbling commented on GitHub (Dec 22, 2022): I might have found a workaround. By disabling lines 19 to 22 in `LibrespotApp.java` I don't encounter the problem anymore. code: ```java if (isArm()) { Decoders.registerDecoder(SuperAudioFormat.VORBIS, 0, TremoloVorbisDecoder.class); Log.i(TAG, "Using ARM optimized Vorbis decoder"); } ``` It seems to be a problem in the arm optimized vorbis decoder. I don't know how much of a performance improvement the hardware accelerated decoder brings but I don't think that it would be a big deal for the average user. At least until someone comes around to fix it. I don't have much time and sufficient knowledge both in the decoder implementation and in using Java/JNI to try and do it myself. Hope this helps!

kerem commented

2026-02-28 14:24:04 +03:00

Author

Owner

@mitschwimmer commented on GitHub (Jan 31, 2023):

@powerbling thank you for providing a workaround. #20 does fix this probably by avoiding Tremolo by default.

@mitschwimmer commented on GitHub (Jan 31, 2023): @powerbling thank you for providing a workaround. #20 does fix this probably by avoiding Tremolo by default.

kerem commented

2026-02-28 14:24:04 +03:00

Author

Owner

@0xf4b1 commented on GitHub (Jan 31, 2023):

A quick note: In #20, I fixed the priorities to use AndroidNativeDecoder before build-in decoders (e.g. jogg) but the tremolo decoder is still the default, so now it is like it was intended Tremolo (arm only) -> AndroidNativeDecoder -> build-in ones.

@0xf4b1 commented on GitHub (Jan 31, 2023): A quick note: In #20, I fixed the priorities to use AndroidNativeDecoder before build-in decoders (e.g. jogg) but the tremolo decoder is still the default, so now it is like it was intended Tremolo (arm only) -> AndroidNativeDecoder -> build-in ones.

No labels

bug

enhancement

pull-request

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-android#13

No description provided.

Rows
Columns