Use Youtube title for video metadata instead of the Content ID track title #241
Comments
|
I have found an additional issue yt-dlp/yt-dlp#904 which describes the issue better than I have. The suggested solution is to add the following arguments for the CLI Which based on my reading is equal to adding the following here: postprocessors.append(
{
"key": "MetadataFromField",
"formats": [
"%(title)s:%(meta_title)s",
"%(uploader)s:%(meta_artist)s",
],
'when': 'pre_process',
}
)I have tested this locally with success and I can create an MR if you agree with the overrides. I however do not yet have a solution for the Content ID Album appearing. Something like |
anonamouslyginger
changed the title
|
Success with help from yt-dlp/yt-dlp#1350 (comment)! To remove the Album which is related to the Content ID media (and causes auto Collection creation in Plex) you need one more or all together: postprocessors.append(
{
"key": "MetadataFromField",
"formats": [
"%(title)s:%(meta_title)s",
"%(uploader)s:%(meta_artist)s",
":(?P<album>)",
],
'when': 'pre_process',
}
)As before, I have tested this locally with success and I can create an MR if you agree with the overrides. |
|
Sorry, for some reason, your issue only just now showed up in the feed. No idea, did GitHub have a hiccup? I think I understand the problem. How does that effect videos without music ids? Is that going to change anything for that? |
|
Apologies @bbilly1 my account was incorrectly automatically flagged for being 'spammy' when I raised this issue, so you only saw this when it was unblocked by an GitHub admin. I took some random YouTube videos: and I downloaded them with the current latest docker container ( Then (in a new cloned repo) I changed the FROM bbilly1/tubearchivist:latest
COPY yt_dlp_handler_custom.py /app/home/src/download/yt_dlp_handler.pyWhere then adding in the lines: postprocessors.append(
{
"key": "MetadataFromField",
"formats": [
"%(title)s:%(meta_title)s",
"%(uploader)s:%(meta_artist)s",
":(?P<album>)",
],
'when': 'pre_process',
}
)Once again I downloaded the list of YouTube videos above resulting in 15 (I guess it's consistently missing 3) videos downloaded. Then I ran the following in both cloned repos: for f in ./youtube/*/*.mp4; do mediainfo "$f" > "$f.mediainfo"; doneAnd ran a diff: tldr; Of the 18 YouTube links:
|
|
Ah, this issue was marked as “spammy” so each time I commented I was blocked. It should be visible again @bbilly1 |
|
Thank you for looking into this. Sounds good, please make a PR with your changes.
Tube Archivist will skip videos if yt-dlp can't read it, from your list that would be:
That's why you only see the 15 out of 18 in your queue. |
bbilly1
added
enhancement
tldr;
Note that this is a known issue on the
yt-dlprepository. See yt-dlp/yt-dlp#3146.The suggested solution is to add
--parse-metadata "title:%(meta_title)s"to theyt-dlpcommand.Issue Explanation
When downloading a YouTube video containing music which has been detected and linked by YouTube (see the description of the video) the downloaded metadata for that video contains the metadata of the music video instead of the archived video.
This issue is only visible when the "metadata embed" configuration option in the UI is set to True.
The UI and Elasticsearch data archived is correct for these videos however when importing these videos into another player (e.g. Plex), Plex displays the incorrect metadata which was embedded into the video.
Issue Example
Archived/Downloaded YouTube Video: Animation Supercut - Neebs Gaming
Contains Music Video: Call to Adventure - Comedy
As seen below, Movie name, Album and Performer are incorrect.
Desired Behavior
Given that I am downloading the target video which contains the music for only a small portion of the video, I would like the metadata to reflect the downloaded video. However, I can predict that some other users would like the opposite behavior. I would argue that as this tool is archiving the target video, the metadata should reflect that.
If a change to the default behavior is not acceptable, then a boolean configuration option, or a free form 'extra yt-dlp' configuration option would be fine.
If no change is desired at all, then a warning in the UI would be great.
The text was updated successfully, but these errors were encountered: