[GH-ISSUE #374] filtering search on albums is not filtered? #296

New issue

Closed

opened 2026-02-27 22:09:03 +03:00 by kerem · 13 comments

kerem commented 2026-02-27 22:09:03 +03:00

Owner

Copy link

Originally created by @zeitmeister on GitHub (Apr 5, 2023).
Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/374

When performing a search with "albums" as filter i get a different response when i run my code locally compared to when i run it in a docker container.

The following search is perfomed:
ytmusic.search("Sepultura Arise", "albums")

And the response from when I run it locally is:

[
   {
      "category":"Albums",
      "resultType":"album",
      "title":"Arise",
      "type":"Album",
      "duration":"None",
      "year":"1991",
      "artists":[
         {
            "name":"Sepultura",
            "id":"UCZDm-NPbTrtTGa69EC2dFGw"
         }
      ],
      "browseId":"MPREb_SXjncHxnAGz",
      ....
      }
]

The response from the same request made from within a docker container:

[{
	'category': 'Albums',
	'resultType': 'song',
	'title': 'Arise',
	'album': None,
	'feedbackTokens': {
		'add': None,
		'remove': None
	},
	'videoId': 'Ubgc-4MNunQ',
	....
	}
]

Note that the resultType is different and the absence of browseId (which breaks my whole app).
I discovered the issue when working on a "bigger" playlist app and decided to do a minimal test and the issue is still there. The minimal code for reproducing the error :

from ytmusicapi import YTMusic
import time
import logging
from datetime import date


ytmusic = YTMusic('header-auth.json')


logging.basicConfig(filename="./logs/test-"+str(date.today())+".log",
                    format='%(asctime)s,%(msecs)d %(name)s %(levelname)s %(message)s',
                    datefmt='%H:%M:%S',
                    level=logging.INFO)

search_results = ytmusic.search("Sepultura Arise", "albums")
logging.info(search_results)

And the Dockerfile:

FROM python:3.10.6
RUN mkdir /code
RUN mkdir /code/logs/
WORKDIR /code
ADD dagensalbum.py /code/
ADD test.py /code/
ADD header-auth.json /code/
RUN pip3 install ytmusicapi requests schedule
CMD ["python3", "./test.py"]

This well might not be a problem with ytmusicapi but instead with docker networking somehow but then wouldn't it be no request at all? I'm trying to wrap my head around what is actually happening here but can't quite figure it out. I wouldn't be suprised if I missed something. Sorry about the long entry.

Thanks for a great service anyhow!

Kind regards
Simon

Originally created by @zeitmeister on GitHub (Apr 5, 2023). Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/374 When performing a search with "albums" as filter i get a different response when i run my code locally compared to when i run it in a docker container. The following search is perfomed: `ytmusic.search("Sepultura Arise", "albums")` And the response from when I run it locally is: ``` [ { "category":"Albums", "resultType":"album", "title":"Arise", "type":"Album", "duration":"None", "year":"1991", "artists":[ { "name":"Sepultura", "id":"UCZDm-NPbTrtTGa69EC2dFGw" } ], "browseId":"MPREb_SXjncHxnAGz", .... } ] ``` The response from the same request made from within a docker container: ``` [{ 'category': 'Albums', 'resultType': 'song', 'title': 'Arise', 'album': None, 'feedbackTokens': { 'add': None, 'remove': None }, 'videoId': 'Ubgc-4MNunQ', .... } ] ``` Note that the `resultType` is different and the absence of browseId (which breaks my whole app). I discovered the issue when working on a "bigger" playlist app and decided to do a minimal test and the issue is still there. The minimal code for reproducing the error : ``` from ytmusicapi import YTMusic import time import logging from datetime import date ytmusic = YTMusic('header-auth.json') logging.basicConfig(filename="./logs/test-"+str(date.today())+".log", format='%(asctime)s,%(msecs)d %(name)s %(levelname)s %(message)s', datefmt='%H:%M:%S', level=logging.INFO) search_results = ytmusic.search("Sepultura Arise", "albums") logging.info(search_results) ``` And the Dockerfile: ``` FROM python:3.10.6 RUN mkdir /code RUN mkdir /code/logs/ WORKDIR /code ADD dagensalbum.py /code/ ADD test.py /code/ ADD header-auth.json /code/ RUN pip3 install ytmusicapi requests schedule CMD ["python3", "./test.py"] ``` This well might not be a problem with `ytmusicapi` but instead with docker networking somehow but then wouldn't it be no request at all? I'm trying to wrap my head around what is actually happening here but can't quite figure it out. I wouldn't be suprised if I missed something. Sorry about the long entry. Thanks for a great service anyhow! Kind regards Simon

kerem 2026-02-27 22:09:03 +03:00

• closed this issue
• added the
  bug
  label

kerem commented 2026-02-27 22:09:04 +03:00

Author

Owner

Copy link

@zeitmeister commented on GitHub (Apr 5, 2023):

Ok, I figured out that everytime I rebuild and run the docker container the newest version of ytmusicapi is installed (since the pip install line in the Dockerfile and that it's been a while since i did it locally. When i updated ytmusicapi locally (from 0.25.0 to 0.25.2 i got the same response as i did from the docker container. The problem still remains though, I am filtering on "albums" and I expect the response to be filtered like that. Is this a proper issue or is it still something I don't understand? : )

<!-- gh-comment-id:1498156546 --> @zeitmeister commented on GitHub (Apr 5, 2023): Ok, I figured out that everytime I rebuild and run the docker container the newest version of ytmusicapi is installed (since the `pip install` line in the Dockerfile and that it's been a while since i did it locally. When i updated ytmusicapi locally (from 0.25.0 to 0.25.2 i got the same response as i did from the docker container. The problem still remains though, I am filtering on `"albums"` and I expect the response to be filtered like that. Is this a proper issue or is it still something I don't understand? : )

kerem commented 2026-02-27 22:09:04 +03:00

Author

Owner

Copy link

@sigma67 commented on GitHub (Apr 5, 2023):

It is indeed a bug. Something about the obscure filtering params used in search seems to have changed.

<!-- gh-comment-id:1498194014 --> @sigma67 commented on GitHub (Apr 5, 2023): It is indeed a bug. Something about the obscure filtering params used in search seems to have changed.

kerem commented 2026-02-27 22:09:04 +03:00

Author

Owner

Copy link

@sigma67 commented on GitHub (Apr 5, 2023):

It works for me with the change above. Did you notice any other oddities about search?

<!-- gh-comment-id:1498203788 --> @sigma67 commented on GitHub (Apr 5, 2023): It works for me with the change above. Did you notice any other oddities about search?

kerem commented 2026-02-27 22:09:04 +03:00

Author

Owner

Copy link

@zeitmeister commented on GitHub (Apr 6, 2023):

All right! No, I'm actually just using album searching so I haven't noticed anything else with the search functionality. Is there anyway i could try these changes out?

<!-- gh-comment-id:1498507419 --> @zeitmeister commented on GitHub (Apr 6, 2023): All right! No, I'm actually just using album searching so I haven't noticed anything else with the search functionality. Is there anyway i could try these changes out?

kerem commented 2026-02-27 22:09:04 +03:00

Author

Owner

Copy link

@sigma67 commented on GitHub (Apr 6, 2023):

pip install git+https://github.com/sigma67/ytmusicapi

<!-- gh-comment-id:1498722105 --> @sigma67 commented on GitHub (Apr 6, 2023): `pip install git+https://github.com/sigma67/ytmusicapi`

kerem commented 2026-02-27 22:09:04 +03:00

Author

Owner

Copy link

@zeitmeister commented on GitHub (Apr 6, 2023):

Sorry but this command installs the package as UNKNOWN and I am too much of a python newbie to know how to make this work. from UNKOWN import YTMusic does not do the trick unfortunately.

<!-- gh-comment-id:1498851040 --> @zeitmeister commented on GitHub (Apr 6, 2023): Sorry but this command installs the package as `UNKNOWN` and I am too much of a python newbie to know how to make this work. `from UNKOWN import YTMusic` does not do the trick unfortunately.

kerem commented 2026-02-27 22:09:04 +03:00

Author

Owner

Copy link

@sigma67 commented on GitHub (Apr 6, 2023):

Not sure why, I get

Successfully installed ytmusicapi-0.25.3.dev19+ga1e4662

What's your pip output?

<!-- gh-comment-id:1498966851 --> @sigma67 commented on GitHub (Apr 6, 2023): Not sure why, I get `` Successfully installed ytmusicapi-0.25.3.dev19+ga1e4662 `` What's your pip output?

kerem commented 2026-02-27 22:09:04 +03:00

Author

Owner

Copy link

@zeitmeister commented on GitHub (Apr 6, 2023):

Defaulting to user installation because normal site-packages is not writeable
Collecting git+https://github.com/sigma67/ytmusicapi
  Cloning https://github.com/sigma67/ytmusicapi to /tmp/pip-req-build-3z0yq16c
  Running command git clone --filter=blob:none --quiet https://github.com/sigma67/ytmusicapi /tmp/pip-req-build-3z0yq16c
  Resolved https://github.com/sigma67/ytmusicapi to commit a1e466273d44e711318ec238bfe933e2639f8c87
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Installing backend dependencies ... done
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: UNKNOWN
  Building wheel for UNKNOWN (pyproject.toml) ... done
  Created wheel for UNKNOWN: filename=UNKNOWN-0.25.3.dev19+ga1e4662-py3-none-any.whl size=1982 sha256=4caf198af7233b59084600e434140c2a2fced3de7f5e7b62fb4d5752c43ad5d3
  Stored in directory: /tmp/pip-ephem-wheel-cache-2lunxq97/wheels/c0/b9/ed/67a26920c402bd107627c793a91a4494e4398ff00219383b2d
Successfully built UNKNOWN
Installing collected packages: UNKNOWN
Successfully installed UNKNOWN-0.25.3.dev19+ga1e4662

my python version is 3.10.6
and pip is 22.0.2

I've also tried with sudo with same result. Also tried the -e flag (which is some edit mode for renaming and stuff, I really have no idea what it does) but got:

ERROR: Project ytmusicapi from git+https://github.com/sigma67/ytmusicapi#egg=ytmusicapi has a 'pyproject.toml' and its build backend is missing the 'build_editable' hook. Since it does not have a 'setup.py' nor a 'setup.cfg', it cannot be installed in editable mode. Consider using a build backend that supports PEP 660.

<!-- gh-comment-id:1499029582 --> @zeitmeister commented on GitHub (Apr 6, 2023): ``` Defaulting to user installation because normal site-packages is not writeable Collecting git+https://github.com/sigma67/ytmusicapi Cloning https://github.com/sigma67/ytmusicapi to /tmp/pip-req-build-3z0yq16c Running command git clone --filter=blob:none --quiet https://github.com/sigma67/ytmusicapi /tmp/pip-req-build-3z0yq16c Resolved https://github.com/sigma67/ytmusicapi to commit a1e466273d44e711318ec238bfe933e2639f8c87 Installing build dependencies ... done Getting requirements to build wheel ... done Installing backend dependencies ... done Preparing metadata (pyproject.toml) ... done Building wheels for collected packages: UNKNOWN Building wheel for UNKNOWN (pyproject.toml) ... done Created wheel for UNKNOWN: filename=UNKNOWN-0.25.3.dev19+ga1e4662-py3-none-any.whl size=1982 sha256=4caf198af7233b59084600e434140c2a2fced3de7f5e7b62fb4d5752c43ad5d3 Stored in directory: /tmp/pip-ephem-wheel-cache-2lunxq97/wheels/c0/b9/ed/67a26920c402bd107627c793a91a4494e4398ff00219383b2d Successfully built UNKNOWN Installing collected packages: UNKNOWN Successfully installed UNKNOWN-0.25.3.dev19+ga1e4662 ``` my python version is 3.10.6 and pip is 22.0.2 I've also tried with `sudo` with same result. Also tried the `-e` flag (which is some edit mode for renaming and stuff, I really have no idea what it does) but got: `ERROR: Project ytmusicapi from git+https://github.com/sigma67/ytmusicapi#egg=ytmusicapi has a 'pyproject.toml' and its build backend is missing the 'build_editable' hook. Since it does not have a 'setup.py' nor a 'setup.cfg', it cannot be installed in editable mode. Consider using a build backend that supports PEP 660.`

kerem commented 2026-02-27 22:09:04 +03:00

Author

Owner

Copy link

@zeitmeister commented on GitHub (Apr 6, 2023):

Sorry for being a complete idiot. Upgrading pip made me able to run the updated ytmusicapi. fml...

<!-- gh-comment-id:1499039751 --> @zeitmeister commented on GitHub (Apr 6, 2023): Sorry for being a complete idiot. Upgrading pip made me able to run the updated ytmusicapi. fml...

kerem commented 2026-02-27 22:09:04 +03:00

Author

Owner

Copy link

@sigma67 commented on GitHub (Apr 6, 2023):

Good to know though, should specify pip > 23 somewhere I guess

<!-- gh-comment-id:1499040518 --> @sigma67 commented on GitHub (Apr 6, 2023): Good to know though, should specify pip > 23 somewhere I guess

kerem commented 2026-02-27 22:09:04 +03:00

Author

Owner

Copy link

@zeitmeister commented on GitHub (Apr 6, 2023):

Yeah, I suppose. But even now when I'm using ytmusicapi 0.25.3.dev19+ga1e4662 as stated when I'm running pip list i still get the same none album response when filtering for albums. The resultType is all of the value song

<!-- gh-comment-id:1499073111 --> @zeitmeister commented on GitHub (Apr 6, 2023): Yeah, I suppose. But even now when I'm using ```ytmusicapi 0.25.3.dev19+ga1e4662``` as stated when I'm running `pip list` i still get the same _none_ album response when filtering for albums. The `resultType` is all of the value `song`

kerem commented 2026-02-27 22:09:04 +03:00

Author

Owner

Copy link

@sigma67 commented on GitHub (Apr 6, 2023):

I have to apologize, that was an oversight on my part. It wasn't actually the parameter, the old one worked fine.

I added some more asserts as well to prevent this in the future.

<!-- gh-comment-id:1499600425 --> @sigma67 commented on GitHub (Apr 6, 2023): I have to apologize, that was an oversight on my part. It wasn't actually the parameter, the old one worked fine. I added some more asserts as well to prevent this in the future.

kerem commented 2026-02-27 22:09:04 +03:00

Author

Owner

Copy link

@zeitmeister commented on GitHub (Apr 7, 2023):

All right, no worries! It seems to be working now. Thank you so much for your quick responses!

<!-- gh-comment-id:1500559183 --> @zeitmeister commented on GitHub (Apr 7, 2023): All right, no worries! It seems to be working now. Thank you so much for your quick responses!

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

fix-yt-dlp-link

restore-codecov-cat

unify-coverage-workflow

sigma67-security-md

rewrite-workflow

dep/update-pdm-lock

remove-2025-explore-test

get-explore-fix-top-episodes-duration

update-linters

fix-ci-pipeline

fix-827

remove-oauth-account-tests

fix-tests

fix-799

fix-remaining-tests

v2

niquests

3-10-typed

fix-758

fix-743

fix-734-continuations

add-oauthcredentials-import-doc

ytmusic-auth-refactor

fix-720

fix-721

fix-713

fix-703

add-test-analytics

update-oauth-docs

feat-670

heinrich26-patch-1

fix-675

fix-get-history

fix-648

fix-641

refactor-use-pathlib

fix-647

fix-642

fix-640

fix-633

feat-628

fix-625

models

introduce-exception-classes

improve-coverage

pytest-retry

fix-588

fix-587

fix-582

fix-569

fix-get-playlist-562

get-artist-shows

get-podcast-playlist

fix-get-album-544

library-podcasts

get-episode-progress

fix-548

brand-account-setup

album-data-mining

jcbirdwell-album-data-mining

album-data-mining-fixes

get-podcast

artist-albums-continuations

1.11.5

1.11.4

1.11.3

1.11.2

1.11.1

1.11.0

1.11.0rc1

1.10.3

1.10.2

1.10.1

1.10.0

1.9.1

1.9.0

1.8.2

1.8.1

1.8.0

1.7.5

1.7.4

1.7.3

1.7.2

1.7.1

1.7.0

1.6.0

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.2

1.4.1

1.4.0

1.3.2

1.3.1

1.3.0

1.2.1

1.2.0

1.1.1

1.1.0

1.0.2

1.0.1

1.0.0

0.25.2

0.25.1

0.25.0

0.24.1

0.24.0

0.23.0

0.22.0

0.21.0

0.20.0

0.19.5

0.19.4

0.19.3

0.19.2

0.19.1

0.19.0

0.18.0

0.17.3

0.17.2

0.17.1

0.17.0

0.16.0

0.15.1

0.15.0

0.14.3

0.14.2

0.14.1

0.14.0

0.13.1

0.13.0

0.12.2

0.12.1

0.12.0

0.11.0

0.10.2

0.10.1

0.10.0

0.9.2

0.9.1

0.9.0

0.8.1

0.8.0

0.7.1

0.7.0

0.6.1

0.6.0

0.5.2

0.5.1

0.5.0

0.4.3

0.4.2

8cc1986

0.4.1

1ac614e

Labels

Clear labels   

a/b

  

bug

  

documentation

  

enhancement

  

good first issue

  

help wanted

  

invalid

  

pull-request

Mirrored from GitHub Pull Request

  

question

  

wontfix

  

yt-error

  

yt-update

No labels

a/b

bug

documentation

enhancement

good first issue

help wanted

invalid

pull-request

question

wontfix

yt-error

yt-update

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

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/ytmusicapi#296

No description provided.