Bug 2010

Could be related to bug 1905.

Created attachment 2107 [details]
Screenshof of preview tab in file properties

Konqueror does not freeze here ...

It looks like, depending on the video format, different mechanisms are involved.
When using "MKV" video, the preview tab works, it simply show a picture from the video. It's the same picture as the tooltip in konqueror file view.

With "AVI" video, the tooltip preview shows a black picture, and the preview property tab shows an empty embedded "media player". It does not freeze, just doesn't display anything ...

What behaviour do you have in 3.5.13.2 ? Picture preview or embedded video player ?

With .mp4 files there is no freeze here either.
Just nothing gets played, that is. 
Very very likely that the cause is the same of bug 1905, since the same error message can be observed:
"/opt/trinity/bin/artsd: symbol lookup error: /opt/trinity/lib/libarts_xine.so.0: undefined symbol: ao_new_port"

I'd bet that ao_new_port does not have proper symbol visibility set.  Let me look into this; if true, it's a 5 second fix.

>I'd bet that ao_new_port does not have proper symbol visibility set.  Let me >look into this; if true, it's a 5 second fix.
No, it's more than that. I am still looking at it (I only have time here and there in this period) but it has to do with the "migration" to xine 1.2.
When building tdemultimedia on a clean environment, _x_ao_new_port is not detected and libarts_xine.so consequently does not export it (instead ao_new_port is available). In this situation, both Kaboodle (bug 1905) and Konqueror have problems.
In my local system I still have libxine1 installed as well. When I build tdemultimedia locally, _x_ao_new_port is detected and I can get Kaboodle and Konqueror to play the audio stream of a video file, but not yet the video stream.
So I think there two components in this problem:
1) the migration from libxine1 to libxine2: perhaps changes to the source code of libarts_xine.so are required (need to investigate)
2) the absence of the video stream. _x_ao_new_port is probably only for the audio stream, but while navigating through the libxine API documentation I also noticed the presence of _x_vo_new_port. My (yet unverified) guess is that _x_vo_new_port takes care of the video stream. Darrell mentioned that in 3.5.13.2 there is "only nominal support" for videos, and perhaps he meant the absence of the video stream. This problem may have generated a long time, when the ***_new_port functions were added.

I am working on this, but expect it will take a while to fix it (this week almost no time at all).

> Darrell mentioned that in 3.5.13.2 there is "only nominal support" for videos
Actually that was mentioned on a comment about bug 1905, but the two bugs are definitely caused by the same problem.

OK, thanks for the detailed information.  Assigning the report to you so that there is no accidental duplication of effort.

> Assigning the report to you so that there is no accidental duplication of
> effort.
Yep, no problem. This week (and perhaps the next) I don't expect to be able to do much, after that I should have more time available.

I tried to investigate some information. As I discovered with xine 1.2 _x_ao_new_port (original ao_new_port) are considered internal and are no longer exported. See: http://permalink.gmane.org/gmane.comp.video.xine.devel/16901

As a replacement could be used xine_open_audio_driver, but that function assumes the "name" of the driver, not the structure that define this driver. However, libarts_xine uses standard xine video driver and itself internally use as audio output driver. But this internal driver does not have name that could be used in xine_open_audio_driver.

As a solution I can think of: in libarts_xine internally fully define the output audio plugin - for example 'artsfifo', which would then be applicable to the function xine_open_audio_driver. But I'm not sure if this way is possible. Or separate audio output plugin as an independent library that would be correctly classified as audio output plugin in xine.

I fear that both will require a lot of effort.

I retested the original problem description as I am now using Slackware 14.1 rather than 14.0. Slackware 14.1 uses xine-lib 1.1.21. Thus xine-lib 1.2 is not involved in my original report although xine-lib 1.2 might further complicate the problem.

The video file I tested is /usr/share/xine/visuals/default.mpv. The ffmpeg output indicates the file is mpeg1video. I do not see any ao_new_port related messages in ~/.xsession-errors. Konqueror still freezes hard the moment I select the Properties->Preview tab. I have to kill the konqueror process.

The default.mpv file plays fine in xine, kaffeine, mplayer when I select the file in konqueror. The file does not play in kaboodle, as reported in bug 1905.

(In reply to Michele Calgaro from comment #5)
> 2) the absence of the video stream. _x_ao_new_port is probably only for the
> audio stream, but while navigating through the libxine API documentation I
> also noticed the presence of _x_vo_new_port. My (yet unverified) guess is
> that _x_vo_new_port takes care of the video stream. Darrell mentioned that
> in 3.5.13.2 there is "only nominal support" for videos, and perhaps he meant
> the absence of the video stream. This problem may have generated a long
> time, when the ***_new_port functions were added.
> 
> I am working on this, but expect it will take a while to fix it (this week
> almost no time at all).

In the code, you can find xine_open_video_driver calls. This is equivalent to _x_ao_new_port, hence xine_open_audio_driver.

Darrell,
thanks for the update. There is actually more than one problem here, that's why you also see problems with libxine1

Slavek,
thanks for the additional info, they will be useful. As further note, I discovered one more thing yesterday night. Using libxine1, if a video file extension is .mp4, Kaboodle plays the audio stream ok (no video though). When renaming the file in .mpg, Kaboodle tries to open a video stream (different plugin) and crashes. So to add to the list of problems already mentioned, we also need to look at the mime type association and how Kaboodle decides between audio and video file.

> I fear that both will require a lot of effort.
Yes, I guess this bug will require a lot of effort, especially because we need to maintain compatibility with libxine1 and libxine2 for the different distros.
I will probably work on this in parallel with other bugs, so we keep things moving.

Unassigning from Michele per conversation in Bug 1905.

I suspect that once Bug 1905 is resolved this bug will automagically be fixed as well.

>I suspect that once Bug 1905 is resolved this bug will automagically be fixed
>as well.
The patches from bug 1905 seem to have resolved this bug report as well. No more freezing. Thanks. :)

Marking as RESOLVED FIXED.

Thanks for reporting and testing!

No lock up here as well, but Kaboodle still not playing video as explain in bug 1905.