Xine - causes total system crash since last week

English Multimedia
#1

Hi

Running xine to watch videos, and since possibly Friday, I’ve been regularly getting a total system lock up that requires the power button to get out of. This usually occurs after a few minutes of playing video (usually mp4 , possibly even exclusively an mp4)

So, total crash except for about a second of sound that loops repeatedly until the power button finally forces the laptop off. No mouse, no caps lock, no using Alt Ctrl F1 to get to a tty terminal…

I’ve played the same video back - a download from youtube (IFSC Bouldering Word Cup) done via youtube-dl with mplayer and it played all the way through without glitches.

As far as I can see I get nothing in the logs - I think the freeze is too sudden for anything to get logged.

I don’t think it’s the sound on the laptop, I was playing a gig on Saturday night, and I use Clementine to do music before, between and after the two sets we do. Xine is the only thing that crashes it.

Information for package xine-ui:
--------------------------------
Repository     : packman                      
Name           : xine-ui                      
Version        : 0.99.10-61.25                
Arch           : x86_64                       
Vendor         : http://packman.links2linux.de
Installed Size : 3.2 MiB                      
Installed      : Yes                          
Status         : up-to-date                   
Source package : xine-ui-0.99.10-61.25.src    
Summary        : Video player with plugins

I’m up to date using tumbleweed

I’ll try and see if I can run a tail of journalctl in a terminal alongside xine and maybe top as well. I don’t think the system load is going up beforehand.

I’ve got 16gb RAM, laptop is a Lenovo Z70, and apart from this runs fine.

Crashes usually happen within about 5 to 10 minutes after starting xine.

I’ll post more details later if I can get anything from logs at all. It should be quite easy to get it to crash, anyway…

Regards

#2

xine-ui is just a frontend, and irrelevant here.
But neither xine-ui nor libxine2 itself have been updated recently.

And anyway, a total system freeze always points to a problem on a lower level.

In this case, it’s probably related to the video driver, maybe VDPAU (hardware video decoding).

What graphics card/driver are you using?

Try to disable VDPAU in xine’s settings, either set a different “video driver” in the GUI (Settings->video->driver) or edit ~/.xine/config with a text editor to contain this:

video.driver:xv

(you could also try xshm, or any of the other options really, except auto and vdpau)
Alternatively, switch libxine2 to the version from the standard repos as a test, which has vdpau disabled (but libxine2-codecs should still work nevertheless).

#3

This has got slightly more bizarre

After reading wolfi323’s reply, I thought I’d check my video car / driver

lspci tells me

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)

Ans then I thought I’d look in /var/log/Xorg.0.log

and found that ended with

  1722.383] (II) Server terminated successfully (0). Closing log file.

on or about the date when this problem started

So, what also happened then was that my default-displaymanager had been reset by a zypper dup to gdm, and this time I just ignored it rather than running

sudo update-alternatives --config default-displaymanager

and choosing lightdom which I prefer and have been running for ages

And the xine problems started at about the same time

My /var/log/Xorg.0.log was dated as below

Apr 18 10:32 Xorg.0.log

So, just I changed my default-displaymanager back to lightdm, and after a reboot my Xorg.0.log gets updated, and the xine crashes appear to have stopped

And I’ve also changed back to gdm, just to check it, and ran xine for a couple of hours without it crashing my computer.

So at this point, it appears to be fixed. But I can’t prove what caused it.

At the moment my /var/log/Xorg.0.log is from 14.45pm this afternoon, it’s now 21.29pm

That’s probably a different problem, but I assume it’s one that needs fixing? Presumably Xorg.0.log should be getting updated whilst using GDM to log in with? and not LightDm?

Hope that is helpful for the OpenSUSE developers, even if it is straying off my own topic…

#4

Since a bit more than half a year, the default displaymanager is no longer set by /etc/sysconfig/displaymanager, but rather via update-alternatives.
Unfortunately, the old setting is not “migrated”.

Also, there was a bug in update-alternatives, that caused it to “forget” a manual setting during updates, but that should be fixed meanwhile.

At the moment my /var/log/Xorg.0.log is from 14.45pm this afternoon, it’s now 21.29pm

That’s probably a different problem, but I assume it’s one that needs fixing? Presumably Xorg.0.log should be getting updated whilst using GDM to log in with? and not LightDm?

That’s not a bug.
GDM runs Xorg as unprivileged user (i.e. not as root anymore) since quite some time, and therefore Xorg cannot create a logfile in /var/log/ due to missing permissions to do so.
The log will get created in ~/.local/share/xorg/ (I think) therefore, or it can be extracted from systemd’s journal.

Hope that is helpful for the OpenSUSE developers, even if it is straying off my own topic…

“The OpenSUSE developers” (whoever that should be) likely won’t read this here.

#5

Hi

Thanks for the reply

Also, there was a bug in update-alternatives, that caused it to "forget" a manual setting during updates, but that should be fixed meanwhile.

This bug still seems to be present, as I’ve been using update-alternatives to reset my default-displaymanager back to lightdm every time an update reverts it to GDM, which is every couple of months or so

The difference is that this time I didn’t. So its possible this is not a new bug with xine, as I’ve always switched back to Lightdm immediately

The log will get created in ~/.local/share/xorg/ (I think) therefore, or it can be extracted from systemd's journal.

Thank you, yes, that is correct, see below

ls -1 .local/share/xorg/
Xorg.1.log
Xorg.1.log.old
Xorg.2.log

Now, an update of what I’ve found, and what I’ve not found.

Laptop is perfectly stable running GDM or LightDM except when running xine,
So far, I only get the xine hard crash when my display manager is GDM - I will test this further, but yesterday I reverted to GDM, left xine running and had 3 complete crashes

Last night,with Lightdm, watched most of a film with xine, no crashes

The crashes are completely “hard”

I had ssh sessions from a desktop compuiter running with

“sudo journalctl -f” and “top”. The crash disconnected them. logging just stopped.

Both showed nothing untoward, and journalctl didn’t log anything, and system load was perfectly reasonable, memory use was low. Nothing was logged.

Xine was running from a console, and there was nothing on that console to show a problem just before the crash, either.

This evening, I have Lightdm as my displaymanager, I will watch a film using xine. I do not expect it to crash

Assuming that is the case, I will switch to GDM, reboot, and leave xine watching the same film. And we’ll see what happens.

As you can guess, my suspicion is that this is a problem with GDM and xine.

xine, by the way shows this:

xine Bouldering2018-02-Moscow-Semi-Finals.mp4 
This is xine (X11 gui) - a free video player v0.99.10.
(c) 2000-2014 The xine Team.
libva info: VA-API version 1.0.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_0
libva info: va_openDriver() returns 0
vo_vdpau: Failed to check vdpau get/put bits native capability : VDP_STATUS_NO_IMPLEMENTATION

I’ve pretty much always seen that vdpau “failed to check vdpau” etc I don’t think that changes whether I am using lightdm or gdm. I will confirm later

Regards

#6

It looks as though this problem has resolved itself, without me being able to determine what the exact cause was.

As I said last post, the problem seemed to be related to using GDM as my default-displaymanager - but after posting that, my tests have not provoked another crash.

and I’ve been switching back and forwards between LightDM and GDM several times.

I note that there was an update too Mesa just after I posted last, and I wonder if there was a glitch between that and my video card that was the root of the issue.

But, as I say, no logs because the crash was that total.

Bt is does appear to be fixed now.