TeamNewPipe / TeamNewPipe/NewPipeExtractor
Error in displaying the like count for YouTube videos with no likes
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 2k
- Forks
- 602
- Avg merge
- 3d 6h
- Merged PRs (30d)
- 6
Description
Checklist
- I am able to reproduce the bug with the latest version given here: CLICK THIS LINK.
- I am aware that this issue is being opened for the NewPipe Extractor, NOT the app, and my bug report will be dismissed otherwise.
- I made sure that there are no existing issues - open or closed - which I could contribute my information to.
- I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
- This issue contains only one bug.
- I have read and understood the contribution guidelines.
Affected version
0.25.0
Steps to reproduce the bug
- In the NewPipe app, find and open a video that both has zero likes and has enabled likes and dislikes.
- Look at the like counter of the video.
Expected behavior
The like counter should display 0 likes.
Actual behavior
The like counter displays 'Disabled'.
Screenshots/Screen recordings
I was watching a recently uploaded video (https://www.youtube.com/watch?v=Di9HYOoGr88) of someone playing Dance Dance Revolution in NewPipe. On the YouTube website, the like counter displays 0 correctly:
However, in NewPipe, the like counter displays 'Disabled':
Logs
Exception
- User Action: requested stream
- Request: Some info not extracted: https://www.youtube.com/watch?v=Di9HYOoGr88
- Content Country: US
- Content Language: en-US
- App Language: en_US
- Service: YouTube
- Timestamp: 2026-01-15T21:42:02.868+11:00
- Package: org.schabi.newpipe
- Service: YouTube
- Version: 0.28.1
- OS: Linux Xiaomi/amber_global/amber:14/UP1A.231005.007/V816.0.16.0.UKWMIXM:user/release-keys 14 - 34
Crash log
org.schabi.newpipe.extractor.exceptions.ParsingException: Could not get like count
at org.schabi.newpipe.extractor.services.youtube.extractors.YoutubeStreamExtractor.getLikeCount(YoutubeStreamExtractor.java:416)
at org.schabi.newpipe.extractor.stream.StreamInfo.extractOptionalData(StreamInfo.java:262)
at org.schabi.newpipe.extractor.stream.StreamInfo.getInfo(StreamInfo.java:82)
at org.schabi.newpipe.extractor.stream.StreamInfo.getInfo(StreamInfo.java:72)
at org.schabi.newpipe.util.ExtractorHelper.$r8$lambda$bVfA-5gb6gDc8jcAgcGWG5oH0FE(ExtractorHelper.java:118)
at org.schabi.newpipe.util.ExtractorHelper$$ExternalSyntheticLambda3.call(R8$$SyntheticClass:0)
at io.reactivex.rxjava3.internal.operators.single.SingleFromCallable.subscribeActual(SingleFromCallable.java:43)
at io.reactivex.rxjava3.core.Single.subscribe(Single.java:4855)
at io.reactivex.rxjava3.internal.operators.single.SingleDoOnSuccess.subscribeActual(SingleDoOnSuccess.java:35)
at io.reactivex.rxjava3.core.Single.subscribe(Single.java:4855)
at io.reactivex.rxjava3.internal.operators.maybe.MaybeFromSingle.subscribeActual(MaybeFromSingle.java:41)
at io.reactivex.rxjava3.core.Maybe.subscribe(Maybe.java:5377)
at io.reactivex.rxjava3.internal.operators.maybe.MaybeConcatArray$ConcatMaybeObserver.drain(MaybeConcatArray.java:153)
at io.reactivex.rxjava3.internal.operators.maybe.MaybeConcatArray$ConcatMaybeObserver.request(MaybeConcatArray.java:78)
at io.reactivex.rxjava3.internal.operators.flowable.FlowableElementAtMaybe$ElementAtSubscriber.onSubscribe(FlowableElementAtMaybe.java:66)
at io.reactivex.rxjava3.internal.operators.maybe.MaybeConcatArray.subscribeActual(MaybeConcatArray.java:42)
at io.reactivex.rxjava3.core.Flowable.subscribe(Flowable.java:16149)
at io.reactivex.rxjava3.internal.operators.flowable.FlowableElementAtMaybe.subscribeActual(FlowableElementAtMaybe.java:36)
at io.reactivex.rxjava3.core.Maybe.subscribe(Maybe.java:5377)
at io.reactivex.rxjava3.internal.operators.maybe.MaybeToSingle.subscribeActual(MaybeToSingle.java:46)
at io.reactivex.rxjava3.core.Single.subscribe(Single.java:4855)
at io.reactivex.rxjava3.internal.operators.single.SingleSubscribeOn$SubscribeOnObserver.run(SingleSubscribeOn.java:89)
at io.reactivex.rxjava3.core.Scheduler$DisposeTask.run(Scheduler.java:644)
at io.reactivex.rxjava3.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:80)
at io.reactivex.rxjava3.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:71)
at java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:348)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1154)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:652)
at java.lang.Thread.run(Thread.java:1563)
Caused by: org.schabi.newpipe.extractor.exceptions.ParsingException: Could not get like count from accessibility data
at org.schabi.newpipe.extractor.services.youtube.extractors.YoutubeStreamExtractor.parseLikeCountFromLikeButtonRenderer(YoutubeStreamExtractor.java:464)
at org.schabi.newpipe.extractor.services.youtube.extractors.YoutubeStreamExtractor.getLikeCount(YoutubeStreamExtractor.java:414)
... 29 more
Additional information
I debugged the parseLikeCountFromLikeButtonViewModel() and parseLikeCountFromLikeButtonRenderer() methods in YoutubeStreamExtractor.java. The video I linked does not have a like button renderer, but it does have a like button view model where accessibilityText = "like this video". Since there are no digits in the accessibility text string, parseLikeCountFromLikeButtonViewModel() throws an exception.
My finding goes against the comment at the end of that method, which states The like count is always returned as a number in this element, even for videos with no likes. Going through past issues in NewPipe and NewPipeExtractor, I found one containing a comment where the accessibility text string might be "like this video along with 0 other people" in the past. From my testing, it seems that only videos with 0 likes omit the "along with xxx other people" part, so maybe it is not possible to get the like count from the accessibility text in this case.
However, I noticed that the title property of the likeToggleButtonViewModel object contains a string that seems to indicate the like count. Testing this on several videos with small or large like counts, I think it represents the abbreviation of the actual like count (e.g. 257k, 1.1m, 4, 0). I am unfamiliar with the NewPipeExtractor code so I do not know the best way to handle this issue, but I wonder if it is a good idea to comment out the ParsingException code for the accessibility text in parseLikeCountFromLikeButtonViewModel() and add code that tries to parse the like count from the title property? If yes, should I open a pull request?
try {
return Long.parseLong(Utils.removeNonDigitCharacters(accessibilityText));
} catch (final NumberFormatException e) {
// throw new ParsingException(
// "Could not parse \"" + accessibilityText + "\" as a long", e);
}
final String title = likeToggleButtonViewModel.getString("title");
if (title == null) {
throw new ParsingException("Could not find buttonViewModel's title string");
}
try {
return Long.parseLong(Utils.removeNonDigitCharacters(title));
} catch (final NumberFormatException e) {
throw new ParsingException(
"Could not parse \"" + title + "\" as a long", e);
}
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in extractor/src/main/java/org/schabi/newpipe/extractor/services/youtube/extractors/YoutubeStreamExtractor.java, focusing on getLikeCount(), parseLikeCountFromLikeButtonViewModel(), and parseLikeCountFromLikeButtonRenderer(). Reproduce the linked YouTube video and inspect the accessibilityText and title values. Done means videos with enabled likes and zero likes report a like count of 0 without a ParsingException, while existing counts continue to parse correctly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100