mirror of
https://github.com/kokarare1212/librespot-python.git
synced 2026-04-25 08:35:49 +03:00
[GH-ISSUE #52] AttributeError: 'Track' object has no attribute 'alternative_list' #3
Labels
No labels
bug
dependencies
duplicate
enhancement
invalid
pull-request
question
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot-python-kokarare1212#3
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ghost on GitHub (Jul 7, 2021).
Original GitHub issue: https://github.com/kokarare1212/librespot-python/issues/52
On playing a specific track (https://open.spotify.com/track/1peqrZv4XESUQ0oG4bWU7t) librespot crashes for some reason with the following backtrace...
@kokarare1212 commented on GitHub (Jul 8, 2021):
Thank you for your inquiry.
That error itself was fixed with
github.com/kokarare1212/librespot-python@e8f0e024d9However, in my environment, it seems to be failing to load packets, so I will investigate additionally.
@ghost commented on GitHub (Jul 8, 2021):
Thanks for the quick reply and patch, although this doesn't seem to be fixing the main problem for me, as I still get the same error.
Goodluck with the additional investigation though! :)
@kokarare1212 commented on GitHub (Jul 8, 2021):
It was a mistake.
This commit should resolve the error itself.
github.com/kokarare1212/librespot-python@e9c396b756@ghost commented on GitHub (Jul 8, 2021):
It seemed to fix that error!
Although there is a new error now in its place:
@ghost commented on GitHub (Jul 8, 2021):
I also found something interesting!
Turns out for one of the tracks that can cause librespot to crash. I managed to find/get to different url's for the exact same song, one of these urls works with librespot and the other causes the crash. Here they are if you wanna have a look for testing! :)
WORKING: https://open.spotify.com/track/2CgOd0Lj5MuvOqzqdaAXtS
BROKEN: https://open.spotify.com/track/3ISYGHoYnu4gos6JNMfL4z
@kokarare1212 commented on GitHub (Jul 8, 2021):
Yes, perhaps the broken track is failing to load packets looking for a replacement because the original track is not available.
I may be slow on bug tracking because I can't find the time.
@ghost commented on GitHub (Jul 8, 2021):
Yeah maybe. 👍 I'm great at python so I might be able to help debug this when I get time, although I wasn't the one who wrote this so I'll see how I go
@ghost commented on GitHub (Jul 10, 2021):
Interesting find, if you do an api request on a specific track that breaks, the "id" it returns in the json will actually be different, if you try to play that new track id it all play perfectly with no problems. Idk if this can help you fix the bug but you're welcome lol
@kokarare1212 commented on GitHub (Jul 20, 2021):
It was a bug in migrating the original data when using the Metadata.Track alternative.
@kokarare1212 commented on GitHub (Aug 11, 2021):
I've fixed it and will close the issue.