MediaInfo For Emby Plugin(HDR, Vision, Atmos, DTS:X)

[Cheesegeezer 3086]

51 minutes ago, Derkington said:

It's not the permissions on the binaries, unless they are being called in some special way by the plugin. I have done two things to demonstrate this.

1) I have changed the permissions on both binaries to 777, that's the most permissive a file can be on a Linux system. With those permissions anyone and anything can read, write and execute the binarys.  That made no diffrence.

2) As requested above I have run mediainfo as the user emby, see below.  The emby user was able to run the binary without issue.

sudo -u emby mediainfo --output=JSON "/mnt/media/Movies/The Lion King (1994)/The Lion King (1994).mkv"
{
"creatingLibrary": {
"name": "MediaInfoLib",
"version": "21.09",
"url": "https://mediaarea.net/MediaInfo"
},
"media": {
"@ref": "/mnt/media/Movies/The Lion King (1994)/The Lion King (1994).mkv",
"track": [
{
"@type": "General",
"UniqueID": "325487425604656655180182799631349113347",
"VideoCount": "1",
"AudioCount": "7",
"TextCount": "7",
"MenuCount": "1",
"FileExtension": "mkv",
"Format": "Matroska",
"Format_Version": "4",
"FileSize": "963944906",
"Duration": "5303.560",
"OverallBitRate": "1454035",
"FrameRate": "23.976",
"FrameCount": "127158",
"IsStreamable": "Yes",
"Encoded_Date": "UTC 2021-03-21 19:43:14",
"File_Modified_Date": "UTC 2022-08-20 06:02:43",
"File_Modified_Date_Local": "2022-08-20 07:02:43",
"Encoded_Application": "mkvmerge v49.0.0 ('Sick Of Losing Soulmates') 64-bit",
"Encoded_Library": "libebml v1.4.0 + libmatroska v1.6.2 / Lavf58.45.100"
},
{
"@type": "Video",

 

Can you post a full non password json for a file and I can check the JSON is completely valid. If it is NOT, we will need to don the scuba gear and dive deeper

Edited September 7, 2022 by Cheesegeezer

[Cheesegeezer 3086]

15 minutes ago, neik said:

Well, I'm running out of ideas then...
We actually do have quite a similar setup, also Ubuntu LTS here.

Come on Neik… pull it out the bag lol  

[Derkington 13]

37 minutes ago, Cheesegeezer said:

Can you post a full non password json for a file and I can check the JSON is completely valid. If it is NOT, we will need to don the scuba gear and dive deeper

Here you go.....

 

JSON

Edited September 7, 2022 by Derkington
Did not attach file!

[Derkington 13]

1 hour ago, neik said:

Well, I'm running out of ideas then...
We actually do have quite a similar setup, also Ubuntu LTS here.

Could I be missing a package in my install?   Does the mediainfo plugin depend on OS libraries or other packages beyond mkvtools and media info?

[Cheesegeezer 3086]

1 hour ago, Derkington said:

Could I be missing a package in my install?   Does the mediainfo plugin depend on OS libraries or other packages beyond mkvtools and media info?

Nope as long as it’s MediaInfoCLI then we are good, mkvtoolnix is just to write the info back to the file.

i believe that MediaInfo for linux variants is all in one package, whereas windows requires specific packages

[Cheesegeezer 3086]

1 hour ago, Derkington said:

Here you go.....

 

JSON 9.84 kB · 3 downloads

I’ll look at this tomorrow for you its 23:25 hr now 

[mbguy 38]

Thanks @Cheesegeezerfor this amazing work and everyone else for your contributions.

I have not installed this yet because of this warning on the first line of the wiki: THIS PLUGIN WILL REPLACE EMBEDDED TRACK TITLES TO YOUR MKV FILES

I tried looking for more information for how the embedded track titles will be replaced and what the consequences of this replacement is, so here are my questions:

1. Is there a way to 'control" how the embedded track titles will be replaced?

2. Will the replacement/edit happen only during library scan?

3. Will watch status tracking etc be affected by this "embedded track title replacement"?

4. Are they examples as to how "replacement of embedded track titles" work?

5. Would this change the "Date added" status of the files?

Thanks in advance for your feedback.

Edited September 8, 2022 by mbguy

[rbjtech 4260]

1 hour ago, mbguy said:

1. Is there a way to 'control" how the embedded track titles will be replaced?

The task has it's own schedule and/or run when new media is added.

1 hour ago, mbguy said:

2. Will the replacement/edit happen only during library scan?

No - it will happen as above - but a library scan/metadata refresh is needed to 'see' the changes - ie re-read the MKV file

1 hour ago, mbguy said:

3. Will watch status tracking etc be affected by this "embedded track title replacement"?

No - this will not impact any aspect of the watch or 'item id' status - the item is exactly the same, but will now have titles for each track within the MKV for emby (or any other application) to use.

1 hour ago, mbguy said:

4. Are they examples as to how "replacement of embedded track titles" work?

The Plugin simply uses MediaInfo to get the detailed information and then uses Mkvpropedit (part of mkvtoolnix) to write the new header information.  It does not need to remux the MKV's or anything like that - it just changes the header - thus it is very fast.

1 hour ago, mbguy said:

5. Would this change the "Date added" status of the files?

No - Emby will see this as a metadata update - thus the emby date added is not changed.    If you are referring to the operating system file changed date - then yes, this is changed because it's data written to disk, even if it is just the header.

 

I would suggest you setup a small test instance (a 2nd emby instance takes a few mins to install - use the portable version and use a different network port, close the first instance while you change the new instance port, then restart the 1st instance again) - then you can see exactly what it does.  

[Derkington 13]

9 hours ago, Cheesegeezer said:

I’ll look at this tomorrow for you its 23:25 hr now 

I think I have found the problem. But I do not know how to fix it this second. The system syslog (/var/log/syslog) has these entires, there's a missing library or the library is not where mediainfo expects it to be.  This looks like an Emby library issue, any ideas?

 

ep  5 18:00:17 nuci5 emby-server[7474]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libmediainfo.
so.0)
Sep  5 18:00:17 nuci5 emby-server[7474]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /lib/x86_64-linux-gnu/libmediainfo.
so.0)
Sep  5 18:00:17 nuci5 emby-server[7475]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libmediainfo.
so.0)
Sep  5 18:00:17 nuci5 emby-server[7475]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /lib/x86_64-linux-gnu/libmediainfo.
so.0)
Sep  5 18:00:17 nuci5 emby-server[7476]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libmediainfo.
so.0)
Sep  5 18:00:17 nuci5 emby-server[7476]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /lib/x86_64-linux-gnu/libmediainfo.
so.0)
Sep  5 18:00:17 nuci5 emby-server[7477]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libmediainfo.
so.0)
Sep  5 18:00:17 nuci5 emby-server[7477]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /lib/x86_64-linux-gnu/libmediainfo.
so.0)
Sep  5 18:00:17 nuci5 emby-server[7478]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libmediainfo.
so.0)

 

[Derkington 13]

8 minutes ago, Derkington said:

I think I have found the problem. But I do not know how to fix it this second. The system syslog (/var/log/syslog) has these entires, there's a missing library or the library is not where mediainfo expects it to be.  This looks like an Emby library issue, any ideas?

 

ep  5 18:00:17 nuci5 emby-server[7474]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libmediainfo.
so.0)
Sep  5 18:00:17 nuci5 emby-server[7474]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /lib/x86_64-linux-gnu/libmediainfo.
so.0)
Sep  5 18:00:17 nuci5 emby-server[7475]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libmediainfo.
so.0)
Sep  5 18:00:17 nuci5 emby-server[7475]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /lib/x86_64-linux-gnu/libmediainfo.
so.0)
Sep  5 18:00:17 nuci5 emby-server[7476]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libmediainfo.
so.0)
Sep  5 18:00:17 nuci5 emby-server[7476]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /lib/x86_64-linux-gnu/libmediainfo.
so.0)
Sep  5 18:00:17 nuci5 emby-server[7477]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libmediainfo.
so.0)
Sep  5 18:00:17 nuci5 emby-server[7477]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /lib/x86_64-linux-gnu/libmediainfo.
so.0)
Sep  5 18:00:17 nuci5 emby-server[7478]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libmediainfo.
so.0)

 

Looks like similar issues regarding the libraries packaged with with Emby have caused problems for mediainfo in the past. This looks like an Emby issue to me, and not a user config error or Linux defect issue.

https://emby.media/community/index.php?/topic/108984-mediainfo-for-emby-pluginhdr-vision-atmos-dtsx/&do=findComment&comment=1159175

https://emby.media/community/index.php?/topic/108984-mediainfo-for-emby-pluginhdr-vision-atmos-dtsx/&do=findComment&comment=1157954

 

[rbjtech 4260]

6 minutes ago, Derkington said:

Looks like similar issues regarding the libraries packaged with with Emby have caused problems for mediainfo in the past. This looks like an Emby issue to me, and not a user config error or Linux defect issue.

https://emby.media/community/index.php?/topic/108984-mediainfo-for-emby-pluginhdr-vision-atmos-dtsx/&do=findComment&comment=1159175

https://emby.media/community/index.php?/topic/108984-mediainfo-for-emby-pluginhdr-vision-atmos-dtsx/&do=findComment&comment=1157954

 

Ah yes, I remember now - this was related to an old library that emby was using.

I thought it got updated tbh - what version of emby are you using ? (beta, stable ?)

 

[Derkington 13]

1 minute ago, rbjtech said:

Ah yes, I remember now - this was related to an old library that emby was using.

I thought it got updated tbh - what version of emby are you using ? (beta, stable ?)

 

Stable, Version 4.7.6.0

[rbjtech 4260]

@neik

Can you help us out here please - I believe you resolved this linux issue with the out of date mediainfo/mkvpropedit libraries?

I 'thought' Luke updated the binary in the linux distro but I may well be wrong - I'm not up to speed on the Linux version at all ...

Thanks !

[Derkington 13]

6 hours ago, rbjtech said:

@neik

Can you help us out here please - I believe you resolved this linux issue with the out of date mediainfo/mkvpropedit libraries?

I 'thought' Luke updated the binary in the linux distro but I may well be wrong - I'm not up to speed on the Linux version at all ...

Thanks !

looks like the Emby links to libraries has not been updated in a while.

/opt/emby-server/lib$ ls -la
lrwxrwxrwx 1 root root       23 Aug 21  2017 libavcodec.so -> libavcodec.so.59.21.100
lrwxrwxrwx 1 root root       23 Aug 21  2017 libavcodec.so.59 -> libavcodec.so.59.21.100
-rw-r--r-- 1 root root 26682456 Aug 21  2017 libavcodec.so.59.21.100
lrwxrwxrwx 1 root root       23 Aug 21  2017 libavdevice.so -> libavdevice.so.59.5.100
lrwxrwxrwx 1 root root       23 Aug 21  2017 libavdevice.so.59 -> libavdevice.so.59.5.100
-rw-r--r-- 1 root root   702160 Aug 21  2017 libavdevice.so.59.5.100
lrwxrwxrwx 1 root root       23 Aug 21  2017 libavfilter.so -> libavfilter.so.8.25.100
lrwxrwxrwx 1 root root       23 Aug 21  2017 libavfilter.so.8 -> libavfilter.so.8.25.100
-rw-r--r-- 1 root root  8765888 Aug 21  2017 libavfilter.so.8.25.100
lrwxrwxrwx 1 root root       24 Aug 21  2017 libavformat.so -> libavformat.so.59.17.100
lrwxrwxrwx 1 root root       24 Aug 21  2017 libavformat.so.59 -> libavformat.so.59.17.100
-rw-r--r-- 1 root root  5834648 Aug 21  2017 libavformat.so.59.17.100
lrwxrwxrwx 1 root root       22 Aug 21  2017 libavutil.so -> libavutil.so.57.19.100
lrwxrwxrwx 1 root root       22 Aug 21  2017 libavutil.so.57 -> libavutil.so.57.19.100
-rw-r--r-- 1 root root   715368 Aug 21  2017 libavutil.so.57.19.100
lrwxrwxrwx 1 root root       17 Aug 21  2017 libcom_err.so -> libcom_err.so.3.0
lrwxrwxrwx 1 root root       17 Aug 21  2017 libcom_err.so.3 -> libcom_err.so.3.0
-rw-r--r-- 1 root root    14064 Aug 21  2017 libcom_err.so.3.0
lrwxrwxrwx 1 root root       16 Aug 21  2017 libcrypto.so -> libcrypto.so.1.1
-rw-r--r-- 1 root root  2888184 Aug 21  2017 libcrypto.so.1.1
lrwxrwxrwx 1 root root       16 Aug 21  2017 libcurl.so -> libcurl.so.4.7.0
lrwxrwxrwx 1 root root       16 Aug 21  2017 libcurl.so.4 -> libcurl.so.4.7.0
-rw-r--r-- 1 root root   517024 Aug 21  2017 libcurl.so.4.7.0
lrwxrwxrwx 1 root root       23 Aug 21  2017 libfontconfig.so -> libfontconfig.so.1.12.0
lrwxrwxrwx 1 root root       23 Aug 21  2017 libfontconfig.so.1 -> libfontconfig.so.1.12.0
-rw-r--r-- 1 root root  1160840 Aug 21  2017 libfontconfig.so.1.12.0
lrwxrwxrwx 1 root root       13 Aug 21  2017 libgcc_s.so -> libgcc_s.so.1
-rw-r--r-- 1 root root    71864 Aug 21  2017 libgcc_s.so.1
lrwxrwxrwx 1 root root       21 Aug 21  2017 libgssapi_krb5.so -> libgssapi_krb5.so.2.2
lrwxrwxrwx 1 root root       21 Aug 21  2017 libgssapi_krb5.so.2 -> libgssapi_krb5.so.2.2
-rw-r--r-- 1 root root   323640 Aug 21  2017 libgssapi_krb5.so.2.2
lrwxrwxrwx 1 root root       18 Aug 21  2017 libicudata.so -> libicudata.so.68.2
lrwxrwxrwx 1 root root       18 Aug 21  2017 libicudata.so.68 -> libicudata.so.68.2
-rw-r--r-- 1 root root 28571112 Aug 21  2017 libicudata.so.68.2
lrwxrwxrwx 1 root root       18 Aug 21  2017 libicui18n.so -> libicui18n.so.68.2
lrwxrwxrwx 1 root root       18 Aug 21  2017 libicui18n.so.68 -> libicui18n.so.68.2
-rw-r--r-- 1 root root  3196792 Aug 21  2017 libicui18n.so.68.2
lrwxrwxrwx 1 root root       16 Aug 21  2017 libicuio.so -> libicuio.so.68.2
lrwxrwxrwx 1 root root       16 Aug 21  2017 libicuio.so.68 -> libicuio.so.68.2
-rw-r--r-- 1 root root    55080 Aug 21  2017 libicuio.so.68.2
lrwxrwxrwx 1 root root       18 Aug 21  2017 libicutest.so -> libicutest.so.68.2
lrwxrwxrwx 1 root root       18 Aug 21  2017 libicutest.so.68 -> libicutest.so.68.2
-rw-r--r-- 1 root root    72752 Aug 21  2017 libicutest.so.68.2
lrwxrwxrwx 1 root root       16 Aug 21  2017 libicutu.so -> libicutu.so.68.2
lrwxrwxrwx 1 root root       16 Aug 21  2017 libicutu.so.68 -> libicutu.so.68.2
-rw-r--r-- 1 root root   207408 Aug 21  2017 libicutu.so.68.2
lrwxrwxrwx 1 root root       16 Aug 21  2017 libicuuc.so -> libicuuc.so.68.2
lrwxrwxrwx 1 root root       16 Aug 21  2017 libicuuc.so.68 -> libicuuc.so.68.2
-rw-r--r-- 1 root root  1976040 Aug 21  2017 libicuuc.so.68.2
lrwxrwxrwx 1 root root       18 Aug 21  2017 libk5crypto.so -> libk5crypto.so.3.1
lrwxrwxrwx 1 root root       18 Aug 21  2017 libk5crypto.so.3 -> libk5crypto.so.3.1
-rw-r--r-- 1 root root   186296 Aug 21  2017 libk5crypto.so.3.1
lrwxrwxrwx 1 root root       14 Aug 21  2017 libkrb5.so -> libkrb5.so.3.3
lrwxrwxrwx 1 root root       14 Aug 21  2017 libkrb5.so.3 -> libkrb5.so.3.3
-rw-r--r-- 1 root root   841568 Aug 21  2017 libkrb5.so.3.3
lrwxrwxrwx 1 root root       21 Aug 21  2017 libkrb5support.so -> libkrb5support.so.0.1
lrwxrwxrwx 1 root root       21 Aug 21  2017 libkrb5support.so.0 -> libkrb5support.so.0.1
-rw-r--r-- 1 root root    51200 Aug 21  2017 libkrb5support.so.0.1
lrwxrwxrwx 1 root root       23 Aug 21  2017 libpostproc.so -> libpostproc.so.56.4.100
lrwxrwxrwx 1 root root       23 Aug 21  2017 libpostproc.so.56 -> libpostproc.so.56.4.100
-rw-r--r-- 1 root root    95952 Aug 21  2017 libpostproc.so.56.4.100
lrwxrwxrwx 1 root root       17 Aug 21  2017 libSkiaSharp.so -> libSkiaSharp.so.2
lrwxrwxrwx 1 root root       20 Aug 21  2017 libSkiaSharp.so.2 -> libSkiaSharp.so.80.2
-rw-r--r-- 1 root root  5854576 Aug 21  2017 libSkiaSharp.so.80.2
lrwxrwxrwx 1 root root       19 Aug 21  2017 libsqlite3.so -> libsqlite3.so.0.8.6
lrwxrwxrwx 1 root root       19 Aug 21  2017 libsqlite3.so.0 -> libsqlite3.so.0.8.6
-rw-r--r-- 1 root root  1259120 Aug 21  2017 libsqlite3.so.0.8.6
lrwxrwxrwx 1 root root       13 Aug 21  2017 libssl.so -> libssl.so.1.1
-rw-r--r-- 1 root root   585272 Aug 21  2017 libssl.so.1.1
lrwxrwxrwx 1 root root       19 Aug 21  2017 libstdc++.so -> libstdc++.so.6.0.25
lrwxrwxrwx 1 root root       19 Aug 21  2017 libstdc++.so.6 -> libstdc++.so.6.0.25
-rw-r--r-- 1 root root  1268144 Aug 21  2017 libstdc++.so.6.0.25
lrwxrwxrwx 1 root root       24 Aug 21  2017 libswresample.so -> libswresample.so.4.4.100
lrwxrwxrwx 1 root root       24 Aug 21  2017 libswresample.so.4 -> libswresample.so.4.4.100
-rw-r--r-- 1 root root   112336 Aug 21  2017 libswresample.so.4.4.100
lrwxrwxrwx 1 root root       21 Aug 21  2017 libswscale.so -> libswscale.so.6.5.100
lrwxrwxrwx 1 root root       21 Aug 21  2017 libswscale.so.6 -> libswscale.so.6.5.100
-rw-r--r-- 1 root root   632528 Aug 21  2017 libswscale.so.6.5.100
lrwxrwxrwx 1 root root       16 Aug 21  2017 libuuid.so -> libuuid.so.1.3.0
lrwxrwxrwx 1 root root       16 Aug 21  2017 libuuid.so.1 -> libuuid.so.1.3.0
-rw-r--r-- 1 root root    26384 Aug 21  2017 libuuid.so.1.3.0
lrwxrwxrwx 1 root root       14 Aug 21  2017 libz.so -> libz.so.1.2.11
lrwxrwxrwx 1 root root       14 Aug 21  2017 libz.so.1 -> libz.so.1.2.11
-rw-r--r-- 1 root root    91856 Aug 21  2017 libz.so.1.2.11

 

[neik 837]

17 minutes ago, Derkington said:

looks like the Emby links to libraries has not been updated in a while.

Yes, I think that was the issue.

Let me check how I fixed it once I'm home again.

[neik 837]

OK, back then installing the latest server beta seemed to have helped (see first post on page 21) but I just gave it a try after a long time and am running into the same issue.

I can see that Emby's package includes libstdc++.so.6.0.28 while the OS file on /usr/lib/x86_64-linux-gnu is a bit newer libstdc++.so.6.0.30.
So, replacing Emby's lib by the system lib could help. Unfortunately, I will only get to it by tomorrow, maybe you can give it a try and see how it behaves.

If this helps we could ask Luke if he could update the lib in the beta package, I guess...

[Derkington 13]

Thanks for checking in @neik, I sorted it not to long ago. I tried two things.

1 - Installed the latest beta on a another machine and checked the version of libraries. I can confirm that the files still have the same old dates so I did not go any further with that.

2- I got it working about an hour ago but this is an ugly hack which will be over written by any changes an upgrade might make to the /opt/emby/lib directory. I moved the original symlinks to a different name (***_ORIG)  in the image below and replaced them with a symlink to the OS libraries which are newer (and I believe they are backwards compatable so should not cause issues). This worked, I did not see any errosrs in the system logs even after an emby restart, but I do not like it!  

Another way to do this is copy the libraries to the emby directory and link to those as you suggested, which is what the Emby devs have done in the past.

We should ask the Emby devs to address this in Emby by updating the libraries shipped with Emby or else others will have this issue and may walk away from what is a good plugin!

[Luke 37063]

3 minutes ago, Derkington said:

Thanks for checking in @neik, I sorted it not to long ago. I tried two things.

1 - Installed the latest beta on a another machine and checked the version of libraries. I can confirm that the files still have the same old dates so I did not go any further with that.

2- I got it working about an hour ago but this is an ugly hack which will be over written by any changes an upgrade might make to the /opt/emby/lib directory. I moved the original symlinks to a different name (***_ORIG)  in the image below and replaced them with a symlink to the OS libraries which are newer (and I believe they are backwards compatable so should not cause issues). This worked, I did not see any errosrs in the system logs even after an emby restart, but I do not like it!  

Another way to do this is copy the libraries to the emby directory and link to those as you suggested, which is what the Emby devs have done in the past.

We should ask the Emby devs to address this in Emby by updating the libraries shipped with Emby or else others will have this issue and may walk away from what is a good plugin!

Updating those is an extremely impactful change and often results in older OS's or devices not being supported anymore, so that's not something I can commit to. 

[Derkington 13]

11 minutes ago, Luke said:

Updating those is an extremely impactful change and often results in older OS's or devices not being supported anymore, so that's not something I can commit to. 

Some questions then!

1- Do you see any negatives with the changes I have made? I would rather have a stable emby, so will revert if it might break something or make it unstable.

2 - Is this something a change to the plugin can handle? Or maybe bundle older and new libraries and create the symlink based on the output of the lsb_release -a  command for ubuntu? 

Edited September 8, 2022 by Derkington

[Luke 37063]

9 minutes ago, Derkington said:

Some questions then!

1- Do you see any negatives with the changes I have made? I would rather have a stable emby, so will revert if it might break something or make it unstable.

 

Possibly, but I just don't know. It's not something we've tested. I haven't read the entire topic but why do the emby lib versions matter? If the user has MediaInfo installed on their machine, they can just configure the plugin to point to it. Or is the plugin trying to embed it?

[Derkington 13]

24 minutes ago, Luke said:

Possibly, but I just don't know. It's not something we've tested. I haven't read the entire topic but why do the emby lib versions matter? If the user has MediaInfo installed on their machine, they can just configure the plugin to point to it. Or is the plugin trying to embed it?

I do not know how the plugin was written. But when you install and execute mediainfo you get the follwing in the server logs until you make the changes made in my previous post.

emby-server[7997]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libmediainfo.so.0)
 emby-server[7997]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /lib/x86_64-linux-gnu/libmediainfo.so.0)
 emby-server[7998]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libmediainfo.so.0)
 emby-server[7998]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /lib/x86_64-linux-gnu/libmediainfo.so.0)
emby-server[7999]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libmediainfo.so.0)
emby-server[7999]: /usr/bin/mediainfo: /opt/emby-server/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /lib/x86_64-linux-gnu/libmediainfo.so.0)

And this in the emby debug logs as a couple examples

2022-09-06 17:18:03.906 Info Media Info: PROCESSING OF  The Lion King  HAS STARTED
2022-09-06 17:18:03.906 Info Media Info: Item FilePath = /mnt/media/Movies/The Lion King (1994)/The Lion King (1994).mkv
2022-09-06 17:18:03.906 Debug Media Info: Starting MediaInfo.exe process
2022-09-06 17:18:03.908 Debug Media Info: ************** Reset Embedded Titles = False
2022-09-06 17:18:03.908 Debug Media Info: The input does not contain any JSON tokens. Expected the input to start with a valid JSON token, when isFinalBlock is true. Path: $ | LineNumber: 0 | BytePositionInLine: 0.

2022-09-06 17:18:04.378 Info Media Info: PROCESSING OF  Summer Wars  HAS STARTED
2022-09-06 17:18:04.378 Info Media Info: Item FilePath = /mnt/media/Anime Movies/Summer Wars.mkv
2022-09-06 17:18:04.378 Debug Media Info: Starting MediaInfo.exe process
2022-09-06 17:18:04.381 Debug Media Info: ************** Reset Embedded Titles = False
2022-09-06 17:18:04.381 Debug Media Info: The input does not contain any JSON tokens. Expected the input to start with a valid JSON token, when isFinalBlock is true. Path: $ | LineNumber: 0 | BytePositionInLine: 0.
2022-09-06 17:18:04.381 Info Media Info: PROCESSING OF Summer Wars HAS COMPLETED

It looks like it is embeded by the plugin in some way. There is no option for a user to configure the plugin to use alternative library paths in the UI.

Edited September 8, 2022 by Derkington

[Luke 37063]

Is the plugin trying to use the media info library or launch the executable?

[FrostByte 5049]

1 hour ago, Luke said:

Is the plugin trying to use the media info library or launch the executable?

it uses the cli / executable

[softworkz 3335]

Welcome to the world of Linux where certain things are working in quite different way from Windows!

When you run an application on Windows, it first looks for libraries to load in the same folder as the executable, then in system folders. 

On Linux, it's different. You control the paths for library loading through the LD_LIBRARY_PATH environment variable and the emby-server startup stub sets it like this:

export LD_LIBRARY_PATH=$APP_DIR/lib:$APP_DIR/extra/lib

This means essentially, that Emby loads its own versions of libs rather than those installed on the system. Otherwise most Emby installations on Linux wouldn't work as it would depend on system-installed libs and that's impossible to manage and deal with.

When a plugin launches a process, that process automatically "inherits" the same environment variables as the parent process (= Emby) and that means that a system-installed binary will try to load required libs from the Emby folders rather than the system folders.

 

Possible Solutions

IMPORTANT: Please DON'T EVER mess around with the libraries of the Emby installation.

1. Use a Statically Compiled Binary 

It's possible to compile a binary "fully static". This means that the binary does not need to load any libraries because all are compiled into the executable.

A plugin could include such binary, save it to some place on disk and execute it from there. Also, it wouldn't be required anymore for users to install it to the system.

2. Adjust the Environment Variables

It's also possible to adjust the environment variables for the child process execution. I'm not sure though, whether it would be sufficient just to clear LD_LIBRARY_PATH or whether it would need to be set to a certain (default) value and which one it would need to be.

Edited September 9, 2022 by softworkz

[Dizzy49 94]

The MediaInfo process has been running and at 0.0% for about 5 days now.