Triage: Plex does not support metadata in .mkv files

[robinprice]

I set up a few profiles and the common theme between them is to grab 4K videos when possible. While it is true that I am getting the 4K file, the metadata isn't showing as expected in PLEX.

Example profile:

Attributes for "YouTube (Videos / No Live / No Shorts)"

id: 4
name: YouTube (Videos / No Live / No Shorts)
inserted_at: 2024-04-11T02:02:17Z
updated_at: 2024-04-11T02:23:51Z
download_source_images: true
download_nfo: true
output_path_template: /{{ source_custom_name }}/Season {{ season_from_date }}/{{ season_episode_from_date }} - {{ title }}.{{ ext }}
preferred_resolution: 2160p
sponsorblock_categories: 
sponsorblock_behaviour: disabled
download_thumbnail: true
embed_thumbnail: true
download_auto_subs: false
download_subs: true
embed_subs: true
sub_langs: en
download_metadata: false
embed_metadata: true
livestream_behaviour: exclude
redownload_delay_days: 1
shorts_behaviour: exclude

I have noticed that none of the 4K files (.mkv) will show the metadata while anything that comes in as 1080p (.mp4) is working without issue.

Example source from PLEX:

[kieraneglin]

Hey there! Thanks for the report (:

I've looked into this a little and it appears like this is actually a long-standing Plex issue where it won't pull metadata from MKV files (link). My concern is that the only way to fix this may be to remux or recode the video which could take up a ton of system resources and slow downloads considerably.

Anyway, I'll look into this and see what I can find! This could be a can of worms so I can't commit to a timeline, but I'll let you know if I find a fix or workaround

[kieraneglin]

Okay, I've done some testing and I have some inconclusive news:

• Remuxing (ie: changing the container without changing the actual composite files) is pretty quick - it adds 7-12% to the download time for media over 1080p and adds no overhead for media at or below 1080p. Tested on my laptop so YMMV
• Recoding (ie: changing the underlying webm into another format) is very slow and resource intensive to the point of not being an option for regular usage

Remuxing might be the ticket, but it's unclear to me how Plex (and others) handle an mp4 container of a webm stream. To that end @robinprice, I have an ask for you if you're up to it.

I'm away on business until early next week. This normally wouldn't be an issue, but I found out my VPN config is busted somehow so I can't access my test server that has my Plex instance. What I'd like to try is remuxing to mp4 and seeing if this works with Plex. Here's how you'd do that:

• Ensure you're on the latest version of Pinchflat (>=v0.1.12) since this is a brand new feature
• Go to your Pinchflat config directory. In there, you'll find a file stored at extras/yt-dlp-configs/base-config.txt
• In that file, add this single line: --remux-video mp4
• In Pinchflat, find the media item record that corresponds with Episode 922 in your screenshot
  • Make sure you're on the page for just this media item - not the page for the source. The URL should look like /sources/<source ID>/media/<media item ID>
• Click Delete Files from the Actions menu (important!)
• Click Force Download from the Actions menu
• Once downloading is complete, check if Plex has rendered the metadata correctly. If so, does the track's video and audio work as expected?

---

All good if you don't want to do this! I'll get around to testing it as soon as I'm home, but that'll take at least a few days 🤙

[robinprice]

That appears to have fixed the problem. 😄

I didn't want to dig through to see what Episode 922 was in the source below so I took another source that was purely all 4K.

Here is what happened when I did your steps (first one being the remove/force download and the second being untouched):

The audio and video appear to be all in sync as well. I've played the first bit of the video and scrubbed back and forth with the syncing being as expected.

[kieraneglin]

That's great news! Thank you very much for testing 🙌

For now, that change to base-config.txt should fix it for all your media going forward. Unfortunately there's no good way to force-redownload since this will change the file extension (ie: the old file won't be overwritten - the old and new file would exist side-by-side). If you want to fix this en masse my recommendation would be to delete the source(s) + their files then redownload

[kieraneglin]

I just pushed release v0.1.13 which should be up in about ~10-15 minutes. Once that's up you can remove the --remux-video mp4 from base-config.txt (or just delete the file if nothing else was in it - it'll get regenerated on restart). You'll probably want to do that so it doesn't try to remux audio content into an mp4 if you ever want to download music or podcasts

Thanks again for your help in testing!

[robinprice]

Thanks for the great program :)