Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

suggestion: Issue tracker to implement 'Don't Play Music Videos' #1431

Closed
4 tasks done
inotia00 opened this issue Sep 27, 2023 · 2 comments
Closed
4 tasks done

suggestion: Issue tracker to implement 'Don't Play Music Videos' #1431

inotia00 opened this issue Sep 27, 2023 · 2 comments
Labels
Suggestion Leave any other suggestions

Comments

@inotia00
Copy link
Owner

Application

YouTube Music

Description

This is an issue tracker for the following issues: ReVanced/revanced-patches-template#1353

Since the implementation process is included in the RVX patch, I wrote it here rather than in the ReVanced repo.

Currently, YouTube Music shows different results under 'Albums' for premium and non-premium accounts.

To help you understand, I will cite the example mentioned in vfsfitvnm/ViMusic#88

Open the following album in YouTube Music and play the first song:
Mercury : Acts 1 & 2

Regardless of the 'Don't Play Music Videos' setting, official music will be played on premium accounts and music videos will be played on non-premium accounts

It's not clear whether this was intended or unintentional.
When sending a request for the same Playlist Id, it appears that premium and non-premium accounts receive different responses.

The ideal way to implement this as a patch would be to find the method in YouTube Music that handles the response to the request for Playlist Id and replace it with the response received from the unofficial API.

Unfortunately, despite conducting reverse engineering for a long time, I could not find a method to handle this endpoint in the YouTube Music client.

Reversing engineering is even more difficult on Android clients because they send requests with the application/x-protobuf type.

Instead, it seems possible to send a request to a piped instance using the initial value created in PlaybackStartDescriptor.

It is impossible to apply the method used by ViMusic as it is, but it seems that some similar implementation is possible.

Here's the description of the patch:

  1. When the music starts, send a request to the piped instance to fetch the videoId.
  2. If the current playing status is Music Video (VideoType == MUSIC_VIDEO_TYPE_OMV), prepare to use the videoId fetched from the piped instance.
  3. When the user presses the music button at the top of the player, the videoId fetched from the piped instance is opened.

e g

I plan to exclude this patch by default because of the high probability of bugs

Acknowledgements

  • I have searched the existing issues and this is a new and no duplicate or related to another open issue.
  • I have written a short but informative title.
  • I filled out all of the requested information in this issue properly.
  • I have written the title and contents in English.
@inotia00 inotia00 added the Suggestion Leave any other suggestions label Sep 27, 2023
@Spacellary
Copy link
Collaborator

👀

Huge!

@inotia00
Copy link
Owner Author

reflected in revanced-patches-v2.190.15

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Suggestion Leave any other suggestions
Projects
None yet
Development

No branches or pull requests

2 participants