Conversion to the cmake building system. #4

symbols visibility
WITH_DPMS
WITH_XTEST
WITH_XINERAMA
WITH_XCB
WITH_GSTREAMER
WITH_OGGVORBIS
WITH_LAME
WITH_DVB
USE_TQT_ONLY -- does not work anymore
WITH_XINIT_WORKAROUND
BUILD_DOC
BUILD_TRANSLATIONS
images folder
mimetypes folder
protocols folder
servicemenus folder

check plugins version...done
check XINE_PARAM_GAPLESS_SWITCH and XINE_PARAM_EARLY_FINISHED_EVENT...done
xinelib is required...done
message gst version...done
pick gstreamer1 over gstreamer-0.10...should be ok
man page if any at Debian...done
paranoia - HAVE_LIBCDIO_090...done
paranoia.cpp L51 - DEFAULT_DRIVE "/dev/cdrom"...done
cddb.cp L78 - hello kde-user...don't change
dvbfe.c L23 - #define _GNU_SOURCE...don't change
specific linux headers - EG <linux/dvb/dmx.h> - DMX_OUT_TSDEMUX_TAP...no ideas
diseqc.c L26 - libdvbapi.a does not seem to rely on this header...don't change

check files (missing png, gstreamer)...done
check Deb package...done
cosmetics...done
rem: lame, oggvorbis are options (input/disk/plugins)...done
maybe add kaffeine-iso.desktop from the Deb packaging...done

disc.cpp L477 - "freedb.freedb.org" vs "http://www.freedb.org"...closing on March 31st of 2020

tarball "dvbdata.tar.gz" in image folder...done
why dvb data are contained into an image folder?...might go into their own folder (dvbdata)...done.
see if possible to update those data: https://linuxtv.org/downloads/dtv-scan-tables ...no need.
mef DVB format (v5 vs v3), EG

dvb-format-convert -I dvbv5 -O channel dvb-c/ch-Rega-Sense legacy-format-ch-Rega-Sense

As I announced, I tested it on Debian 7.x (Wheezy) and playing the video with xine looks good.

I tried installing kaffeine-gstreamer, but it works very badly. First it reported errors due to alsasink and xv. After switching to automatic selection, error messages have disappeared. But a separate window was opened for playing the video, instead of playing in the kaffeine window. After closing this window there was again an error message. I'm going to uninstall the package kaffeine-gstreamer immediately…

There are 5 bugs filled for kaffeine and gstreamer, see here

I am puzzled!
I tested the PR on Slackware64-14.1, the xine engine was working fine, not gstreamer ; then I tested on Slackware64-current and the result was quite the opposite, It worked fine with gstreamer but kept crashing with xine.
A wild guess tells me that the xinelib in Slackware-current does not like the ffmpeg version.
Further tests are needed, I wish someone else could build the PR and give some feedback.

@MicheleC regarding the reported bugs, kaffeine has some shishigang tricks for bug 2918 I believe. Look at the XINE_PARAM_GAPLESS_SWITCH and XINE_PARAM_EARLY_FINISHED_EVENT definition.
I wish those who have reported the bugs could have provided a video sample that can throw kaffeine out of balance.

@SlavekB thanks for the testing.

This is as good as It can go (at least for me), actually the gstreamer engine works better for me.
Tested with the big Buck bunny videos: https://sourceforge.net/projects/bunny-peach-open-movie
I needed the gst-libav plugin in order to read the mp4 versions of the videos.

@SlavekB I added a man page and the kaffeine-iso.desktop desktop file from Debian.
you may want to add lame to your packaging btw.

The messages related to the gstreamer versions can be more verbose/explicit or removed...not done.
Rem, libxine is required not requested...not done.

Wonderful work, @cethyel. 👍

I will test the PR tomorrow too (at least with xine-lib) and will report.

@Chris this would be nice thanks.
Be careful with libxine you will be testing because several people have reported troubles with libxine-1.2.10 either at bugzilla or at the PCLinuxOS forum.

libxine 1.2.10 and 1.2.9 didn't work as expected for me (crashes). On the other side, libxine 1.1.21 and 1.2.6 worked out but the videos were rather sluggy, not very pleasant to watch. It boils down to the way you build the libxine with Its dependencies, I guess.

@cethyel building fails for me. 😞

But that might be just a common problem we had with Amarok and other applications too. 😸

https://mirror.git.trinitydesktop.org/gitea/TDE/kaffeine/src/branch/feat/cmakeConv/kaffeine/src/input/disc/paranoiasettings.ui

It seems the includes are missing for KPushButton and friends. It might be that there are more of them. So the question is if you want to look after that or that PR can be merged and you or me are looking to fix that after merging.

@Chris – oh, interesting – I have to try building on R14.1.0 because my previous successful attempt was on R14.0.8~pre!

@Chris I don't experience FTBFS due to missing includes.
From my side, you may add them in this PR, actually It's up to you.

@cethyel: After adding the missing includes, it builds as expected and was never building better for me. 👍

I have build with all functionality and that was fine too.

I buld against xine-lib-1.2.9, which was building fine and running just like ever before, without any problems here. I also build against the latest xine-lib master branch, which resulted in a fine build too and it worked like expected, without any crash or so. That said, I rebuild against every new xine-lib version before testing and also with support for all codecs. Also you need to setup xine right, likely as gstreamer. Observed problems to xine-lib or GStreamer might be related to the way the backends are build or preconfigured. Also playback problems. So most likely nothing what is Kaffeine to blame for.

So to make the test more complete, I also decided to give GStreamer and friends some chance, so I build gstreamer-1.14 with all support it has (24 packages in total) and that was building just fine too and as you observed on your machine, it was running for me just as fine as with xine-lib. There are some UI glitches, or differences, which are minor cosmetical problems or something like that. So there is no automatically switch to the player window tab, if you open some recent file (which the xine backend does), or the slider is reacting differently, but I think that was always the case. I got no crash or likely, so I would say that is working very fine overall. Good work! 😸

@Chris Thanks for your feedback and contribution, its appreciated.
I feel less lonely in that endeavor now.

Thank you both – it seems we are ready for merge!