requiredBandwidths == 2147483647 for files with attachments

Plex Media Server
, , ,
1

Server Version#: 1.23.4.4775

I have some files with interesting data for requiredBandwidths.

requiredBandwidths=“2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647”

This seems to happen to any files with image attachments, especially covers. It affects both MP4 and MKV containers.

The data for individual streams in the files are correct. And I don’t notice any problems playing these files - but I also usually Direct Play.

I don’t have anything against the eighth Mersenne prime, but it’s always interesting to see 2^31-1. Sometimes it’s used as a special value, but sometimes it indicates a bug. It’s the largest (signed) 32-bit value.

If I remux and strip the image attachments, requiredBandwidths is calculated as expected.

mkvmerge -o newfile.mkv -M oldfile.ext

@FordGuy61, you had a similar-sounding issue. Do you still have any of those files? Do they have image attachments?

MP4 and AVI files not playing - #19 by FordGuy61

2

I never figured it out.

I never looked into embedded images (cover art, etc). That is interesting. I will have to investigate.

None of my MKVs have embedded images. I have not noticed any MKVs have have requiredBandwidth = 2147483647.

I was investigating to see if duplicates might be involved.

In one of my movie libraries I have many duplicates: A MKV disc rip and a MP4/M4V version processed via Handbrake. The duplicate MP4/M4V versions always have requiredBandwidth = 2147483647.

However, to make things even stranger, I have some non-duplicate MP4/M4V with the correct bandwidth info and some with 2147483647.

Thanks for pinging me about this. I’ll investigate the embedded images. See if taking them out helps things.

1 Like
3

Quick update: I’ve no idea. :rofl:

Picked five movies from my primary Plex server - all MP4s, with embedded cover art, and with requiredBandwidth = 2147483647.

Added the movies to a test PMS system where they’ve never existed.

PMS analyzed them and assigned correct requiredBandwidth values.

The movies had all been added within the last 60 days to the primary PMS to libraries using the new movie scanner. PMS on both systems kept “reasonably” up to date, meaning they’re running Plex Pass releases, but I might wait a week before updating to the latest release. Both are now on 1.23.4.4775.

Next Steps:

I noticed some of the MP4s had partially correct requiredBandwidths. The first one or two numbers were correct, but the remainder were 2147483647.

So, I’m wondering if maybe I was not allocating enough time for scheduled tasks on the primary PMS. Deep Analysis, which generates requiredBandwidths, runs as a scheduled task.

I changed scheduled tasks on primary PMS to run from 00:00 to 23:00 (test PMS has all of 10 movies, so time not an issue).

I’ll Plex Dance three MP4s with requiredBandwidths = 2147483647. Once Deep Analysis runs I’ll check requiredBandwidths and also pull log files (I don’t know if log files show anything about requiredBandwidths, I’ve never looked).

That’s where things sit now. I’ve some other things to check as well (movie in single vs multiple libraries, does local media assets or other library settings matter, etc).

Will update occasionally. Sooner if I find anything interesting.

Primary PMS: DS918+, DSM 6, PMS 1.23.4.4775.
Test PMS: DS414, DSM 7, PMS 1.23.4.4775.

4

Embedded cover art is definitely involved.

  • Any MP4 container without embedded cover art has correct requiredBandwidths.
  • Any MP4 container with embedded cover art most likely, but not always, has incorrect requiredBandwidths.

Also, this is only for the the entire movie. requiredBandwidths for the individual video & audio tracks are always correct, whether or not embedded cover art exists.

No cover art:

  • I added five new movies without cover art to my primary server. They were all analyzed correctly.
  • I added the same movies to my test server. They were all analyzed correctly.

Cover art:

  • Movies added to primary server are NOT analyzed correctly.
  • The same movies added to the test server may or may not be analyzed correctly.

So, if you want correct requiredBandwidths, definitely remove the cover art. Still searching for why things are sometimes correct with cover art.

Example:

  • Main server: Raiders & Temple of Doom both incorrect.
  • Test server: Raiders is incorrect, Temple of Doom is correct.

Same files. Same version of Plex Media Server. Same library settings. These are 1080p movies, originally on Blu-ray discs. Same thing happens with 480p movies originally on DVDs.

Test Server: Raiders of the Lost Ark
container="mp4" deepAnalysisVersion="4" has64bitOffsets="1" hasChapterVideoStream="1" hasThumbnail="1" indexes="sd" optimizedForStreaming="1" requiredBandwidths="2147483647,2147483647,15716,9475,7832,7832,7832,7832" videoProfile="high"

Test Server: Temple of Doom
container="mp4" deepAnalysisVersion="4" has64bitOffsets="1" hasChapterVideoStream="1" hasThumbnail="1" indexes="sd" optimizedForStreaming="1" requiredBandwidths="19893,13879,9356,7991,7363,6986,6898,6898" videoProfile="high"

Main Server: Raiders of the Lost Ark
container="mp4" deepAnalysisVersion="4" has64bitOffsets="1" hasChapterVideoStream="1" hasThumbnail="1" indexes="sd" optimizedForStreaming="1" requiredBandwidths="22302,20611,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647" videoProfile="high"

Main Server: Temple of Doom
container="mp4" deepAnalysisVersion="4" has64bitOffsets="1" hasChapterVideoStream="1" hasThumbnail="1" indexes="sd" optimizedForStreaming="1" requiredBandwidths="2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647" videoProfile="high"

1 Like
5

Agreed. I should have mentioned that originally.

I do have files with attachments that don’t exhibit this problem. I’m mildly tempted to look at art/attachment sizes. Perhaps there’s a triggering threshold.

The behavior you see with Raiders is really strange and interesting. I think there’s a code or math problem involved here.

One of those CPUs is Intel, and the other is ARM. :thinking:

By the way, I’ve had success using ./Plex\ Media\ Scanner --analyze-deeply -x --item 35193 to request immediate deep analysis.

6

Can anyone provide me a small enough sample which is easily reproducible ?

I’ll write it up and submit (with the sample attached)

7

I’ll get the samples to you later today.

8

thanks

9

Minimized samples from me.

MKV with attachment:

jellyfish.mkv.zip (3.9 MB)
jellyfish-attachment.mkv.zip (4.0 MB)

jellyfish-mkv-xml.txt (2.0 KB)
jellyfish-attachment-mkv-xml.txt (2.1 KB)

jellyfish-attachment.mkv was produced with this command:

mkvmerge -o jellyfish-attachment.mkv --attach-file kilroy.jpg jellyfish.mkv

MP4 handles attachments differently, but the requiredBandwidths behavior is similar.

jellyfish.mp4.zip (3.9 MB)
jellyfish-artwork.mp4.zip (4.0 MB)

jellyfish-mp4-xml.txt (2.1 KB)
jellyfish-artwork-mp4-xml.txt (2.1 KB)

10

I have the media , in a library, waiting for maintenance to run

1 Like
11

Apologies for the delay. Took longer than expected to get back to this.

100 MB samples of the movies made with dd. Also the XML. If needed I can provide a larger sample.

I loaded Plex Media Server on my Win10 desktop. On that system, any size of embedded cover art resulted in incorrect requiredBandwidths.

Temple.zip (3.7 KB)
Raiders.zip (3.7 KB)

1 Like
12

Thank you!

How does this manifest ?

(what breaks when you are lazy and don’t curate your media ? :rofl: )

13

I’m not personally aware of playback problems that I can ascribe to requiredBandwidths=2147483647. Perhaps this is only a cosmetic issue. But I also don’t have any bandwidth limits configured.

I assume @FordGuy61 will speak up, and there was some other chatter over here:

MP4 and AVI files not playing - #7 by markus101

I don’t think it’s a media curation issue, do you? Poster/cover art attachments are common and legitimate.

In the time Before Plex, I regularly attached poster/cover art to MP4s. I don’t typically do so any more, preferring Plex’s art. :slight_smile:

14

There was a time before Plex? :scream: :roll_eyes:

16

I jumped straight from RCA’s CED players to Plex!

17

Video tapes for me :smiley:

1 Like
18

Was offline for awhile…

I’m not having any current playback issues.

The LG app mentioned in the original thread is now working OK. Remote streaming & transcoding is also working OK, so Plex does not seem to be using the info when making those decisions.

So this may end up being a non-issue.

Having embedded artwork & other metadata is a holdover from when I used iTunes. iTunes reads the embedded metadata. It does not download from the Internet. If I wanted cover art, movie description, etc I had to embed it in the file.

@ChuckPA Thanks for checking into things. Will be interesting to see if the developers (or whoever looks at it) finds anything.

1 Like
19

This appears to be resolved, for the case of files with attachments, in 1.24.0.4897.

(Edit: but see below for additional examples of requiredBandwidths being “off”.)

20

Looks good. Correctly calculated the bandwidth on my movie with embedded artwork.

1 Like
21

@drzoidberg33

1.24.0.4897 and deepAnalysisVersion="5" fixed requiredBandwidths for all of my “real” videos.

I have a few sample files that still exhibit the problem.

They don’t have picture attachments. They do have multiple tracks, including a TrueHD+Atmos track. (None of my “real” library videos have TrueHD+Atmos.) I’ll try to find a minimal reproduction and share it.

Here’s one sample:

“Dolby Cinema - Universe (Nature’s Fury)” from here.

<Media id="407398" duration="187916" bitrate="100709" width="3840" height="2160" aspectRatio="1.78" audioChannels="8" audioCodec="truehd" videoCodec="h264" videoResolution="4k" container="mkv" videoFrameRate="24p" videoProfile="main">
<Part accessible="1" exists="1" id="434565" key="/library/parts/434565/1627359805/file.mkv" duration="187916" file="/path/to/file/Dolby_Universe_4K_SDR_71-Atmos-thedigitaltheater.mkv" size="2367241140" container="mkv" deepAnalysisVersion="5" requiredBandwidths="2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,204182,204182" videoProfile="main">
<Stream id="964208" streamType="1" default="1" codec="h264" index="0" bitrate="92524" language="English" languageCode="en" bitDepth="8" chromaLocation="left" chromaSubsampling="4:2:0" codedHeight="2160" codedWidth="3840" colorPrimaries="bt709" colorRange="tv" colorSpace="bt709" colorTrc="bt709" frameRate="24.000" hasScalingMatrix="0" height="2160" level="51" profile="main" refFrames="4" requiredBandwidths="2147483647,589993,236119,137168,133284,130562,114237,95331" scanType="progressive" width="3840" displayTitle="4K (H.264)" extendedDisplayTitle="4K (H.264)"> </Stream>
<Stream id="964209" streamType="2" default="1" codec="truehd" index="1" channels="8" bitrate="5913" audioChannelLayout="7.1" bitDepth="24" requiredBandwidths="2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,204174,204174" samplingRate="48000" displayTitle="Unknown (TRUEHD 7.1)" extendedDisplayTitle="Unknown (TRUEHD 7.1)"> </Stream>
<Stream id="964210" streamType="2" selected="1" codec="eac3" index="2" channels="8" bitrate="1640" audioChannelLayout="7.1" requiredBandwidths="1621,1621,1621,1621,1621,1621,1621,1621" samplingRate="48000" displayTitle="Unknown (EAC3 7.1)" extendedDisplayTitle="Unknown (EAC3 7.1)"> </Stream>
<Stream id="964211" streamType="2" codec="ac3" index="3" channels="6" bitrate="631" audioChannelLayout="5.1(side)" requiredBandwidths="624,624,624,624,624,624,624,624" samplingRate="48000" displayTitle="Unknown (AC3 5.1)" extendedDisplayTitle="Unknown (AC3 5.1)"> </Stream>
</Part>
</Media>