[BUG] Change in Metadata : Cause "Cannot get alternative track"

[Scrameupeutchi]

Describe the bug
While we were used to encounter this bug due to various circumstances in the past, here it comes again since a few hours, preventing the use of the library. The now usual dreaded error message is appearing :

Traceback (most recent call last):
  File "/home/scrameupeutchi/.local/share/pipx/venvs/zotify/lib/python3.12/site-packages/zotify/track.py", line 304, in download_track
    stream = Zotify.get_content_stream(track, Zotify.DOWNLOAD_QUALITY)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/scrameupeutchi/.local/share/pipx/venvs/zotify/lib/python3.12/site-packages/zotify/zotify.py", line 53, in get_content_stream
    return cls.SESSION.content_feeder().load(content_id, VorbisOnlyAudioQuality(quality), False, None)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/scrameupeutchi/.local/share/pipx/venvs/zotify/lib/python3.12/site-packages/librespot/audio/__init__.py", line 771, in load
    return self.load_track(playable_id, audio_quality_picker, preload,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/scrameupeutchi/.local/share/pipx/venvs/zotify/lib/python3.12/site-packages/librespot/audio/__init__.py", line 825, in load_track
    raise RuntimeError("Cannot get alternative track")
RuntimeError: Cannot get alternative track

From what I could understand from the way the track's URL is retrieved, the Metadata should contain a "file" field to get the information from. However, the result I'm getting in debug does not seems to include that parameter anymore :

> id: "v\335\317\256TGG\216\242\'i\032A\200\253\030"
> name: "Butterfly"
> album {
>   gid: "{\341\320\325E(GT\216P\214\234\273\254[N"
>   name: "Smile"
>   artist {
>     gid: "\030\206\261\217\231\361G:\202\3048\330F\334\023\361"
>     name: "SMiLE.dk"
>   }
>   label: "Parlophone Denmark"
>   date {
>     year: 1998
>     month: 7
>     day: 13
>   }
>   cover_group {
>     image {
>       file_id: "\253gam\000\000\036\002\326j\306id-u\333\265)E\253"
>       size: DEFAULT
>       width: 300
>       height: 300
>     }
>     image {
>       file_id: "\253gam\000\000HQ\326j\306id-u\333\265)E\253"
>       size: SMALL
>       width: 64
>       height: 64
>     }
>     image {
>       file_id: "\253gam\000\000\262s\326j\306id-u\333\265)E\253"
>       size: LARGE
>       width: 640
>       height: 640
>     }
>   }
> }
> artist {
>   gid: "\030\206\261\217\231\361G:\202\3048\330F\334\023\361"
>   name: "SMiLE.dk"
> }
> number: 1
> disc_number: 1
> duration: 177453
> popularity: 64
> external_id {
>   type: "isrc"
>   id: "DKABA9814003"
> }
> earliest_live_timestamp: 413146860
> has_lyrics: true
> licensor {
>   uuid: "\2037\246\256\254\247D\247\263 P\360\306n\023\217"
> }

And then, the value of Metadata.Track is None. No alternatives could be found either.
Looks Spotify is still up to shenanigans, let's hope we can find an alternative.

To Reproduce
Steps to reproduce the behavior:

1. Use librespot-python (last version)
2. Try to get a track
3. It won't get through

Expected behavior
The track is downloaded and converted if needed.

Client Information (please complete the following information):

• OS: Linux Mint 22.04
• Python Version : 3.12.3
• Library Version Last main branch revision

Additional context
Add any other context about the problem here.

[shayanmaher]

Describe the bug While we were used to encounter this bug due to various circumstances in the past, here it comes again since a few hours, preventing the use of the library. The now usual dreaded error message is appearing :

Traceback (most recent call last):
  File "/home/scrameupeutchi/.local/share/pipx/venvs/zotify/lib/python3.12/site-packages/zotify/track.py", line 304, in download_track
    stream = Zotify.get_content_stream(track, Zotify.DOWNLOAD_QUALITY)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/scrameupeutchi/.local/share/pipx/venvs/zotify/lib/python3.12/site-packages/zotify/zotify.py", line 53, in get_content_stream
    return cls.SESSION.content_feeder().load(content_id, VorbisOnlyAudioQuality(quality), False, None)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/scrameupeutchi/.local/share/pipx/venvs/zotify/lib/python3.12/site-packages/librespot/audio/__init__.py", line 771, in load
    return self.load_track(playable_id, audio_quality_picker, preload,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/scrameupeutchi/.local/share/pipx/venvs/zotify/lib/python3.12/site-packages/librespot/audio/__init__.py", line 825, in load_track
    raise RuntimeError("Cannot get alternative track")
RuntimeError: Cannot get alternative track

From what I could understand from the way the track's URL is retrieved, the Metadata should contain a "file" field to get the information from. However, the result I'm getting in debug does not seems to include that parameter anymore :

> id: "v\335\317\256TGG\216\242\'i\032A\200\253\030"
> name: "Butterfly"
> album {
>   gid: "{\341\320\325E(GT\216P\214\234\273\254[N"
>   name: "Smile"
>   artist {
>     gid: "\030\206\261\217\231\361G:\202\3048\330F\334\023\361"
>     name: "SMiLE.dk"
>   }
>   label: "Parlophone Denmark"
>   date {
>     year: 1998
>     month: 7
>     day: 13
>   }
>   cover_group {
>     image {
>       file_id: "\253gam\000\000\036\002\326j\306id-u\333\265)E\253"
>       size: DEFAULT
>       width: 300
>       height: 300
>     }
>     image {
>       file_id: "\253gam\000\000HQ\326j\306id-u\333\265)E\253"
>       size: SMALL
>       width: 64
>       height: 64
>     }
>     image {
>       file_id: "\253gam\000\000\262s\326j\306id-u\333\265)E\253"
>       size: LARGE
>       width: 640
>       height: 640
>     }
>   }
> }
> artist {
>   gid: "\030\206\261\217\231\361G:\202\3048\330F\334\023\361"
>   name: "SMiLE.dk"
> }
> number: 1
> disc_number: 1
> duration: 177453
> popularity: 64
> external_id {
>   type: "isrc"
>   id: "DKABA9814003"
> }
> earliest_live_timestamp: 413146860
> has_lyrics: true
> licensor {
>   uuid: "\2037\246\256\254\247D\247\263 P\360\306n\023\217"
> }

And then, the value of Metadata.Track is None. No alternatives could be found either. Looks Spotify is still up to shenanigans, let's hope we can find an alternative.

To Reproduce Steps to reproduce the behavior:

1. Use librespot-python (last version)
2. Try to get a track
3. It won't get through

Expected behavior The track is downloaded and converted if needed.

Client Information (please complete the following information):

• OS: Linux Mint 22.04
• Python Version : 3.12.3
• Library Version Last main branch revision

Additional context Add any other context about the problem here.

also i have this problem form a few hours

[Scrameupeutchi]

Remote librespot-org seems to have found a workaround by using extended-metada endpoint that still contains the File parameter. ( See librespot-org/librespot#1622 ) . However, I don't clearly know how to actually adapt the fix to this repository, so I hope someone could be up to it.

[IsaacAgulhas]

Remote librespot-org seems to have found a workaround by using extended-metada endpoint that still contains the File parameter. ( See librespot-org/librespot#1622 ) . However, I don't clearly know how to actually adapt the fix to this repository, so I hope someone could be up to it.

the challenge is that this repo is built in python whereas the main librepsot repo is built in rust, and additionally the librespot devs are always very fast with finding and implementing fixes when these issues arise, however we are then stuck waiting for a language specific implementation of that fix

since zotify itself is built in python, and rust modules can be used in python, maybe a correct approach would be to build a fork of zotify that implements librespot as a rust dependency and not as a python module. That way we can keep up with the speed at which the main librespot team finds and implements their fixes.

[Masterolic]

Remote librespot-org seems to have found a workaround by using extended-metada endpoint that still contains the File parameter. ( See librespot-org/librespot#1622 ) . However, I don't clearly know how to actually adapt the fix to this repository, so I hope someone could be up to it.

the challenge is that this repo is built in python whereas the main librepsot repo is built in rust, and additionally the librespot devs are always very fast with finding and implementing fixes when these issues arise, however we are then stuck waiting for a language specific implementation of that fix

since zotify itself is built in python, and rust modules can be used in python, maybe a correct approach would be to build a fork of zotify that implements librespot as a rust dependency and not as a python module. That way we can keep up with the speed at which the main librespot team finds and implements their fixes.

I have a doubt is that we need to add extendedmetadata proto files in librespot-python?

[abdullahrahimoon]

ModuleNotFoundError: No module named 'extended_metadata_pb2' getting this.

[Masterolic]

@kokarare1212 bro can you please check around this issue

[Masterolic]

ModuleNotFoundError: No module named 'extended_metadata_pb2' getting this.

Bro do you know to implement?
Anyway the above mentioned issue i had imported proto files from rust program

https://github.com/Masterolic/librespot-python/blob/main/librespot/proto/extended_metadata_pb2.py

[IsaacAgulhas]

ModuleNotFoundError: No module named 'extended_metadata_pb2' getting this.

Bro do you know to implement? Anyway the above mentioned issue i had imported proto files from rust program

https://github.com/Masterolic/librespot-python/blob/main/librespot/proto/extended_metadata_pb2.py

performing the proto imports will be very similar to how the guys did the patch for the Login5 authentication since that also performed a proto import, you have to do it in a try catch structured import. Here is code snippet of the Login5 they did so you can see the structure:

from librespot.proto.ExplicitContentPubsub_pb2 import UserAttributesUpdate
try:
    from librespot.proto.spotify.login5.v3 import Login5_pb2 as Login5
    from librespot.proto.spotify.login5.v3 import ClientInfo_pb2 as Login5ClientInfo
    from librespot.proto.spotify.login5.v3.credentials import Credentials_pb2 as Login5Credentials
    LOGIN5_AVAILABLE = True
except ImportError as e:
    # Login5 protobuf files not available, will use fallback
    LOGIN5_AVAILABLE = False
    Login5 = None
    Login5ClientInfo = None
    Login5Credentials = None

[Masterolic]

ModuleNotFoundError: No module named 'extended_metadata_pb2' getting this.

Bro do you know to implement? Anyway the above mentioned issue i had imported proto files from rust program
https://github.com/Masterolic/librespot-python/blob/main/librespot/proto/extended_metadata_pb2.py

performing the proto imports will be very similar to how the guys did the patch for the Login5 authentication since that also performed a proto import, you have to do it in a try catch structured import. Here is code snippet of the Login5 they did so you can see the structure:

from librespot.proto.ExplicitContentPubsub_pb2 import UserAttributesUpdate
try:
from librespot.proto.spotify.login5.v3 import Login5_pb2 as Login5
from librespot.proto.spotify.login5.v3 import ClientInfo_pb2 as Login5ClientInfo
from librespot.proto.spotify.login5.v3.credentials import Credentials_pb2 as Login5Credentials
LOGIN5_AVAILABLE = True
except ImportError as e:
# Login5 protobuf files not available, will use fallback
LOGIN5_AVAILABLE = False
Login5 = None
Login5ClientInfo = None
Login5Credentials = None

Ha buddy understood i was just trying to fix because my projects are stuck now...so when i tried to fix its ended with 400 status error i dont have much interal knowledge of librespot-python and proto

[IsaacAgulhas]

ModuleNotFoundError: No module named 'extended_metadata_pb2' getting this.

Bro do you know to implement? Anyway the above mentioned issue i had imported proto files from rust program
https://github.com/Masterolic/librespot-python/blob/main/librespot/proto/extended_metadata_pb2.py

performing the proto imports will be very similar to how the guys did the patch for the Login5 authentication since that also performed a proto import, you have to do it in a try catch structured import. Here is code snippet of the Login5 they did so you can see the structure:
from librespot.proto.ExplicitContentPubsub_pb2 import UserAttributesUpdate
try:
from librespot.proto.spotify.login5.v3 import Login5_pb2 as Login5
from librespot.proto.spotify.login5.v3 import ClientInfo_pb2 as Login5ClientInfo
from librespot.proto.spotify.login5.v3.credentials import Credentials_pb2 as Login5Credentials
LOGIN5_AVAILABLE = True
except ImportError as e:

Login5 protobuf files not available, will use fallback

LOGIN5_AVAILABLE = False
Login5 = None
Login5ClientInfo = None
Login5Credentials = None

Ha buddy understood i was just trying to fix because my projects are stuck now...so when i tried to fix its ended with 400 status error i dont have much interal knowledge of librespot-python and proto

where did you get the librespot/proto/extended_metadata_pb2.py in the first place, because in my project it is not there. Did you recompile the librespot protos from source?

[Masterolic]

ModuleNotFoundError: No module named 'extended_metadata_pb2' getting this.

Bro do you know to implement? Anyway the above mentioned issue i had imported proto files from rust program
https://github.com/Masterolic/librespot-python/blob/main/librespot/proto/extended_metadata_pb2.py

performing the proto imports will be very similar to how the guys did the patch for the Login5 authentication since that also performed a proto import, you have to do it in a try catch structured import. Here is code snippet of the Login5 they did so you can see the structure:
from librespot.proto.ExplicitContentPubsub_pb2 import UserAttributesUpdate
try:
from librespot.proto.spotify.login5.v3 import Login5_pb2 as Login5
from librespot.proto.spotify.login5.v3 import ClientInfo_pb2 as Login5ClientInfo
from librespot.proto.spotify.login5.v3.credentials import Credentials_pb2 as Login5Credentials
LOGIN5_AVAILABLE = True
except ImportError as e:

Login5 protobuf files not available, will use fallback

LOGIN5_AVAILABLE = False
Login5 = None
Login5ClientInfo = None
Login5Credentials = None

Ha buddy understood i was just trying to fix because my projects are stuck now...so when i tried to fix its ended with 400 status error i dont have much interal knowledge of librespot-python and proto

where did you get the librespot/proto/extended_metadata_pb2.py in the first place, because in my project it is not there. Did you recompile the librespot protos from source?

Yes buddy
https://github.com/photovoltex/librespot/blob/9a0c96bd8c97d716ded9088dbbe7b1d088f7bf80/protocol/proto/extended_metadata.proto

From there 2,3 proto files had recompiled and implemented

[Masterolic]

@photovoltex can you fix this python version too :)

[IsaacAgulhas]

@photovoltex can you fix this python version too :)

@Masterolic is your version now working?!