aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/yt_dlp_plugins/extractor/radiko_time.py
Commit message (Collapse)AuthorAgeFilesLines
* minor housekeepinggarret2023-10-251-1/+0
| | | | mostly whitespace changes
* fix broadcast day stuffgarret2023-10-131-7/+14
| | | | | | deduped code for working it out also fixed bug in broadcast_day_end where it shifted forward by a day, but didn't also set the time to 5am
* ShareTime: handle day out of range for monthgarret2023-10-131-3/+9
| | | | | | | | | the site will accept this so we have to as well i should probably try and handle this in SiteTime but cant be fucked right now iirc the site just blanks out if the day is out of range so the datetime exception matches the site's behaviour 👍
* fix executable permsgarret2023-10-131-0/+1
| | | | | extractor shouldnt be executable time thing should so i can test it easier
* check end of broadcast day, not end of air timegarret2023-09-101-0/+8
| | | | | | | | | | | | | The old behaviour assumed programmes were deleted precisely a week after their end time. This isn't actually the case though, as long as it's within a week of the _broadcast day_, the site will let you. This lead to the extractor bailing out (Programme is no longer available) when in fact the programme was still playable on the site. The fix uses the same logic as RadikoTime.broadcast_day to find the broadcast day (TODO: one func for both?), then sets the time to 05:00:00 the next day - i.e. the start of a new broadcast day.
* Migrate to unified time handler thinggarret2023-08-241-0/+114
now only one thing gets passed around and it has most everything we need closes #11