After building openPHT 1.6, it now works great on Ubuntu, but I’m missing some text in the configuration menu’s. All “new” menu entries are empty lines, not sure how to proceed. I’ll try later to delete the config files/replace them with clean ones.
It would be great if someone would make a nice resume of all this efforts for anyone willing to compile Are all this issues related to 14.04 only or they apply also to 15.10 or 16.04?
Now I have a running OpenPHT 1.6 on Ubuntu. However, it seems I’m missing some of the menu entries - I just see blank lines with check boxes next to them. Looks like it’s all “the new ones”
Here is a detailed guide of my steps to build OpenPHT 1.6 under Ubuntu 14.04 LTS. It is using exactly the same ffmpeg 2.8.7 version bundled in OpenPHT 1.6 and the same configure command with the non-existent options removed. The Kodi specific patches for ffmpeg are applied too.
Everything works perfectly on my Intel Nuc.
Build OpenPHT 1.6 from source on Ubuntu 14.04 (Intel NUC)
Backup the old version /opt/openpht and the configuration ~/.plexht
cd ~
mkdir ~/ffmpeg-sources
cd ~/ffmpeg-sources
wget http://ffmpeg.org/releases/ffmpeg-2.8.7.tar.bz2
tar xjvf ffmpeg-2.8.7.tar.bz2
cd ffmpeg-2.8.7
cp -r ~/openpht-source/lib/ffmpeg/patches patches
On Ubuntu 14.04 I have some tearing in the menu …
Also I get an error because : libexif-x86_64-linux.so is missing … root@14-04-64VM:l/opt/openpht/bin# ll system/ total 1920 drwxr-xr-x 2 root root 4096 juin 10 17:21 ./ drwxr-xr-x 3 root root 4096 juin 10 17:21 ../ -rw-r--r-- 1 root root 1737445 juin 10 16:55 ImageLib-x86_64-linux.so -rw-r--r-- 1 root root 204314 juin 10 16:55 libcpluff-x86_64-linux.so -rw-r--r-- 1 root root 11055 juin 10 17:12 libsse4-x86_64-linux.so root@14-04-64VM:/opt/openpht/bin#
so corresponding error : 16:22:53 T:140497496827904 ERROR: Unable to load /opt/openpht/bin/system/libexif-x86_64-linux.so, reason: //opt/openpht/bin/system/libexif-x86_64-linux.so: No such file or directory
Is it common to all delivery or specific to Linux (Ubuntu) portage ???
can we use the libexif provide by Kodi 16 for ex. ??
father_mande:
I don’t have any menu tearing. Have you tried changing the VSync option in the Preferences?
I don’t have the libexif library on my Ubuntu 14.04 system and I don’t have the error you have received. I assume it is in your plexhometheater.log. Have you tried ldd against the plexhometheater binary?
tearing exist even Vsync is disable or enable only during playback
… I had this problem with 1.5.2 and Vsync change solve it … not now
I use a fresh .plexht or using a 1.5.2 .plexht (update of OpnePHT)
… Things I will have to do :
… verify Intel Graphics Libraries (because I use a Celeron J1900 based Ubuntu 14.04 but IGP driver is from vivid (but provide for Ubuntu 14.04) … BUT VAAPI is called and work as well. I use a Vmware environment for compilation and first tests (better to quickly going back) … then transfer to the system where the Hdmi monitor (sound) is connected
… check with another screen to be sure it’s not linked to the screen …
during my first tests … I will try to run a slideshow (photos)
… some small tearing also appear in the edge of each image during transition …
… so I had a look to the plexhometheater.log and discover the warning
YES I have check with ldd that all the requested libraries (and version compare to my dev. system) are present
… this lib (part of Kodi/xbmc) are not linked with plexhometheater
Thanks for your help …
I search to identify if problems is “local” to my own environment, due to the Linux portage … or generic … before creating separate post or issue …
Philippe.
Thanks … 1 yes I have run ldd and nothing is missing …
libexif-x86_64-linux.so … comes with kodi (or xbmc) part
… as you can imagine this error occurs during photo slideshow …one error for each photo …
2 For tearing :
A) yes I have try (as requested for 1.5.2) to put Vsync disabled or enable only for playback
… in 1.5.2 this (vsync disable ) suppress the tearing …
… I have to do another test to be sure it’s not linked to my screen … (Hdmi monitor with sound) use for tests and development …
B) I have to check the library system … for X … my system is a Celeron J1900 and need for Ubuntu 14.04 a vivid version of Intel Graphics processor … so perhaps a version mismatch between some libraries …
C) tearing is only in the menu (for the limited test I have done … ) no problem during movies and music
… some tearing seems to be visible with slideshow BUT only on the edge during transition … it’s why I have look to plexhometheater.log … and see the warning on exif lib missing …
I will check all (again) because I had generated different version of OpenPHT up to obtain the complete version (with all patches need to ffmpeg …
Globally … I have good result with this version … so I don’t want to “open” separate post or issue if it’s specific to the Linux portage …
Thanks again for your help, alone it’s easy to jump or forget somethings … 8-|
F.Y.I.
under Ubuntu 14.04 Intel IGP
I have redo a full install to have exactly the same libraries (when requested) … except new ffmpeg
for OpenPHT 1.5.2
for OpenPHT 1.6
On my screen :
with Vsync enable or selected to be driver dependent :
1.5.2 generate tearing (like pressing repetitively keys)
… tearing in settings menu (frequent) and on menu (search, videos, etc.) BUT never during playback
1.6 generate also tearing (eventually after some delay)… same tearing rules as 1.5.2
with Vsync Disable or “activated during playback”
1.5.2 DON’T generate any tearing in any case, menu, settings, etc.
1.6 keep exactly as before : tearing … like if Vsync parameters is not use or apply …
… verification in guisettings.xml … Vsync is at 0 (so normal value for “disable” … “0”
FWIW, I maintain a set of debian files for building on Debian Jessie / SteamOS here. I’ll have to review all of this a bit more to see if I can switch over to using the rebuilt FFMPEG packages from Ubuntu.
“Also note that the system bundled ffmpeg do not have some kodi specific patches and a plex.direct specific patch. Using ffmpeg avio as network transport will not work correctly.” - kwiboo
Though, because of this, unless it was absolutely necessary, having to manage extra patches for ffmpeg is not always ideal. Maybe I’ll make a “openpht-unstable” package to always have as a backup that uses internal ffmpeg.