[GH-ISSUE #139] [BUG] base62.encode() not working as intended on byte strings #18

New issue

Closed

opened 2026-02-27 08:11:27 +03:00 by kerem · 4 comments

kerem commented

2026-02-27 08:11:27 +03:00

Owner

Originally created by @Yetangitu on GitHub (Jun 30, 2022).
Original GitHub issue: https://github.com/kokarare1212/librespot-python/issues/139

While refactoring spodcast to use librespot-python-provided interfaces instead of doing raw API access I hit upon a snag in the base62 encoder: it does not seem to be able to encode byte strings while it is fed such through the various XxxId.to_spotify_uri() methods (in librespot.metadata) by means of util.hex_to_bytes():

PlayableId.base62.encode(util.hex_to_bytes(self.__hex_id)))

Here's what happens (text between brackets - () - is produced by instrumentation, as is the actual line on which the fault occurs (which otherwise would have occurred on line 67: translation[i] = dictionary[int.from_bytes(indices[i].encode(),"big")]):

(in encode)
(indices:  b'\x04$\'::\x1a\x08\x11<*\x19;(\x11."!\x1d12\r/')
(dictionary:  b'0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ')
(len(indices):  22)
(range:  range(0, 22))
(i:  0)
(indices[i]:  4)
Traceback (most recent call last):
  File "/home/frank/.local/bin/spodcast", line 33, in <module>
    sys.exit(load_entry_point('spodcast', 'console_scripts', 'spodcast')())
  File "/home/frank/Projects/spodcast/spodcast/__main__.py", line 42, in main
    args.func(args)
  File "/home/frank/Projects/spodcast/spodcast/app.py", line 29, in client
    download_episode(episode_id)
  File "/home/frank/Projects/spodcast/spodcast/podcast.py", line 134, in download_episode
    podcast_name, podcast_id, duration_ms, episode_name, description, release_date, uri, download_url = get_episode_info(episode_id)
  File "/home/frank/Projects/spodcast/spodcast/podcast.py", line 47, in get_episode_info
    uri = episode.to_spotify_uri()
  File "/home/frank/.local/lib/python3.10/site-packages/librespot/metadata.py", line 187, in to_spotify_uri
    EpisodeId.base62.encode(util.hex_to_bytes(self.__hex_id)))
  File "/home/frank/.local/lib/python3.10/site-packages/librespot/util.py", line 58, in encode
    return self.translate(indices, self.alphabet)
  File "/home/frank/.local/lib/python3.10/site-packages/librespot/util.py", line 75, in translate
    print("encoded: ", indices[i].encode())
AttributeError: 'int' object has no attribute 'encode'

This code seems to be transpiled from the java version in https://github.com/librespot-org/librespot-java/blob/dev/lib/src/main/java/xyz/gianlu/librespot/common/Base62.java - has the result been tested to be functional?

I'd suggest ditching this piece of code and using one of the existing base62 libraries (pybase62 seems to work, I'm using it in spodcast to circumvent these problems), either inlined or as an import.

Originally created by @Yetangitu on GitHub (Jun 30, 2022). Original GitHub issue: https://github.com/kokarare1212/librespot-python/issues/139 While refactoring _spodcast_ to use _librespot-python_-provided interfaces instead of doing raw API access I hit upon a snag in the base62 encoder: it does not seem to be able to encode byte strings while it is fed such through the various `XxxId.to_spotify_uri()` methods (in `librespot.metadata`) by means of `util.hex_to_bytes()`: `PlayableId.base62.encode(util.hex_to_bytes(self.__hex_id)))` Here's what happens (text between brackets - () - is produced by instrumentation, as is the actual line on which the fault occurs (which otherwise would have occurred on line 67: `translation[i] = dictionary[int.from_bytes(indices[i].encode(),"big")]`): ``` (in encode) (indices: b'\x04$\'::\x1a\x08\x11<*\x19;(\x11."!\x1d12\r/') (dictionary: b'0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ') (len(indices): 22) (range: range(0, 22)) (i: 0) (indices[i]: 4) Traceback (most recent call last): File "/home/frank/.local/bin/spodcast", line 33, in <module> sys.exit(load_entry_point('spodcast', 'console_scripts', 'spodcast')()) File "/home/frank/Projects/spodcast/spodcast/__main__.py", line 42, in main args.func(args) File "/home/frank/Projects/spodcast/spodcast/app.py", line 29, in client download_episode(episode_id) File "/home/frank/Projects/spodcast/spodcast/podcast.py", line 134, in download_episode podcast_name, podcast_id, duration_ms, episode_name, description, release_date, uri, download_url = get_episode_info(episode_id) File "/home/frank/Projects/spodcast/spodcast/podcast.py", line 47, in get_episode_info uri = episode.to_spotify_uri() File "/home/frank/.local/lib/python3.10/site-packages/librespot/metadata.py", line 187, in to_spotify_uri EpisodeId.base62.encode(util.hex_to_bytes(self.__hex_id))) File "/home/frank/.local/lib/python3.10/site-packages/librespot/util.py", line 58, in encode return self.translate(indices, self.alphabet) File "/home/frank/.local/lib/python3.10/site-packages/librespot/util.py", line 75, in translate print("encoded: ", indices[i].encode()) AttributeError: 'int' object has no attribute 'encode' ``` This code seems to be transpiled from the _java_ version in https://github.com/librespot-org/librespot-java/blob/dev/lib/src/main/java/xyz/gianlu/librespot/common/Base62.java - has the result been tested to be functional? I'd suggest ditching this piece of code and using one of the existing base62 libraries (_pybase62_ seems to work, I'm using it in _spodcast_ to circumvent these problems), either inlined or as an import.

kerem

2026-02-27 08:11:27 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-27 08:11:27 +03:00

Author

Owner

@kokarare1212 commented on GitHub (Jul 11, 2022):

Thank you for your patience.
It seems that the encoding and decoding of strings (especially the conversion of str and bytes) was not working properly.

@kokarare1212 commented on GitHub (Jul 11, 2022): Thank you for your patience. It seems that the encoding and decoding of strings (especially the conversion of str and bytes) was not working properly.

kerem commented

2026-02-27 08:11:27 +03:00

Author

Owner

@tacohitbox commented on GitHub (Feb 2, 2023):

Thank you for your patience. It seems that the encoding and decoding of strings (especially the conversion of str and bytes) was not working properly.

Any progress on this?

@tacohitbox commented on GitHub (Feb 2, 2023): > Thank you for your patience. It seems that the encoding and decoding of strings (especially the conversion of str and bytes) was not working properly. Any progress on this?

kerem commented

2026-02-27 08:11:27 +03:00

Author

Owner

@kokarare1212 commented on GitHub (Feb 2, 2023):

I believe this was fixed in v0.0.7.

@kokarare1212 commented on GitHub (Feb 2, 2023): I believe this was fixed in v0.0.7.

kerem commented

2026-02-27 08:11:27 +03:00

Author

Owner

@tacohitbox commented on GitHub (Feb 3, 2023):