Actually fix history view count #8564
                
     Merged
            
            
          
  Add this suggestion to a batch that can be applied as a single commit.
  This suggestion is invalid because no changes were made to the code.
  Suggestions cannot be applied while the pull request is closed.
  Suggestions cannot be applied while viewing a subset of changes.
  Only one suggestion per line can be applied in a batch.
  Add this suggestion to a batch that can be applied as a single commit.
  Applying suggestions on deleted lines is not supported.
  You must change the existing code in this line in order to create a valid suggestion.
  Outdated suggestions cannot be applied.
  This suggestion has been applied or marked resolved.
  Suggestions cannot be applied from pending reviews.
  Suggestions cannot be applied on multi-line comments.
  Suggestions cannot be applied while the pull request is queued to merge.
  Suggestion cannot be applied right now. Please check back later.
  
    
  
    
What is it?
Description of the changes in your PR
#8336 did not really fix the problem, it just made so that each item in history has 1 less view. This meant that, even though the bug appeared to be fixed the first time a video is opened (since that video's views are correctly set to 1), the second time the same video is opened the views are incorrectly set to 3. And #8336 actually introduced a regression, since e.g. enqueued videos were registered as "No views" as reported in #8336 (comment).
The underlying problem was an incorrect usage of Java's
==(same) operator: it was used in the player'sonEventsfunction to check if the media item tag in the ExoPlayer was equal to the one currently set in ourPlayer. The problem with this is, when the player is started from scratch, the media item tag is first updated with a tag with noLoadedMediaSourceattached (since the player is still loading the media source), and then updated again when the media source was loaded. The second update created a new instance of the media item tag (seeStreamInfoTag.withExtras()and its usage inLoadedMediaSourceandFailedMediaSource), so the==operator is not suitable for comparing them. When the player is not started from scratch, but rather just switches to the next item in the queue, only 1 view was (correctly) registered, since the media source is usually already loaded because of the mechanism of pre-fetching the next item in the queue.This PR solves the issue by comparing the stream info url associated with the media item tag before calling
updateMetadataWith()with the new stream info.This PR also makes it so that marking a video as watched does not add one view to it, and also does not update its last access time. Now a new history entry with 0 views is added, and this happens only if one did not exist before. Tell me if I should revert this.
Fixes the following issue(s)
APK testing
app-debug.zip
Due diligence