Metadata doesn't pull for episodes with the same date even when ASS assigns sequential suffix. #84
Comments
|
the result of a scan with the datestamps removed from the filenames. the episodes where ASS assigned an a longer number to the end went unmatched |
Scanner numbering as designed with hack for multiple releases on same day. Are the files added in Plex at the salon/episode/dates as per the logs above? If so, the scanner did it's job and you have an agent issue... You need to add files for it to rescan, even if you rename as scanner results are cached |
|
There is no matching for files, just series.
|
|
When two videos are scanned in from the same day from a channel, then they will be placed under the correct series and correct season (year). However, the videos will only have the filename as their title and the generated thumbnail. They lack an episode number/date (shows as 1900-01-01 in the edit screen, but nothing shows below the title like files showing correctly). The agent throws an error when trying to process data for the file(s): The error is the same for each instance of this, and I notice this as well: "metadata.seasons[2021].episodes[None]". Is this perhaps because the scanner/Plex isn't handling the "hacked" release date correctly resulting in a null episode number? Setting the release date for these affected videos to the correct date and then refreshing the "show" will allow it to properly pull the metadata -- with duplicated infomation on the videos that are actually from the same day and not processed as such due to timezones (but I believe I saw this was a limitation on Plex's handling of same day episodes when release date is the "episode number"?) |
|
So I think the combo of ASS & the YT agent throws an error if i'm using the Channel ID (UC prefix) but not if I use the "all videos uploaded" playlist ID (UU prefix.) It's been a few days so my memory is already fuzzy but I ended up ditching ASS, using the default scanner, and having yt-dl assign S01EXX based on playlist index and now everything is hunky dory. sorry for the hubbub. |
|
if you use the playlist id, the rank in the playlist is used as episode number and it auto reverse the playlist if needed, so it make sense it works then Yes it seem the date based numbering make e = None, which crashed it... @MizeryMade |
|
I think the code and relevant line got a little jumbled. The code seems to have been lifted from line 458, but modifying the relevant line 488 by removing "if len(e)>3: ", the agent no longer throws the critical error when scanning these same day episodes. It correctly shows a date in the log where it was previously showing the error. They still remain as just titles in plex however. Was the change supposed to mitigate that, or was it strictly addressing the subsequent agent crash? EDIT: Thought I would note that currently I have Plex Server 1.22.3.4392... in case a plex update busted your hack? |
|
Was mitigating the crash. |
|
Scanned in two videos from the same day in a clean database. Log(s) as follows: Sinvicta [UC86BKGkw3Giit6yTAntInfQ].scanner.log
|
|
Weird, series title is updated, so the rest of the metadata update should be applied Need to check code but nothing obvious to date |
|
I see the "# videoID not in Playlist/channel item list" on what appears to be any video in a "[UC...]" folder. Is that normal? In toying around with some things, I think this boils down to a limitation on Plex's part. I'm not sure if a recent Plex build might have broken what you were able to accomplish with the hack you implemented into the ASS code for same-date episodes, but it doesn't seem to accomplish what it's trying to do anymore? I think the "YYYY-MM-DDII" episode identifiers are being lost by Plex resulting in these videos being unable to be associated with metadata. Your agent will save the data it's pulling for any video showing in the agent as "metadata.seasons[2021].episodes[None]" to a None.xml file in the folder tree the agent says it's serializing the data to but Plex doesn't seem to do anything with said data. Scanned in the two example files with the stock Plex Series Scanner and your agent (since I noticed the stock scanner was adding "same date episodes" in another library of mine -- added the date in the filename though so Plex's scanner would recognize) and it added the files in similarly to your scanner, but gave a generic title (instead of the filename, they were "Episode 04-28") and showed the "release date" below said title which ASS doesn't. The agent then tried doing it's thing, and only showed one of the videos in the log like when running the test with ASS, but didn't show the "None" and correctly apply metadata to... well, it applied the metadata from one of the videos to both, but it's surely thinking they're the same episode. I don't know. There's only a couple channels I save videos from that sometimes put out multiple episodes per day (although there's cases where due to timezones, the code places videos on the same day when they weren't intended to be) so it's not catastrophic if it doesn't work, haha. |
|
Very good analysis Seems like I can add to Plex from the scanner but the episode number is None so cannot be lopped through the agent side anymore... Need to find another way but not sure there is... |
|
i think you may have to revert to calculating an episode id based on month/day/(hour/min or counter). So, having two videos with the following date/time:
could be:
or
I'd lean towards the latter because i think the former is prone to issues if a new video is added with a previously used date and that older video doesn't exist anymore because it was deleted. |
|
remove the year as the season is the year, to be tested but if two videos can be posted the same minute, we could have issues |
|
yes, the year doesn't need to be there. yes, there may be chance, but I think the percentage of that is really, really small. |
|
Putting together an artificial "episode number" for these files would probably do the trick, and as pointed out would probably play even nicer for instances where episodes are added/deleted over time. Having it apply the number by Month/Day/Hour/Minute would work fine if you're pulling the filedate -- but wouldn't work out as well for those that have the release in the filename as it's not really standard to have the hour/minute in there although I guess you could revert to doing a sequential index for these? I know you recently consolidated the Youtube functionalities into a single mode for the scanner, but perhaps you could break out this functionality into Youtube2, as the current implementation works fine for the majority of cases -- it's only those that do put out more than one video a day. The user is likely to know which sources do this and could choose to run Youtube2 to get these alternate episode numbers. This would of course miss the random case for ones that don't normally release more than one in a day though. Hm. |
|
Just ran into this same issue. Is there anything I can do to help fix this? |
|
I believe I have the same issue. I have downloaded TED talks and it got sorted nicely into different Years (seasons). In 2007 I have the following files in the directory. The directory structure above is as follows:
Only the last video has the proper Metadata, while the others only show the filename. And in Plex, I can't mark them as watched/unwatched independently. The log file shows an error about a Is there a way I can manually make some changes to get these right? |
|
json_video_details['snippet']['publishedAt'] so need to add a check for it and ue Dict to avoit error on missing key for good practice replace if len(e)>3: episode.originally_available_at = Datetime.ParseDate(json_video_details['snippet']['publishedAt']).date(); Log.Info('[ ] date: "{}"'.format(json_video_details['snippet']['publishedAt']))with: if len(e)>3 and Dict(json_video_details, 'snippet', 'publishedAt'): episode.originally_available_at = Datetime.ParseDate(Dict(json_video_details, 'snippet', 'publishedAt')).date(); Log.Info(u'[ ] date: "{}"'.format(Dict(json_video_details, 'snippet', 'publishedAt')))and report please |
|
Doesn't seem to make a difference. The Metadata does still not get updated. This is the new log after a restart of Plex. |
|
Thanks to your feedback, we now know "len(e)" cause the error... replace with: if e is not None and len(e)>3 and Dict(json_video_details, 'snippet', 'publishedAt'): episode.originally_available_at = Datetime.ParseDate(Dict(json_video_details, 'snippet', 'publishedAt')).date(); Log.Info(u'[ ] date: "{}"'.format(Dict(json_video_details, 'snippet', 'publishedAt')))and report please |
|
I updated the file, restarted Plex, refreshed the page with the YouTube video season and tried to refresh the Metadata for one Episode. It showed another error. Looks like that line has a syntax error. |
|
Number of spaces before the command is too much. Put same number of leading spaces as old command Using latest code it is line 490: https://github.com/ZeroQI/YouTube-Agent.bundle/blob/master/Contents/Code/__init__.py#L490 |
|
I used a tab instead of spaces. Unfortunately, still no improvement. The Metadata is not loading. This is the log. |
|
metadata.seasons[2007].episodes[None] |
|
So that means there is no solution for this? |
|
Renaming files so the scanner allocate proper episode number |
|
How do I have to rename the files? Adding a S07EXX in front does not make a difference. I also tried [2007].[01], but also then it does not add the Metadata. |
|
Ok, so I think I figured it out. I had to move the files out of the library, refresh it, rename the files and give them a different date, then put them back into the library. Only then it recognized it and added the Metadata. |
|
Has anyone found a hard fix as of yet? I keep running into this issue and tried following this thread, but nothing seems to work. Only seemingly random videos get matched despite having all my metadata saved as .jsons. @MatthK You mentioned you found a workaround by renaming and re-dating the files, any chance you could share what methods worked for you? |
|
Well, as I mentioned above. By manually giving the files a different date (outside the library) and move them back, then the agent pulled the metadata. |
|
Do you happen to have any examples of a file you had and what you renamed it to to get it working? Do you keep the dates in the filenames? |
|
This is an example. TubeSync downloaded these three files all with the same date. I moved the files out of the directory, renamed the files (change the dates for the 2nd and 3rd file) and moved them back to the library. |
|
I got to thinking about this again recently. It's something that'll rear its head for me on occasion. We can certainly chalk this up as a limitation in the way that Plex works. However, it could still be worked around -- but that'd come from ASS as opposed to the Meta Agent. That left me a little unsure if I should start a fresh thread over at ASS about it, or come back over here since there was already some established conversation about it here. I know that you tried working around it in the ASS code by trying to add the index at the end which didn't completely solve the issue. Unsure if that's due to that functionality being deprecated in Plex at some point or if its due to the approach in implementing it into ASS. I tracked down the Extended Media Scanner which I believe provided the inspiration and went poking round it. It looks to me that it might work on there because it's actually setting "built" episode numbers for the files in question -- which was a suggestion at one point here. Though I know you were a fan of the Date Based approach because it looks cleaner. That said, I went to tinkering with ASS and running some test scans. I don't entirely know what I'm doing, but was able to butcher it enough to test the theory that said "built" episode numbers would work. Awful, I know. Just doing some testing. This gave a MMDDHHMM episode number -- unfortunately it doesn't look like Youtube freely hands over the release/upload time anymore which is why I cobbled it together using the Filedate if pulling MMDD from filename. Certainly possible that someone with fast internet could end up with two files finished in the same minute, but again, testing some things out at least. Assigning the HHMM to each file and not just "duplicates" results in more uniform numbers for sorting and also would prevent some Metadata and Watch History shenanigans from happening if you add/remove videos later and thus removing/changing an index. However bad the means of getting there, the result was a successful scan and Meta search for a set of Test files I had from some time ago that was a dozen or so 2 a day releases. I then tried scanning in my main Youtube folder and all the files were successfully added into Plex and didn't appear to show any issues with Metadata but honestly didn't look over them in too much detail since there were so many. The way I approached it pretty much bypassed the second part of your code where you try setting an Index. Being honest, I get completely lost just looking at that second half! Haha. HOWEVER -- my lack of understanding of that portion didn't allow me to try something else. I ran across this: https://www.reddit.com/r/PleX/comments/bfcmzl/identifying_datebased_episodes_when_two_have_the/ In that reddit post from a few years back, they run into a similar issue with the native scanner and a talkshow. They found that giving the "duplicate" episodes an explicit episode number go them to scan in with the other Date Based episodes. Given I was unable to hack away at the second part of the code, I am left unsure if something like this could be the automatic happy median to our "problem." I don't know how trying to mix Date Based and Explicitly set Episode Numbers would display and sort in Plex or if it would've worked back then but has since been deprecated by Plex. Perhaps something to tinker with by someone who understands coding far more than me, haha. All that said... I know you at one point had some Youtube switches for differing functionality in ASS and then deprecated them as you wrapped it all up into one function that (should've) covered all of our bases -- but perhaps if explicitly setting each episode number is the only way of preventing the missing Metadata issue, then perhaps readding a switch that could then optionally be used by those that want and/or that could be used on those channels that do frequently have multiple videos a day? |
|
Also seeing this issue. FWIW, the MMDDHHMM episode hack didn't work for me, but I'm pulling metadata from the local json files. |
|
Is there any solid solution presently or in progress? Too many videos aren't being matched into my library due to them being hidden by one from the same date, and I've adored this plugin otherwise. |
|
If videos are released at the same time there are issues using date based numbering, the scanner leaves it to the agent strings to renumber episodes and that failed if released at the same time. My fix seemingly didn't work and this is uncharted territory... If somebody want to work on it I will assist |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If you have a channel/list with a bunch of videos from the same date, if you add the first one by itself, the metadata will pull, but adding any additional episodes will cause the metadata to reset for the videos of that date and revert to the filenames / unmatched. Removing the datestamp from the filenames solves this problem sometimes but that's the most I can say right now.
The text was updated successfully, but these errors were encountered: