Cloudtube uses Normal Play Time MediaFragment parameter to fetch a video from the time defined on the t URL parameter (converters.tToMediaFragment()).
Example: https://www.youtube.com/watch?v=1BwxYHNFAgk&t=3m15s
Using git bisect between 406e04b7b0367e99d826fab4f7a1f3ca860342d1 as good and e0238d7e7dbe7c6af03183f00584a7b9e6e1329a as bad, it seems that it's been broken with commit ac3de4b4e6b38e3f209d22f85f319bdf4468aa63, though I don't understand how it could have introduced this regression.
The last link should be https://git.sr.ht/~cadence/cloudtube/commit/ac3de4b4e6b38e3f209d22f85f319bdf4468aa63
Thanks for the bisect! If you set the default quality in settings to "720p" or "Best combined", does the issue persist with ac3de4b?
(fixed links in OP)
There's no
Best combinedin the /settings page on my instance, so tested everything:
720p: initial default, not working, starts at 00:00360p: not working, starts at 00:00Best possible: worked once, but track time was locked on 3:15 while it was playing, after a refresh was not working anymore, starts at 00:00Best <= 1080p: not working, starts at 00:00Best <= 30fps: not working, starts at 00:00
Commenting this line out is sufficient to make the &t=startTime parameter work again (comes from https://git.sr.ht/~cadence/cloudtube/commit/ac3de4b4e6b38e3f209d22f85f319bdf4468aa63#html/static/js/player.js-1-6).
Thanks you for that investigation! I was able to track this down and - I believe - fix it, thanks to you.
Fixed in c811a4aaf9ad9778533fb51f2a5639770707c2a1.
!