~lomanic


#29 Support alternative channel URLs 6 days ago

Comment by ~lomanic on ~cadence/tube

Are there any others?

https://github.com/yt-dlp/yt-dlp/blob/0fa9a1e23625f0ba4516e5107ce447ac693e7ec1/yt_dlp/extractor/youtube.py#L2467

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/UCVRacX7DnkMLNrQPQWvgNZA

https://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.

#42 Properly handle non-existing channels 8 days ago

enhancement added by ~lomanic on ~cadence/tube

#42 Properly handle non-existing channels 8 days ago

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.

#41 &t=startTime parameter broken on videos 8 days ago

Comment by ~lomanic on ~cadence/tube

#41 &t=startTime parameter broken on videos 12 days ago

Comment by ~lomanic on ~cadence/tube

(fixed links in OP)

There's no Best combined in 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

#41 &t=startTime parameter broken on videos 13 days ago

problem added by ~lomanic on ~cadence/tube

#41 &t=startTime parameter broken on videos 13 days ago

cloudtube added by ~lomanic on ~cadence/tube

#41 &t=startTime parameter broken on videos 13 days ago

Ticket created by ~lomanic on ~cadence/tube

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.

#26 "Unknown download error" on videos blocked on copyright grounds could be more explicit 13 days ago

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.

#26 "Unknown download error" on videos blocked on copyright grounds could be more explicit 20 days ago

newleaf added by ~lomanic on ~cadence/tube