Closed kieraneglin closed 6 months ago
This one is tricky because getting those appended 01
, 02
... is more complicated than you may expect. The issue is that, in many cases, tracking that data with yt-dlp
's playlist_index
would work with some playlists (since videos are generally appended to playlists) but would be worse than useless for channels (since videos are prepended to channels).
An example: if you index a channel today its most recent video would have an index of 1. If the channel uploads another video, that new video would now have an index of 1 and the video that previously had an index of 1 would now have an index of 2. That constant shifting makes it VERY hard to have a system that works reliably and as a user would expect.
You can get around this by reading the channel in reverse (ie: the oldest content gets indexed first), but completely breaks an advantage of Pinchflat (its uniquely short time between indexing and downloading new content). I think this is how ytdl-sub
does it but don't quote me on that.
Didn't mean to dig too deep there! I'm sure this is a solvable problem, but it's not the ezpz slam dunk it appears to be on the surface. I'll keep working on it and seeing what I can come up with!
I appreciate the care and thought that you've put into not only this issue but the repository as a whole.
For now until you envision a more holistic solution, I may try adding %(release_timestamp)s
as a suffix in lieu of the 01, 02, etc. scheme. Perhaps creating a new variable for that that spits out a hour/minute/second integer might be a viable approach, e.g. release_timestamp
-> '180430'. There would still possibly be collisions if multiple videos were released at the exact same time, but it's an incremental improvement on the current situation.
Thank you for the kind words (:
I wish I could do that - that's where my mind went as well BUT YouTube only returns the date and not the time for all videos. Or there was some other issue related to that when I first looked into it - I'm away from my computer at the moment but I'll check tomorrow.
I was thinking about this more this evening and I think I have a possible solution that'll work in most/all cases. I'll be testing that out sometime this week
@johnwarne @Gex2501 I have a fix for this in #221 which should be going out as part of v0.1.16
later today!
There are some things to be aware of:
{{ season_episode_from_date }}
in the output template will have to update that part to {{ season_episode_index_from_date }}
Thanks for your patience here! This was a tricky one but I'm happy with the approach I ended up using 🎉
That rules! I've only added a handful of sources so far as I was testing migrating away from ytdl-sub
, so I will be your first tester for this functionality when the new release drops. I'll update my profiles, re-add my test sources, and will let you know how it goes in this thread. Really appreciate you looking into this!
@johnwarne much appreciated! The release with this change has been pushed and will be available in ~15 minutes 🤙
Let me know how it works out for you and if I need to make any changes!
Great! In my testing it all seems to be working as intended with the new {{ season_episode_index_from_date }}
template part. From what I can tell in testing, the latest episode from a day ends with 99 and it goes in reverse chronological order from there, e.g. if there are three episodes uploaded on a specific day, they will end in 97, 98, and 99. Success! Super appreciate this.
Wooo! Love to hear it 🎉 - thanks for helping test!
As you saw the index will count down from 99 if it's a channel and count up from 0 if it's a playlist - this should cover the expected behaviour for both those types of sources
I'm testing switching from
ytdl-sub
and have encountered this issue as well. I think the way they've solved it is to append 01, 02, etc. to the end of each episode identifier. It doesn't look as clean in e.g. Plex, but it makes episodes from the same day appear in the Plex library.