Ticket created by ~lomanic on ~cadence/bibliogram-issues
When accessing a profile page and clicking on a post image, an overlay is superimposed over the grayed page to display the post (the page is not refreshed). To discard the post overlay, you have to click on the gray part of the page, outside the post overlay.
While there are shortcuts to navigate posts with ← →, I often find myself trying to close the overlay by pressing the Escape key like on many websites, without success. I would appreciate if pressing Escape could discard the post overlay.
Comment by ~lomanic on ~cadence/tube
Are there any others?
I think there's no more routes.
if someone has /c/stage, does this also automatically give them /user/stage and /stage?
https://www.youtube.com/c/AndreasSpiess redirects (this is new: "short links" redirect to the "slug" one now, this is done client-side and it looks like it's only a call to
history.replaceState()) to https://www.youtube.com/channel/UCu7_D0o48KbfhpEohoP7YSQ, while https://www.youtube.com/user/AndreasSpiess is some another Avocado empty user, redirected to https://www.youtube.com/channel/UCVRacX7DnkMLNrQPQWvgNZAhttps://www.youtube.com/AndreasSpiess redirects properly to https://www.youtube.com/channel/UCu7_D0o48KbfhpEohoP7YSQ
https://tube.cadence.moe/channel/AndreasSpiess (https://redirect.invidious.io/channel/AndreasSpiess also) gives this Avocado user. https://www.youtube.com/channel/AndreasSpiess is a 404.
Is it acceptable to redirect from that name to the standard /channel/{identifier}, or must I render the response directly on those routes?
YouTube now rewrites the URL to the slug one (amusingly, if you click on any tab like Videos, the original visited old short link shows up), we can follow that if it makes it simpler on CloudTube part.
enhancement added by ~lomanic on ~cadence/tube
Ticket created by ~lomanic on ~cadence/tube
Currently, this deleted channel returns a stackstrace on NewLeaf https://www.youtube.com/channel/UC6v6ljwkDGjk8Q7Dj-yjuqg
Traceback (most recent call last): File "/home/cloudtube/newleaf-venv/lib/python3.5/site-packages/cherrypy/_cprequest.py", line 638, in respond self._do_respond(path_info) File "/home/cloudtube/newleaf-venv/lib/python3.5/site-packages/cherrypy/_cprequest.py", line 697, in _do_respond response.body = self.handler() File "/home/cloudtube/newleaf-venv/lib/python3.5/site-packages/cherrypy/lib/encoding.py", line 219, in __call__ self.body = self.oldhandler(*args, **kwargs) File "/home/cloudtube/newleaf-venv/lib/python3.5/site-packages/cherrypy/lib/jsontools.py", line 59, in json_handler value = cherrypy.serving.request._json_inner_handler(*args, **kwargs) File "/home/cloudtube/newleaf-venv/lib/python3.5/site-packages/cherrypy/_cpdispatch.py", line 54, in __call__ return self.callable(*self.args, **self.kwargs) File "/home/cloudtube/NewLeaf/index.py", line 83, in channels return extract_channel(ucid) File "/home/cloudtube/NewLeaf/extractors/channel.py", line 26, in extract_channel channel_metadata = yt_initial_data["metadata"]["channelMetadataRenderer"] KeyError: 'metadata'This should be properly handled, and the same way as Invidious API.
The error code also needs to be handled in CloudTube.
Comment by ~lomanic on ~cadence/tube
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).
Comment by ~lomanic on ~cadence/tube
(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
cloudtube added by ~lomanic on ~cadence/tube
Ticket created by ~lomanic on ~cadence/tube
Cloudtube uses Normal Play Time MediaFragment parameter to fetch a video from the time defined on the
tURL parameter (converters.tToMediaFragment()).Example: https://www.youtube.com/watch?v=1BwxYHNFAgk&t=3m15s
Using
git bisectbetween406e04b7b0367e99d826fab4f7a1f3ca860342d1as good ande0238d7e7dbe7c6af03183f00584a7b9e6e1329aas bad, it seems that it's been broken with commitac3de4b4e6b38e3f209d22f85f319bdf4468aa63, though I don't understand how it could have introduced this regression.
Comment by ~lomanic on ~cadence/tube
So does this mean that the reason for the error is not "unknown" anymore?
I think I just understood that remark, yes, we could/should remove the
Unknown download error:part in the error.Also, what I wrote about youtube-dlc not returning the full error (just "Video unavailable") doesn't apply to yt-dlp/youtube-dl, these libraries return complete errors, see https://www.youtube.com/watch?v=hXi6hrRh0J8 as another example (uploader deleted his account) or just the videos previously mentioned in this discussion.