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)
Best combinedin the /settings page on my instance, so tested everything:
720p: initial default, not working, starts at 00:00
360p: not working, starts at 00:00
Best 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:00
Best <= 1080p: not working, starts at 00:00
Best <= 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.