Server Version#: 1.20.1.3252
Player Version#: 4.34.4 / 4.42.1
Plex Media Server v1.20.1.3252-a78fef9a9 - Western Digital MyCloudEX2Ultra armv7l - build: linux-armv7sf wd-ex2ultra - GMT -05:00
Linux version: 2.40.155, language: en-US
Processor Arm
For some unknown reason, the value bitrate for the audio streams is missing for all the MKV content added after the version update in the media_streams table of the com.plexapp.plugins.library.db database, causing an immediate error when the content is launched on a Remote Web Player.
There is no issue in the reproduction of the content when the App is used, neither for the MP4 content even if was added after the update, neither when the Web Player is running over the same local network than the PMS.
“Adjust Quality” enabled or disabled, has the same effect. “Playback Error – Not enough CPU for conversion of this item.”
The “Analyze” on media or library, doesn’t update the bitrate value in the media_streams table of the com.plexapp.plugins.library.db database,
The content is able to be played on Remote Web Player as soon the value is manually updated: UPDATE media_streams SET bitrate = 147512 WHERE (media_item_id = **XXXXX**) AND (codec = 'aac');
My question is:
It is normal that the mentioned value is NULL for all the audio streams of all the added MKV files since 1.19.3.2852 update?
I don’t think that’s normal. I agree something is weird.
Almost all files I’ve added in the last few weeks have NULLmedia_streams.bitrate. (But they do have requiredBandwidths, implying deep analysis has been performed.)
The files I added most recently, yesterday and a test just now, DO have a value in media_streams.bitrate.
The test file got a value in media_streams.bitrate when I first added it. Then it got an updated value after I ran deep analysis.
sqlite> SELECT id FROM media_items WHERE (metadata_item_id = 6861);
23126
sqlite> SELECT bitrate FROM media_streams WHERE (media_item_id = 23126) AND (codec = 'aac');
128648
128680
It looks to me like bitrate is populated when a file is first added. Can you confirm the same thing? (Edit: this appears to be true for MP4, but not true for MKV)
But then something is happening to remove it later. I haven’t figured out how to trigger this. I have an idea about something else to test - maybe I can trigger it by moving and renaming files. I’ll try that.
I think that when you checked Perform extensive media analysis during maintenance, it successfully updated media_streams.bitrate because you hadn’t performed deep/extensive analysis before.
I already had that checkbox enabled, and deep/extensive analysis had previously been performed. Since it didn’t run twice, my files weren’t updated.
But either way, deep analysis shouldn’t be mandatory. Files should be playable as soon as they’re added, and they should get a bitrate as soon as they’re added. Right?
Because even after maintenance ran some items still had a null value for media_streams.bitrate, this Query helped me to identify that Items with Null value for media_streams.bitrate:
> cd "/mnt/HD/HD_a2/Nas_Prog/plex_conf/Plex Media Server/Plug-in Support/Databases"
> sqlite3 com.plexapp.plugins.library.db
> SELECT media_items.metadata_item_id
> FROM media_streams
> INNER JOIN media_items ON media_streams.media_item_id=media_items.id
> WHERE ((codec = 'aac') AND (media_streams.bitrate IS NULL)) AND (media_items.color_trc = 'bt709');
Then I’ve created a Script that executed the following command for every result:
The bt709 in the query, is just looking a marker for those items that have been previously analyzed but leaving the media_streams.bitrate without a value.
Of course it is not an issue that is related to the video stream color.
Other approach including content with a different audio encoding than AAC, could be the following:
SELECT media_items.metadata_item_id
FROM media_streams
INNER JOIN media_items ON media_streams.media_item_id=media_items.id
WHERE ((media_streams.stream_type_id=2) AND(media_streams.bitrate IS NULL) AND (media_items.color_trc = 'bt709'));
I finally figured out what I was doing wrong in my query. And coming back here I see that you’ve expanded your response.
I think this is correctly identifying my library items that have had deep analysis performed, but also have NULLmedia_streams.bitrate on audio. I see this on the majority of my library.
select distinct(meta.id) from metadata_items meta
join media_items media on media.metadata_item_id = meta.id
join media_parts part on part.media_item_id = media.id
join media_streams stream on stream.media_item_id = media.id
where part.extra_data like '%deepAnalysisVersion%'
and stream.bitrate IS NULL
and stream.stream_type_id = 2
and meta.library_section_id > 0
and part.file != "";
I remain confused about the underlying issue. I believe that something in Plex may be NULLing media_streams.bitrate.
Here’s what I’m seeing; does it match what you see?
When media is first added, an initial audio bitrate is usually populated.
Overnight, deep analysis is performed. But the audio bitrate becomes NULL.
After --analyze-deeply -x, audio media_streams.bitrate is restored.
I’m curious to see if bitrate gets removed again (by the nightly/weekly jobs) after the manual --analyze-deeply is forced.
Edit: I actually wonder if something has improved in 1.20.2. All of my files now have bitrate after deep analysis.
Excellent Query, there were many more that I had not identified.
My case:
If I add new content, no value for media_streams.bitrate is populated., How do I know?, Because I make queries to the database as soon the content is added, and during the next minutes.
When is populated?, as soon I execute --analyze-deeply -x over the content, or after the scheduled maintenance deep analysis is performed, but in the second case, that maintenance only touches the new content, old content is not updated by the maintenance task, keeping a NULL value for media_streams.bitrate
In my case, bitrate is not removed by the maintenance jobs.
I analyzed all of mine last night too. In retrospect I wish I had left a few, isolated them for future experiments.
I added two movies. One has bitrate and the other doesn’t. Neither has had deep analysis completed yet.
When I’m bored I’ll test some more additions and see if there’s any pattern. I wonder if there’s stuff going on in parallel and if there’s a race.
I think movies should work immediately, even if the bitrate values aren’t 100% correct. I think it’s a bug for bitrate to not be populated immediately.
As you add movies going forward, I’m curious if the nightly deep analysis jobs consistently fix them for you, or something else. I’ll watch the same thing here.
For some reason, your Query doesn’t show any new added items with no bitrate, so as the query didn’t return results, I thought the problem was solved.
I realized that new content cannot be played in Remote Web Player, so, using my previous query, I found that all new content has an empty bitrate value.
That query only looks for stuff with with no bitrate AND where deep analysis has been completed.
Does it find your new media if you remove “deepAnalysisVersion” from the where clause?
select distinct(meta.id) from metadata_items meta
join media_items media on media.metadata_item_id = meta.id
join media_parts part on part.media_item_id = media.id
join media_streams stream on stream.media_item_id = media.id
where stream.bitrate IS NULL
and stream.stream_type_id = 2
and meta.library_section_id > 0
and part.file != "";
