Show Total Time In The Playlist

[cheznewa]

Hello/Hi Is Possible To Add A "Total Time" In All Playlists?

It Sums Up All The Video Durations Of A Playlist.

[benoit74]

Yes, looks pretty easy. Where would you like to see this information (screenshot welcomed). Not saying we will follow your recommendation, but I would like to be sure that we add the information on the page(s) where you need it ^^

[aaryansinhaa]

Hey @benoit74 , I would like to work on this issue, but I am new to this repo, can you guide me on how to start contributing, and documentations to understand the structure and other concepts of this repo. Thanks!

[benoit74]

Hey @aaryansinhaa, everything is in the repo. Please share your implementation plan here once you've understood the codebase and I will assign you the issue.

[aaryansinhaa]

Hey @benoit74 ,

TL;DR: I added duration_seconds in videos_channels, and propose computing each playlist’s total duration inside generate_playlist_object(). I plan to implement this feature through 8 small, focused PRs (backend + schema + frontend). Does this approach work for you?

---

I spent some time with the repository, and from what I understand about the flow of the program:

The entrypoint calls scraper.run() inside youtube/scraper:

1. It validates the CLI arguments and prepares all required folders.
2. It calls extract_playlists(), which internally calls
3. extract_playlists_details_from(self.youtube_id) (in youtube.py), which simply identifies what playlists should be scraped from the given YouTube ID.
4. It then computes the list of videos using extract_videos_list() (in scraper.py), which builds the list of all valid videos from the selected playlists, filtering out deleted, non-public, or out-of-range videos, and stores their IDs.
5. After this, the date-after filter is checked, and the general metadata is updated.
6. A ZIM file is created and the header metadata is populated.
7. After initializing the ZIM writer, the scraper starts adding content to the ZIM: channel branding and the frontend UI (ZimUI).
8. It then downloads all videos, subtitles, thumbnails, and retrieves channel information for each video.
9. get_videos_authors_info() (in youtube.py) is where we first obtain the duration for each video.
10. Finally, make_json_files() generates all the JSON structures that will be consumed by the frontend.

From my understanding, this make_json_files() function is the correct place to introduce playlist-level duration aggregation, because this is where:

• all validated videos are available
• all playlists are reconstructed
• playlist JSON objects are created
• channel/home/playlist list JSON files are written

Initially, I thought of aggregating the total duration across all videos like this:

self.total_video_duration = 0
for video in videos:
    video_id = video["contentDetails"]["videoId"]
    self.total_video_duration += videos_channels[video_id]["duration_seconds"]

…but the issue description specifically states:

“To Add A ‘Total Time’ In All Playlists — It Sums Up All The Video Durations Of A Playlist.”

So instead of a global accumulator, the correct approach seems to be computing duration per playlist inside generate_playlist_object():

Inside this function, we already call:

videos = get_videos_list(playlist)

This gives the exact list of videos belonging to that specific playlist.

def generate_playlist_object(playlist):
    videos = get_videos_list(playlist)
    playlist_duration = 0

    for video in videos:
        vid = video["contentDetails"]["videoId"]
        playlist_duration += videos_channels[vid]["duration_seconds"]

    #.... function continued....

Now, In order to add duration_seconds to the video_channels: I modified the function get_videos_authors_info() in youtube.py.

Originally, each entry inside videos_channels[video_id] only contained:

"channelId": ...,
"channelTitle": ...,
"duration": <ISO-8601 string>,

I updated the code inside the loop that processes each video returned by the YouTube API. Specifically, I:

• Imported isodate to parse ISO 8601 durations.
• Converted item["contentDetails"]["duration"] (e.g., "PT10M34S") into total seconds:

duration_iso = item["contentDetails"]["duration"]
duration_seconds = int(isodate.parse_duration(duration_iso).total_seconds())

Extended the stored dictionary for each video to include this new numeric duration:

req_items.update(
    {
        item["id"]: {
            "channelId": item["snippet"]["channelId"],
            "channelTitle": item["snippet"]["channelTitle"],
            "duration": duration_iso,
            "duration_seconds": duration_seconds,   # ← newly added field
        }
    }
)

As a result, videos_channels.json now contains both:

• duration (ISO 8601 string, for frontend display)
• duration_seconds (plain integer, for backend calculations such as playlist total duration)

This allows make_json_files() to easily sum durations using:

videos_channels[video_id]["duration_seconds"]

And then adding the new fields to the Playlist schema in schemas.py so the frontend can access them.

Let me know if this interpretation is correct, or if you would prefer the duration to also appear somewhere else (e.g., playlist previews or the channel.json).

If this direction looks good, I can open a series of 8 small and focussed PRs:

1. Update the video_channel so that it contains duration in seconds.
2. Add tests for duration parsing
3. Add playlist duration aggregation logic
4. Update schema to include duration fields.
5. Add duration fields into playlist JSON generation.
6. Add formatting function (format_duration)(will be placed in utils.py).
7. Add duration to playlist preview
8. Display total playlist duration in UI

I'd be really happy if I get a chance to learn and more importantly contribute to this repository.

Thanks!

[aaryansinhaa]

Hey @benoit74 , Just a small follow-up in case my earlier message got buried. If assigning the issue isn’t necessary, I can start working on it right away and open a PR when it's ready.

Let me know if you'd prefer I wait for assignment or just proceed!

[benoit74]

@aaryansinhaa

• please be patient ; while we aim to provide quick feedback, sometimes it takes a bit more time
• 8 PRs is way too much, 1 PR is sufficient, we do not want 1 PR per line of code changed / introduced but 1 PR per issue (unless the issue is so big that it is worth to split) ; especially because individual PRs you've suggested makes very little sense in isolation
• the details you gave are way too verbose ; pretty sure it was AI-generated ; I don't mind you use AI, this is your choice, but do not use it to generate sloppy content which only adds more burden to reviewers / maintainers
• the overall plan (I only looked at the TL;DR) looks good to me