Comment by ~lomanic on ~cadence/tube
This issue can be closed, there's no stacktrace returned anymore by CloudTube for non-existing channels.
Comment by ~lomanic on ~cadence/tube
This shouldn't have been closed as Implemented, as the MR or commit said, this is only partially fixed as
/{name}channels are still not properly displayed (Cloudtube may redirect to/watch?={name}if{name}matches YouTube video ID format).In the meantime, a new
/@{name}format appeared, such as https://www.youtube.com/@YouTube (nameis case-independent for this format also).I have implemented support for the
/@{name}format in https://git.sr.ht/~lomanic/cloudtube/commit/1b13680c5a6f0d5ca9d2218c799e5ce55ab9bf53 and https://git.sr.ht/~lomanic/NewLeaf/commit/e601f21dd696f91c4adbf2f450c470c318ac3e06, in thealternative-channel-names-atandproxy-videosbranches respectively. If you are interested in pulling these changes.
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