Should a playlist mockup w/ 24 items require manually creating 552 state links under Prototype?

Thank you for taking the time to reply. 

I freely admit that I am a complete novice at all of this.
The above was my very first attempt to utilize components. 

Between recording the above video and posting here today (9.5 days later) I had begun to grasp the concept of a component a bit more and (as you suggest) create a "playlist item" component with multiple states, changing the thumbnail and text for each instance. 

You suggest an Active and Inactive state for each. 
I am thinking more in terms of Past, Present, and Future states. 

(Past being useful for conveying "This chapter/portion has been listened to.")

For the sake of conversation, however, if I were to adopt your strategy and trim the states for each "playlist item" component back to Active and Inactive, my prediction is that if I set the trigger to switch between those states as a Tap, then every tapped component in that list would stay in the Active state until clicked a second time. Is there a simple way of setting all other components in the list to Inactive when one is clicked? If so, what is the simplest method? 

Secondly, how would you tie the transcript position, video player proxy's screenshot, and Timeline highlight to the playlist components' states?

Thirdly, you suggest creating the playlist as a separate artboard and turning it into a component to use elsewhere. 
Forgive my very newbie question, but how would I then tie the video screenshots, transcript scroll position, and timeline highlighting to which playlist item has been clicked? 

These are good faith questions. The answers are not clear to me or I would not ask. 

Lastly, for playlists which are longer than the playlist window affords (necessitating scrolling) is there a simple way to not make the playlist scroll position part of the playlist component's state? You can observe explicit playlist scroll positions for each state interfering with my navigation at 1:14 in the above video demo (and my determination by 1:18 to not manually scroll the playlist any more in the video, but to simply click on the next playlist item and let the scrolling happen automatically).

Thank you in advance for your criticism/feedback. 

With regard to your parting thought, "...it might have been easier to prototype in real code (HTML/CSS/JS)", the same exact thought occurred to me. 

The exception is the "JS" part, as I have a mental barrier when it comes to any sort of reading/writing code. 
HTML/CSS might be possible, provided a GUI such as Dreamweaver or Webflow. 

With regard to "Why do them all?" this is a single episode's content. 
At present, there are 70 episodes in total (soon to be 71), so believe it or not, this was a subset. 

I'm still dissatisfied with almost every aspect of my design, however I would rather discover my dissatisfaction on my own time in a mockup, than after I've asked a programmer to actually build something in JS. 

One thing that I am still not satisfied with is the styling of past chapters. 
I like the idea of each chapter having its own progress bar (currently shown in navy blue on past and present chapters) and I like the idea of showing the user which content has been completed, however I'm not particularly keen on the trail of blue progress bars as enough of the episode is played to fill the index/playlist window, as one of my aims is to avoid explicit borders on containers. 

That is something of a tangent to actually wiring up all 24 chapters, however in terms of implementing it, I only triggered the full progress bars as part of the component states.

Inexperience with the process and tooling simply meant that it had not occured to me to mockup what a halfway completed playlist or fully completed playlist would look like, given my style choices for past, present, future index/playlist items (prior to creating component states). 

In any case, I appreciate your taking the time to answer.