Bug 1905

I should add that kaboodle R14 just hangs and requires a forced termination when playing videos.

Add audio files too. Kaboodle won't play them.

I now am able to play audio files with kaboodle. I have no idea what happened before, but perhaps after failed attempts at playing videos, there were stale kaboodle processes open that prevented further usage of kaboodle.

I still cannot play videos.

Darrell, when did Kaboodle last work using your older packages?

I am using /usr/share/xine/visuals/default.avi, which plays fine in 3.5.12.

The oldest R14 package set I have is from Sept 2012. Kaboodle fails to play videos and freezes the same way as described.

I tested the next oldest package set from Jan 2013. Kaboodle opens, refuses to play the video, but does not hang or freeze.

Could be related to bug 2010.

Not sure if this is related, but my kaboodle does not work here in R14.

When opening a video, I have the messagein standard output:

/opt/trinity/bin/artsd: symbol lookup error: /opt/trinity/lib64/libarts_xine.so.0: undefined symbol: ao_new_port

I bet it has something to do with "recent" xine 1.2 support in TDE.

http://osdir.com/ml/kde.users.multimedia/2003-11/msg00200.html

>I bet it has something to do with "recent" xine 1.2 support in TDE.
While xine 1.2 could be one contributing element, I am using Slackware 14.1 with xine 1.1.21 and xine-libs 0.99.7. I still have the same problem not playing videos. I do not see any symbol errors.

Kaboodle doesn't work here either.
Starting from command line, I get an error
unix_connect: can't connect to server ...
which is also repeated every time I try to open a video file.
Some debugging shows that Kaboodle's engine fails to open the file (file player.cpp line 99 "if(!engine->load(current))" ), so probably something to do with arts.
(A lot) more investigation is required.

> Not sure if this is related, but my kaboodle does not work here in R14.
> When opening a video, I have the messagein standard output:
> /opt/trinity/bin/artsd: symbol lookup error: /opt/trinity/lib64
> /libarts_xine.so.0: undefined symbol: ao_new_port

After further analysis, the situation is as follow.
1) Audio files: Kaboodle does play at least .wav and .ogg files without problems.
2) Video files: testing using .mp4 files fails. The problem is related to arts and/or xine since I also get the same message that Francois already posted if I launch artsd before running Kaboodle.
"/opt/trinity/bin/artsd: symbol lookup error: /opt/trinity/lib/libarts_xine.so.0: undefined symbol: ao_new_port"

> I bet it has something to do with "recent" xine 1.2 support in TDE.
I will try to investigate on this. Not sure what's the best point to start from, so any suggestion (Francois, Slavek) is welcome.

And this extract from the build log should be a good hint ;-)

checking for _x_ao_new_port in -lxine... no
checking for ao_new_port... no

> And this extract from the build log should be a good hint ;-)
> checking for _x_ao_new_port in -lxine... no
> checking for ao_new_port... no

As mentioned in comment 8, I am using xine-lib 1.1.21 and not 1.2. My latest tdemultimedia build log shows the following:

checking for _x_ao_new_port in -lxine... yes
checking for ao_new_port... no

I am unable to play videos in kaboodle despite using xine-lib 1.1.21. I do not have any build logs from 3.5.13.2 for comparison, which I last built a very long time ago.

I do not see any stdout/stderr when I start kaboodle from the command line. Running 'strace kaboodle' or 'strace kaboodle /usr/share/xine/visuals/default.mpv' indicates a kaboodle timeout. I am unsure but the timeout seems related to an arts SoundServerV2 socket.

There are several separate causes for the observed problem here.

For libxine < 1.2.x we are probably running into this old unsolved KDE 3.5.9-series bug:
https://bugs.kde.org/show_bug.cgi?id=162248

For libxine >= 1.2.x not only is that bug still valid, but for unfathomable reasons the upstream xine developers continue to advertise _x_ao_new_port in the public headers, yet the symbol itself has been removed from libxine.  When I started rewriting the aRts plugin to use a different public accessor I ran smack into the KDE 3.5.9 bug described above.

Michele, this is currently assigned to you.  Do you still want this bug/have time/ability to trace the threading deadlock?

> Michele, this is currently assigned to you.  Do you still want this bug/have
> time/ability to trace the threading deadlock?
Tim, feel free to work on this bug. Beside still having little free time (even though from this week things are getting a little better), I think your greater knowledge/ability will help in solving this bug more quickly. As a note, I haven't worked on this bug at all in the last 3 weeks.

(In reply to Timothy Pearson from comment #13)
> For libxine >= 1.2.x not only is that bug still valid, but for unfathomable
> reasons the upstream xine developers continue to advertise _x_ao_new_port in
> the public headers, yet the symbol itself has been removed from libxine. 
> When I started rewriting the aRts plugin to use a different public accessor
> I ran smack into the KDE 3.5.9 bug described above.

Regarding the xine >= 1.2, see bug 2010 comment 9.

OK taking bug back and setting to NEW.

I have traced and repaired the threading deadlock in GIT hash 697d333.  This should restore full functionality with libxine < 1.2.x.

The root cause was enabling full Xlib threading support in TQt3.  Instead of randomly crashing the arts server deadlocked due to locking Xlib in the helper thread via the XNextEvent call.  The (suboptimal) solution was to change to polling via XPending before calling XNextEvent.  This will generate ~100 extra wakeups/sec. worst case but then again with a media player running maybe this is expected anyway?

This deadlock on XNextEvent is unfortunately a relatively common problem with XLib and its xcb backend:

http://mail-archives.apache.org/mod_mbox/harmony-dev/200905.mbox/%3C200905181317.n4IDHtGQ002008@d06av03.portsmouth.uk.ibm.com%3E

https://www.opengl.org/discussion_boards/showthread.php/173172-Xlib-and-openGl-in-multithreading

https://www.libreoffice.org/bugzilla/show_bug.cgi?id=41870

etc.

Please test and verify.  I still need to rewrite the audio interface for xine >= 1.2.x.

Thanks!

Tim

Well done Tim.
I will do a full rebuild tonight and in case no FTBFS are encountered, I will be able to test on xine 1.2 tomorrow.

(In reply to Michele Calgaro from comment #17)
> Well done Tim.
> I will do a full rebuild tonight and in case no FTBFS are encountered, I
> will be able to test on xine 1.2 tomorrow.

It won't work there yet--as mentioned in Comment 16 only xine < 1.2.x works at the moment pending a rewrite of the audio interface to use xine's public audio methods.

> I will be able to test on xine 1.2 tomorrow.
Sorry, that was a typo. I meant to say xine 1.1 (libxine1 1.1.21 to be precise)

xine >= 1.2.x support added in GIT hash a05ceb5.

Marking NEEDINFO for now pending results of tests on multiple Xine versions.  1.2.x works here without issue.

>xine >= 1.2.x support added in GIT hash a05ceb5.
Did you mean commit 68cff160?

My first tests are kaboodle again plays videos with xine 1.1.21 (Slackware 14.1). I do not have a system with xine 1.2+. I tested the default xine /usr/share/xine/visuals/default.mpv and some mp4 videos.

A note to other testers, kaboodle must be configured to autoplay. Otherwise kaboodle sits there like a bump on a log until pressing the Play button.

Good job and thanks!

(In reply to Darrell from comment #21)
> >xine >= 1.2.x support added in GIT hash a05ceb5.
> Did you mean commit 68cff160?

Yes I do.  I committed to the original hash and then realized afterward that I had managed to push a whole bunch of irrelevant debugging and todo stuff with it, so I blew away the original commit and did it right the second time. ;-)

> My first tests are kaboodle again plays videos with xine 1.1.21 (Slackware
> 14.1). I do not have a system with xine 1.2+. I tested the default xine
> /usr/share/xine/visuals/default.mpv and some mp4 videos.
> 
> A note to other testers, kaboodle must be configured to autoplay. Otherwise
> kaboodle sits there like a bump on a log until pressing the Play button.
> 
> Good job and thanks!

Well since it works for you on Xine < 1.2.x and works for me with Xine >= 1.2.x I'm going to close this report.

Thanks all for reporting, debugging, and testing!

Tim

Doesn't seems to be working here with xine 1.2.
On my local system, kaboodle plays audio file ok, but crashes when playing a video.
On a VM clean Debian/Jessie install, tdebase + tdemultimedia only, Kaboodle plays audio ok, but do nothing when playing video (no crashes, no error messages).

Let's forget about the crash in my local system (which could be a little "dirty"), but in a clean Debian install it should work straight away.

I temporarily reopen this bug, waiting confirmation/denial of the problem.

(In reply to Michele Calgaro from comment #23)
> Doesn't seems to be working here with xine 1.2.
> On my local system, kaboodle plays audio file ok, but crashes when playing a
> video.
> On a VM clean Debian/Jessie install, tdebase + tdemultimedia only, Kaboodle
> plays audio ok, but do nothing when playing video (no crashes, no error
> messages).
> 
> Let's forget about the crash in my local system (which could be a little
> "dirty"), but in a clean Debian install it should work straight away.
> 
> I temporarily reopen this bug, waiting confirmation/denial of the problem.

Are you building tdemultimedia from source or using the nightly builds for this test?  If the latter, the build farm never got a chance to catch up (especially on Jessie due to its constant changes and apt inconsistencies on the master Debian mirror) so the xine 1.2 fix would not be available in binary form at this time.

Another behaviour here, opensuse 13.1 using xine 1.2.5 running today's R14 git.

Opening kaboodle then opening a video works correctly.

But if during the playback, I open another video, the 2nd video is not displayed, only sound ... The video output gets all black.
I have to explicitely press the stop button so that the video stream is stopped, then I can open another video and it plays correctly.

I have seen no crash at all.

I don't know whether the crashes reported here are the same, but I filed bug 2150 again a crash that occurs when restoring to normal screen from full screen.

>Are you building tdemultimedia from source or using the nightly builds for this 
>test?
Sorry for the late reply, being quite busy today. 
I always build every package from source, even the dependency packages.

(In reply to Francois Andriot from comment #25)
> Another behaviour here, opensuse 13.1 using xine 1.2.5 running today's R14
> git.
> 
> Opening kaboodle then opening a video works correctly.
> 
> But if during the playback, I open another video, the 2nd video is not
> displayed, only sound ... The video output gets all black.
> I have to explicitely press the stop button so that the video stream is
> stopped, then I can open another video and it plays correctly.
> 
> I have seen no crash at all.

This should be fixed in GIT hash c0913ce.

(In reply to Michele Calgaro from comment #23)
> On a VM clean Debian/Jessie install, tdebase + tdemultimedia only, Kaboodle
> plays audio ok, but do nothing when playing video (no crashes, no error
> messages).

Does the fix in GIT repair this issue?  I have not seen this issue on my Jessie system.

Thanks!

>> On a VM clean Debian/Jessie install, tdebase + tdemultimedia only, Kaboodle
>> plays audio ok, but do nothing when playing video (no crashes, no error
>> messages).

> Does the fix in GIT repair this issue?  I have not seen this issue on my Jessie
> system.

With the latest tdelibs+tdebase in a clean VM Jessie install, kaboodle now plays the audio of the video file. I need to rebuild tdemultimedia to do a full test.
I will update again possibly tomorrow, time permitting.

>> On a VM clean Debian/Jessie install, tdebase + tdemultimedia only, Kaboodle
>> plays audio ok, but do nothing when playing video (no crashes, no error
>> messages).

> Does the fix in GIT repair this issue?  I have not seen this issue on my Jessie
> system.

Tested with a full rebuild in a VM Jessie environment. mpg video still not displaying in Kaboodle, only the audio track can be heard.
This are the xine packages installed. Kernel is 3.14-2 because with 3.16-2 virtualbox locks up (this seems to be a problem with the 3.16 kernel and VB, looking at google...)

ii  libarts1-xine-trinity                 4:14.0.0-b039+20141012+0326     amd64        aRts plugin enabling xine support
ii  libxine2                              1.2.6-1+b1                      amd64        xine media player library – meta-package
ii  libxine2-bin                          1.2.6-1+b1                      amd64        xine video/media player library – binary files
ii  libxine2-doc                          1.2.6-1                         all          xine video player library – documentation files
ii  libxine2-ffmpeg                       1.2.6-1+b1                      amd64        MPEG-related plugins for libxine2
ii  libxine2-misc-plugins                 1.2.6-1+b1                      amd64        Input, audio output and post plugins for libxine2
ii  libxine2-plugins                      1.2.6-1                         all          xine video/media player library ‒ meta-package for commonly-used plugins
ii  libxinerama-dev:amd64                 2:1.1.3-1                       amd64        X11 Xinerama extension library (development headers)
ii  libxinerama1:amd64                    2:1.1.3-1                       amd64        X11 Xinerama extension library
ii  x11proto-xinerama-dev                 1.2.1-2                         all          X11 Xinerama extension wire protocol

As further note, hoovering the mouse over the video file in Konqueror displays a file tip with a preview icon. The preview icon is correct.
Git sources are from yesterday (Oct 11).

I am still unable to replicate this.  What architecture is your test system?

Can you provide detailed replication instructions with a freely available video file?  A screenshot of Kaboodle while it is supposed to be playing video, but is only playing audio, would be helpful, as would killing and launching artsd in a separate terminal window and posting the output of that.

Thanks!

Created attachment 2320 [details]
kaboodle "playing" a video

I downloaded and tried the following file
http://clips.vorwaerts-gmbh.de/big_buck_bunny.mp4
from this page:
http://camendesign.com/code/video_for_everybody/test.html

The attached screenshot shows Kaboodle playing the video, but not video displayed.

My host machine is amd64 Debian/Jessie, guest is amd64 Debian/Jessie. Both are running kernel 3.14-2 since using kernel 3.16-2 would result in a host kernel panic as mentioned in previous comments.

The only thing to note is that this clean environment is actually a progressively-updated clean environment. At the beginning of 2014 I create a new Debian/Jessie machine, no DE at all. Using snapshots I do all my testing, then every couple of months I update the original image (again, no DE at all), so each time I can start from a clean console environment for my testing.
I do not expect this to be the cause of the problem.

Thank you for the detailed information.  The linked video plays fine here, so time for a stupid question I should have asked before: Debian is finicky with certain non-free codecs; does xine (from the xine-ui package) on your machine play the video?

Thanks!

Ok, I have done some further investigation and these are the results.

> so time for a stupid question I should have asked before: Debian is finicky 
> with certain non-free codecs; does xine (from the xine-ui package) on your
> machine play the video?
And I should have thought about it before as well ;-)
1) On the VM system, the package xine-ui was not installed (only libxine2 was installed). After installing xine-ui, everything is ok. xine plays the video and magic-magic Kaboodle plays the video! Time to add an install dependency for xine-ui?


2) On my local system, it is not actually Kaboodle crashing but the SoundServer. Kabooble remains operational and after dismissing the DrKonqui crash window, I can use it to play other audio files.

I have uploaded the following crash report for this problem
TDECRSH-ee450de-d30e451-fd4b2b1-121ca22-70f653c-fcc81dc-1333283
in case you want to take a look.

Nevermind, forget the crash dump because I also find the problem with my local system.
As I (kind of) expected, the problem was caused by a dirty xine lib in my system, a left over from when I was testing this bug some time ago.
Clean up and now everything is ok, so I am closing this bug again.

Sorry for the mess...
I am actually reopening the bug so we don't forget to decide what to do with the dependency for xine-ui (see comment 35)

(In reply to Michele Calgaro from comment #37)
> Sorry for the mess...
> I am actually reopening the bug so we don't forget to decide what to do with
> the dependency for xine-ui (see comment 35)

Please, check whether it is sufficient package libxine2-x, instead of xine-ui. For example - from kaffeine dependencies:

libxine2-x | libxine1-x (<< 1.1.20) | libxine1 (<< 1.1.8-2)

> Please, check whether it is sufficient package libxine2-x, instead of xine-ui. 
> For example - from kaffeine dependencies:

Well spotted Slavek! libxine2-x is enough (and makes more sense to me as well).

(In reply to Michele Calgaro from comment #39)
> > Please, check whether it is sufficient package libxine2-x, instead of xine-ui. 
> > For example - from kaffeine dependencies:
> 
> Well spotted Slavek! libxine2-x is enough (and makes more sense to me as
> well).

Added libxine*-x dependency for libarts1-xine in commit 4304cd8f.

Thanks, I was just about to push the same patch when I got the tde-commit notification of yours :-)