mirror of
https://github.com/tubearchivist/tubearchivist-jf-plugin.git
synced 2026-03-23 20:37:14 +00:00
[GH-ISSUE #6] [Bug]: Plugin doesn't send the proper API request #6
Labels
No labels
bug
enhancement
pull-request
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
tubearchivist/archived-tubearchivist-jf-plugin#6
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ewenlau on GitHub (Apr 23, 2024).
Original GitHub issue: https://github.com/tubearchivist/tubearchivist-jf-plugin/issues/6
Originally assigned to: @DarkFighterLuke on GitHub.
Here's the issue:
I have Tube Archivist set up in a docker container at 192.168.1.120 on Debian and Jellyfin set up without a container at 192.168.1.121 on Windows. My media folder is placed at A:\youtube (it's an NFS share). I installed the metadata plugin in Jellyfin but it doesn't seem to be able to get it.
Upon further investigation, it seems like it is consistently sending a request to the API in this format: http://192.168.1.120:8642/api/channel/A:/youtube/channel-id/, putting the path to the channel folder in the request for some reason. This obviously fails resulting in no metadata actually being retrieved. The same happens for video requests. Here's an example: https://pastebin.com/dF7GVMCx. According to the API docs (or what I grasped from them), the expected behaviour would be to send the channel id without any file paths.
Is this a problem with my configuration?
@ewenlau commented on GitHub (Apr 23, 2024):
I'm no developper, but I think that the issue relies in the way the variable videoTAId is stored in the providers file. It seems to me that for some reason, the full originally obtained path is returned instead of the file name, which causes the API call to fail.
@ewenlau commented on GitHub (Apr 23, 2024):
Actually, I think I know why this happens. Should have thought of this before, it likely fails because I am running Jellyfin on Windows, therefore the slashes in item.Path are backwards, which is not parsed by Split("/"), which also likely the reason why it wasn't noticed during development.
@DarkFighterLuke commented on GitHub (Apr 24, 2024):
Thank you for reporting, I will test the behviour on a Windows machine and I'll update you.
Feel free to contribute by yourself if you want.
@ewenlau commented on GitHub (Apr 24, 2024):
I would love to be able to contribute, but, I'm not a developer, sorry.
@DarkFighterLuke commented on GitHub (May 9, 2024):
Hi @ewenlau , can you try the latest release and check if the issue still happens?
@KevMoore88 commented on GitHub (Jul 7, 2024):
I'm also having this issue currently. TubeArchivist is running under Linux while Jellyfin is on Windows Server 2022 - TA data is on a shared NFS mount.
[2024-07-05 07:59:46.715 -04:00] [INF] [38] Jellyfin.Plugin.TubeArchivistMetadata.Plugin: "http://10.124.88.107:8000/api/video/T:/UCHyBWpfAggsFPDc5A7l_eWA/BmSu2vlFfx8/: NotFound"
[2024-07-05 07:59:46.718 -04:00] [INF] [38] Jellyfin.Plugin.TubeArchivistMetadata.Plugin: "Getting images for video: (T:\UCHyBWpfAggsFPDc5A7l_eWA\BmSu2vlFfx8)"
[2024-07-05 07:59:46.720 -04:00] [INF] [38] Jellyfin.Plugin.TubeArchivistMetadata.Plugin: "Thumb URI: "
[2024-07-05 07:59:46.865 -04:00] [INF] [38] Jellyfin.Plugin.TubeArchivistMetadata.Plugin: "http://10.124.88.107:8000/api/video/T:/UC34KnQchv18OwZJ7WouJbqA/M_QotkUTT5M/: NotFound"
[2024-07-05 07:59:46.867 -04:00] [INF] [38] Jellyfin.Plugin.TubeArchivistMetadata.Plugin: "Getting metadata for video: (T:\UC34KnQchv18OwZJ7WouJbqA\M_QotkUTT5M)"
[2024-07-05 07:59:46.869 -04:00] [INF] [38] Jellyfin.Plugin.TubeArchivistMetadata.Plugin: "Received metadata:
null"
Both Tubearchivist and Jellyfin have R/W access to the NFS share where the videos are stored, and I verified that everything is there. (can also play them)