mirror of
https://github.com/tubearchivist/tubearchivist-jf-plugin.git
synced 2026-03-23 20:37:14 +00:00
[GH-ISSUE #30] [Bug]: The season is not set by year (as before) #25
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#25
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 @Druidblack on GitHub (Nov 24, 2024).
Original GitHub issue: https://github.com/tubearchivist/tubearchivist-jf-plugin/issues/30
I've read the documentation
Operating System
Linux (docker)
Your Bug Report
The season is exposed to bad weather (as before). After updating jf to 10.10.0 and the tube jf plugin to version 1.3.4. New videos are placed in the season 1 folder, and not as previously in the folder with the season by year of release.
Relevant Jellyfin log output
Anything else?
It definitely started after upgrading to version 10.10.0, the plugin will update automatically to the latest version.
@ThisIsHetz commented on GitHub (Nov 26, 2024):
I'm confirming the same. I'd mentioned, over in the Discord, that I might open an issue after I first attempted a redeploy but I was delayed. I've since spun up a brand new instance of Jellyfin and the issue has persisted. I'm not well-versed enough in C# to pinpoint the breaking change but something seems to have been altered with Jellyfin itself so that it now prefers filenames when setting the season and episode numbers. It may be worth opening an issue on their GitHub, if someone hasn't already, since it looks like Jellyfin itself is ignoring the
ParentIndexNumberout of all the provided metaadata. That is to say "Jellyfin seems broken, not the TA Plugin."Anyway, if the VID/filename has anything along the lines of
s#,e#,#x#or similar then Jellyfin will use that to assign Season/Episode numbers. For some reason VIDs mainly lead to Season 1 (JF probably defaults to 1 when it doesn't find a substring) but I've plenty of videos being placed in "Specials" (Season 0) and in other seasons. A few would also be out of order within their "Season" because a string likee12in the filename would assign episode number 12 to the video.For the moment I'm manually editing my Jellyfin's
library.dbin order to correct the metadata. I discourage anyone unwilling to risk breaking things further from doing the same but I'll detail the process below for the insistent.Kludge - Not Advised
This will produce the
TopParentIdfor the mounted library folders. We want to take note of the one associated with the TubeArchivist library. On my machine the folder is "/youtube" but it may be different for you if you've mounted it under another name.That
TopParentIdcan be used used in the query below to update the DB.Explanation:
All other metadata is being correctly sent, received and exists in the database. We can use
strftimeto get the year from thePremiereDate(when the video was posted to YouTube) of each entry. That's used to set theParentIndexNumber(season number) and theSeasonName("Season YYYY"). In the process we're also setting theIndexNumber(episode number) toNull.We're targeting the youtube library with the
TopParentId, specifying no folders (IsFolder = 0) and only entries where "TubeArchivist" appears in theProviderIDs. I am fairly confident that should prevent the query from touching anything it shouldn't. That said - do so at your own risk.There's probably a more concise way to write the query but it has been working for me while we await a fix. I threw the query into a Bash script, followed by a
curlto the Jellyfin API to do a library refresh, which I run any time I've new videos in TA.@hugalafutro commented on GitHub (Dec 25, 2024):
If I were to delete a channel from jellyfin and then re-import it would put all videos in single Season 1?
Before it was Season 2023, Season 2024 etc which I liked, but now it's very disparate triggering my imagined ocd, so I'd rather have Season 1, Season 2 etc, than 2 different formats if that makes sense.
@tim-tx commented on GitHub (Dec 26, 2024):
I'm getting occasional inconsistencies even in the "new" season grouping, i.e. for one channel there is a "Season 3" with one episode, and a few episodes in Season 1 have non-zero episode numbers. These seem to just be random
@miltuss commented on GitHub (Dec 26, 2024):
I also encounter the same problem. It's been over a month since the developers fixed this issue ☹️
We want a resolution to this very problematic problem. We need seasons by date
@ThisIsHetz commented on GitHub (Dec 27, 2024):
@hugalafutro
Based on what I have observed, I would say "no." "Season 1" seems to be what Jellyfin defaults to when it cannot determine otherwise. But if any Video IDs from the channel you're re-importing have a substring that Jellyfin determines to be Season/Episode numbers it will use them as such. A VID like
BS6nGLmRrMIwill end up in "Season 6" because of theS6substring, as an example.I have not tested the hypothesis but enabling embedding metadata in TubeArchivist, and setting the option to prefer embedded metadata inside Jellyfin for your TubeArchivist library, may be a solution. However, if that does work, it will only work on new downloads. I looked to the Discord for discussions on the matter and found that embedding of metadata only occurs upon download. At this time there is no built-in method of retroactively embedding metadata.
This means you'd need to come up with your own solution for retrieving metadata from your TubeArchivist instance to then provide to something like ffmpeg in order to embed it into your existing downloads. I'm not sure how feasible it would be to go about that programmatically.
EDIT: It does not appear that embedding metadata resolves anything. In retrospect that should have been obvious to me. "Season" simply doesn't exist among the metadata retrieved with yt-dlp and Jellyfin will not infer a season from the embedded "date" field. TubeArchivist itself would have to create and fill a "Season" field when it fills other metadata in order for it to work, but that probably shouldn't be the responsibility of the core application. "Season" isn't something that users who aren't using the plugin would likely ever need or want in their metadata.
@lamusmaser commented on GitHub (Dec 27, 2024):
This can be done, but it requires ffmpeg (or similar) to copy the file and make the embedded updates with the copy. I've got a similar script for fixing Radarr movies and it takes a good amount of time for each video. Capturing the metadata from TA/ES is actually the easier part.
@tim-tx commented on GitHub (Dec 28, 2024):
What about writing an nfo file for every video in the library, should be fast
@lamusmaser commented on GitHub (Dec 28, 2024):
You can do that, but it will break TA filesystem scans.
@tim-tx commented on GitHub (Dec 28, 2024):
Maybe symlink videos to a separate dir then write nfo there, and that's your JF library
@miltuss commented on GitHub (Dec 28, 2024):
I have the same problem too. I share the logs:
@tim-tx commented on GitHub (Dec 31, 2024):
Based on some tests I believe this to be more of an issue with Jellyfin than the plugin.
I tried making a simple skeleton plugin that just sets
IndexNumber(ie episode) to some integer (52) and nothing else. I set this plugin to be the only Episode Metadata provider for my library. In some cases this worked, in other cases the episode number was set to some other value. In my test library the filenames are uuids and apparently my test plugin was only successful in setting an Episode number (52) when the second field of the uuid filename both started and ended with a letter instead of a number. For example for the filenamebf3b3590-be7f-11ef-a885-250694b0925f.mp4, this would get Episode number 52 becausebe7fstarts and ends with a letter. In another case085958e0-927a-11ef-859a-f5d8aac99cd2.mp4, Jellyfin would decide to ignore my plugin and set the episode number to927(the numeral in the second field of the filename). So apparently you don't even need the pattern "E##" to set the episode number (or maybe a filename that looks like a uuid just matches some other part of a regex) and Jellyfin will always prioritize the filename above whatever provider is specified.I think this kind of behavior from Jellyfin is really a mistake. I'm guessing it's written like this due to the common practice of media collectors organizing everything by files and folders (probably before software like Jellyfin, or anything with a database, even existed) where naming was very important. There's no reason why you can't use file names to guess metadata, but it should not be the first priority, or at least it should be configurable.
Are there any possible workarounds?
Embed metadata in filesNot a solution according to @ThisIsHetz@travisterrell commented on GitHub (Jan 2, 2025):
With regards to the NFO files solution, it didn't work in my attempts. In short, I couldn't convince Jellyfin to actually read the nfo files and use them for metadata. (I'm really hoping it's just some setting I've overlooked.)
I have Jellyfin set to generate nfo files, so I edited them for a show and set each Season property to the video year. I then turned off the TubeArchivist metadata providers and did a "replace all metadata," and...yeah, it just removed it all. (And it retained the existing season structure of "everything in Season 1", FWIW.)
I tried doing the same with a new library, disabling every metadata provider before selecting any folders. In this case, the files imported, but weren't sorted within a Show at all, so presumably the nfo's were still not being read.
Soooo, I'm not sure. You would think that Jellyfin would be able to utilize the nfo files it creates in the absence of a real metadata provider, but if it can, I cannot figure out how. Also it's probably obvious, but to prevent frustration: If you're going to be manually modifying the nfo files, ensure that you don't still have a metadata provider enabled+generate nfos enabled first. Otherwise, they'll be overwritten by metadata fetched from TubeArchivist.
Aside from that, the API sounds like it might be the most favorable option to me (I'm generally wary of manually manipulating data without going through an application, even though it shouldn't be problematic in this particular case.) It could perhaps even be re-implemented in the modern plugin if required, even if would suck to have to revert to that method for only 1 piece of metadata. I believe the reply above is correct about this being how the old one worked, though, as the archived readme.md says that the season structure will be created after imports are complete.
@tim-tx commented on GitHub (Jan 2, 2025):
Yes I saw Jellyfin ignore / rewrite a season number specified in a NFO file in a simple test case.
Maybe the old plugin still works?
Anyway here's a script that uses the web API that should basically do the same as the query from @ThisIsHetz above, i.e set season number to the year and unset the episode number. Note it relies on finding series based on if
ProviderIdsincludes aTubeArchivistkey, and I had some series that were created by the old plugin that did not have this key. A 'Search for missing metadata' on the series fixed that.@DarkFighterLuke commented on GitHub (Jan 10, 2025):
Hi guys, sorry for the delay, it's a busy period for me unfortunately.
I can confirm that it's a Jellyfin issue, it doesn't place Episodes in the season specified by SeasonName attribute.
I am looking forward to fix it someway.
@DarkFighterLuke commented on GitHub (Jan 10, 2025):
I tried your script, but it doesn't change the season name for me and it is foreseeable that is this way, SDK and REST API use the same logic under the hood.
A workaround I can try to implement is to create a scheduled task that updates the seasons names based on their content.
@tim-tx commented on GitHub (Jan 10, 2025):
It's verified working for me... though you have to update/rescan the series or collection for the change to "finalize" in a GUI, which this does not do, but could be made to do so. I have made some customizations for local use (possibly there is some mistake in the intermediate version here) and am running this daily with success. (Though yes I do not set SeasonName, only ParentIndexNumber, I was unsure of the reason for this apparent redundancy and just use numerals. Fits my use case anyway.)
@DarkFighterLuke commented on GitHub (Jan 10, 2025):
Yeah, it doesn't tackle the season name problem, thanks for providing this workaround btw.
@tim-tx commented on GitHub (Jan 10, 2025):
I'm not sure if maybe it takes a refresh but it looks like SeasonName does eventually update to match ParentIndexNumber for me, fwiw
EDIT: It seems to happen for me after two or maybe three refreshes. After one refresh I see a log message like "removing virtual season XX" and after the second refresh SeasonName is updated
@DarkFighterLuke commented on GitHub (Jan 12, 2025):
Here is a bug filed on Jellyfin issues: https://github.com/jellyfin/jellyfin/issues/13197.
They are triaging it, so we should wait to see if it will be fixed.
@DarkFighterLuke commented on GitHub (Mar 1, 2025):
Good news folks, the bug on Jellyfin is finally fixed, even though it is currently only on the release-10.10.z branch and no new minor version has been released.
To get it working right away, you'll need to build Jellyfin from that branch, or alternatively you have to wait for the new Jellyfin minor release.
@hugalafutro commented on GitHub (Mar 1, 2025):
@DarkFighterLuke I'm ok with waiting, but once JF updates to the version with the fix, do I need to do something? Or will it rename the season by itself next library update? Thanks.
@DarkFighterLuke commented on GitHub (Mar 1, 2025):
@hugalafutro no, you won't have to do nothing except rescanning the collection for metadata, the plugin had no bug, it was just on Jellyfin side.
@Zeager0 commented on GitHub (Apr 8, 2025):
I am still experiencing this issue on Jellyfin 10.10.7 but only with a smaller subset of videos. It seemed to fix the majority but here is a video that shows in JF as Season 8 Episode 7. I also had to manually update yt-dlp to download this particular video.
@hugalafutro commented on GitHub (Apr 8, 2025):
I've updated to 10.10.7, rescanned the whole TA library with "replace metadata" and nothing changed. The latest video from each channel doesn't even get its name / thumbnail scrapped. Going to try to remove the library and re-add it to see if it fixes anything, leaving the logs from just rescanning here before I lose them, here's a snippet of 2 files one which had metadata previously and a new one which is just named as the garbled youtube string:
@hugalafutro commented on GitHub (Apr 8, 2025):
After removing - readding - rescanning it's a total mess, the only metadata it pulls is description of the videos
Wish I'd left it as it was...
should have been a red flag
@Druidblack commented on GitHub (Apr 12, 2025):
New videos are added to the seasons again according to the year of release. Unfortunately, updating the replacement data did not help to recreate the old data. Apparently you need to delete the library and add it again.
@hugalafutro commented on GitHub (Apr 12, 2025):
I've deleted and readded - the screenshot is from the "new" library. I then rescanned with the 2 checkboxes that say use embedded metadata which put all videos in order of release in single Sesaon Unknown (which is fine by me), but neither the episodes or channels or "actors" have pictures like before.
I mean as long as I can play it is the main thing, but it looked a lot nicer before.
edit: I think the issue is the BadRequest but I have no idea why it says that, I have not changed anything, just updated Jellyfin
@lamusmaser commented on GitHub (Apr 12, 2025):
The linked Issue for Jellyfin is still not merged into main. Unless there is something else happening, this is still not in an official release for Jellyfin.
@Zeager0 commented on GitHub (Apr 12, 2025):
It was supposed to be fixed by https://github.com/jellyfin/jellyfin/pull/13611
@lamusmaser commented on GitHub (Apr 12, 2025):
You're right, and I see that in the Release Notes for 10.10.7.
@lamusmaser commented on GitHub (Apr 12, 2025):
Is this part of your
TA_HOST?@hugalafutro commented on GitHub (Apr 12, 2025):
thank you, there was a discrepancy between
TA_HOSTNAMEand what the address was in JF plugin (domain vs ip). It's rescanning now and sayingOkinstead ofBadRequest, but it's a lot of files so it'll take a bit. I'll edit this post with results later.edit:
sigh, no luck, it's even worse than before lol. I deleted the library, restarted jellyfin, added it back, rescanned - this is what I get now. The only metadata scrapped is the description. log looks ok:
@DarkFighterLuke commented on GitHub (Apr 14, 2025):
Are you using the latest version of TubeArchivist? The plugin only supports that one.
@hugalafutro commented on GitHub (Apr 15, 2025):
Yup, always last versions of everything I'm a bit mental about upgrades, I literally cannot do anything done unless I check for updates
Jellyfin: 10.10.7
JF TA Plugin: 1.3.0.0
TubeArchivist: v0.5.1
@lamusmaser commented on GitHub (Apr 15, 2025):
Latest version for the JF plugin is v1.3.6.
@hugalafutro commented on GitHub (Apr 15, 2025):
@lamusmaser you are right, I was under impression JF plugins autoupdate seems I was wrong. I will update the plugin, restart JF and rescan and update this post with results. If simple rescan won't do it i will remove / re-add the library again, so it might be a lot later I'll update this post.
Now I have another list of stuff to check for update yay - JF plugins
edit: YAY success! It pulls the images and all now, although some videos still sort into Season not sorted by year if that makes sense
@DarkFighterLuke commented on GitHub (Apr 17, 2025):
@hugalafutro can you point me the video that is being inserted in "Season 6"?
@Zeager0 commented on GitHub (Apr 17, 2025):
@DarkFighterLuke I linked a video above that was still having issues.
@hugalafutro commented on GitHub (Apr 17, 2025):
all the mistakes from my channels:
s2 https://www.youtube.com/watch?v=t2X3wlvoShg
s9 https://www.youtube.com/watch?v=H9X0Auo14PM
specials https://www.youtube.com/watch?v=n97sEn0X3BM
s6 https://www.youtube.com/watch?v=ApwmPle6-3s
s2 https://www.youtube.com/watch?v=2x4U2WqeWkU
s5 https://www.youtube.com/watch?v=Yr4hLuu-554
s6 https://www.youtube.com/watch?v=ZCg62b6X0NM
s7 https://www.youtube.com/watch?v=laWg0fd7x7c
s7 https://www.youtube.com/watch?v=zZ0b7X9gTTI
s8 https://www.youtube.com/watch?v=Dx8-62MfiTQ
s9 https://www.youtube.com/watch?v=OM486CH9x2Q
(this one has season 95)
s2 https://www.youtube.com/watch?v=JY4GfoqI2-0
s3 https://www.youtube.com/watch?v=3X6KP3xq9fw
s5 https://www.youtube.com/watch?v=T5cU5X2X1Ts
s8 https://www.youtube.com/watch?v=fBNOW8-1suw
s95 https://www.youtube.com/watch?v=NbA4qT95x4s
s4 https://www.youtube.com/watch?v=ZG04XxY4x5k
@anonamouslyginger commented on GitHub (Apr 19, 2025):
It's good to know I am not alone, I am seeing the exact same issue.
I have the latest versions of Jellyfin, the TA plugin, TA, and I am getting some media being stored in 'Season X' folders that are not years. Deleting and rebuilding the Jellyfin Library resulted in the same state; as outlined in the comments from others above.
A sample of the videos I have (in the event it might help):
'Season 9' - https://www.youtube.com/watch?v=b4wQpL9x8qw
'Season 6' - https://www.youtube.com/watch?v=TyT7-syn6x0
'Season 9' - https://www.youtube.com/watch?v=IkfUNc9x7MU
'Season 73' - https://www.youtube.com/watch?v=wP9On73X82g
'Season 4' - https://www.youtube.com/watch?v=PezNZw_04-0
'Season 6' - https://www.youtube.com/watch?v=R6X4RRMJDUA
Now it might be a massive coincidence, but the series number seems to also appear in the YouTube hash for the video, followed by either an 'x' or a '-'.
@DarkFighterLuke commented on GitHub (May 26, 2025):
Hi guys, I was actually able to reproduce your situation, but I don't have currently the time to investigate into Jellyfin codebase to find the bug that they have, so , if you want and I would really appreciate it, fire an issue on their repo to report this situation.