aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/yt_dlp_plugins/extractor/radiko_time.py
Commit message (Collapse)AuthorAgeFilesLines
* more right-thinking way of handling timefree 30HEADmastergarret2024-11-011-9/+4
| | | | still hardcoded to not work though
* prepare for "timefree 30"garret2024-09-171-0/+11
| | | | | | | | | | | | | https://prtimes.jp/main/html/rd/p/000000032.000007490.html "radiko to launch new service "Timefree 30" this autumn, allows listening to programmes from the past 30 days, no 3-hour time limit" probably can't spoof having the plan, that's fine it might work if you pass cookies of a timefree30 account though, so i'm adapting the time stuff to account for that the plan doesn't exist yet, and i don't know how i would go about detecting it yet, so i'm just hardcoding to False for now
* fix RadikoSiteTime test (forgot)garret2024-08-111-1/+1
| | | | | changed func in eb94441420845970d48fe7b4e30cc5eed78ac95a , forgot to change the test also
* change names of RadikoTime functions so that datetime is the "default"garret2024-08-051-4/+8
| | | | generally we should work in datetimes, the strings should be the "special" ones
* make time classes inherit from datetime.datetimegarret2023-11-101-32/+13
| | | | | | | | | | | so now it's just datetime.datetime with custom input and a few new funcs instead of actually having a datetime.datetime internally and jankily kind-of-exposing it doesn't really affect things currently, but it makes something i want to do possible (and it's generally just the better way of doing it) Co-Authored-By: 9382 <omnomaidan@gmail.com>
* 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
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2024-11-21 18:29:40 +0000