3:56 p.m.
I reported earlier that vlc-3.0.0-0.16 gave immediate segfaults in
fedora 24. It does the same for me in fedora 25 with SD and HD TV
recordings and DVD .iso images. Before the segfault it reports 'libEGL
warning: DRI2: failed to authenticate', but that may not be the actual
cause. Still using the nVidia 304 driver.
vlc-3.0.0-0.9.fc25.x86_64 works for me, as does smplayer-17.3.0-1
John P
4:34 p.m.
On 28/03/17 16:56, John Pilkington wrote:
I reported earlier that vlc-3.0.0-0.16 gave immediate segfaults in
fedora 24. It does the same for me in fedora 25 with SD and HD TV
recordings and DVD .iso images. Before the segfault it reports 'libEGL
warning: DRI2: failed to authenticate', but that may not be the actual
cause. Still using the nVidia 304 driver.
vlc-3.0.0-0.9.fc25.x86_64 works for me, as does smplayer-17.3.0-1
Yesterday, after a vlc upgrade in SL7, I absent-mindedly re-upgraded it
in FC25. Same immediate segfault. I couldn't locate any EGL-files,
and 3.0.0-0.9 wasn't showing up, so I removed all *nvidia packages
(304.135) using yumex-dnf and to my great surprise nouveau just took
over. It was already installed, but presumably blacklisted. I suppose
that could have been the problem.
vlc doesn't segfault with nouveau and appears to work ok. It gives the
same libEGL warning, and adds others re vdpau, but seems usable.
John P
_______________________________________________
rpmfusion-users mailing list -- rpmfusion-users(a)lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-users-leave(a)lists.rpmfusion.org
3:05 p.m.
On 26/05/17 17:34, John Pilkington wrote:
On 28/03/17 16:56, John Pilkington wrote:
> I reported earlier that vlc-3.0.0-0.16 gave immediate segfaults in
> fedora 24. It does the same for me in fedora 25 with SD and HD TV
> recordings and DVD .iso images. Before the segfault it reports
> 'libEGL warning: DRI2: failed to authenticate', but that may not be
> the actual cause. Still using the nVidia 304 driver.
>
> vlc-3.0.0-0.9.fc25.x86_64 works for me, as does smplayer-17.3.0-1
>
Yesterday, after a vlc upgrade in SL7, I absent-mindedly re-upgraded it
in FC25. Same immediate segfault. I couldn't locate any EGL-files,
and 3.0.0-0.9 wasn't showing up, so I removed all *nvidia packages
(304.135) using yumex-dnf and to my great surprise nouveau just took
over. It was already installed, but presumably blacklisted. I suppose
that could have been the problem.
vlc doesn't segfault with nouveau and appears to work ok. It gives the
same libEGL warning, and adds others re vdpau, but seems usable.
Having found that switching between *nvidia-304 and *nouveau could seem
painless I tried re-enabling *nvidia-304 and installed vlc-3.0.0-0.25
from testing. My kde-plasma desktop was active but had no panels or
task-launcher, and I wasn't able make either of them visible.
Eventually I reverted again to nouveau, undid a few settings that had
got changed, and once more have a working desktop. The new vlc seems
ok, too.
The video card (old) is a GeForce 7500 LE (G72)
> John P
8:37 p.m.
On 29/05/17 16:05, John Pilkington wrote:
On 26/05/17 17:34, John Pilkington wrote:
> On 28/03/17 16:56, John Pilkington wrote:
>> I reported earlier that vlc-3.0.0-0.16 gave immediate segfaults in
>> fedora 24. It does the same for me in fedora 25 with SD and HD TV
>> recordings and DVD .iso images. Before the segfault it reports
>> 'libEGL warning: DRI2: failed to authenticate', but that may not be
>> the actual cause. Still using the nVidia 304 driver.
>>
>> vlc-3.0.0-0.9.fc25.x86_64 works for me, as does smplayer-17.3.0-1
>>
>
> Yesterday, after a vlc upgrade in SL7, I absent-mindedly re-upgraded
> it in FC25. Same immediate segfault. I couldn't locate any
> EGL-files, and 3.0.0-0.9 wasn't showing up, so I removed all *nvidia
> packages (304.135) using yumex-dnf and to my great surprise nouveau
> just took over. It was already installed, but presumably blacklisted.
> I suppose that could have been the problem.
>
> vlc doesn't segfault with nouveau and appears to work ok. It gives
> the same libEGL warning, and adds others re vdpau, but seems usable.
Having found that switching between *nvidia-304 and *nouveau could seem
painless I tried re-enabling *nvidia-304 and installed vlc-3.0.0-0.25
from testing. My kde-plasma desktop was active but had no panels or
task-launcher, and I wasn't able make either of them visible. Eventually
I reverted again to nouveau, undid a few settings that had got changed,
and once more have a working desktop. The new vlc seems ok, too.
The video card (old) is a GeForce 7500 LE (G72)
Another update. Under nouveau, xrandr showed only a 1024*768 monitor,
with no sign of the 1920*1080 tv on a DVI-to-HDMI-adapter. That screen
showed the same picture, with the wrong aspect ratio. So, for now, back
to the newly-stable 304.135-4. The panel and launcher reappeared after
'running' NVIDIA-X-Server Settings.
vlc...26snap from testing still segfaults on starting playback. vlc...9
from release still works.
This hardware has done what I have asked it to do for ~10 years, and
another in my family gives satisfaction under kubuntu 16.04, but it
looks as if a single-width GT 710 should fit in the box without needing
a new power supply or too much cash, would offer new facilities and
might suffer less from bit-rot. Timetabling delivery is awkward at
present, so I'll see how things go for a little longer.
John P
2:46 p.m.
I've made several posts about vlc failing in f24 and f25 with an old
video card and the nvidia-304 drivers. It seemed time to move on.
I now have a GT 710 fanless card from msi, which is marketed as an
upgrade for older MB video hardware; it isn't a gamers' card, but it
runs the current nvidia driver from rpmfusion.
It is working well for me in mythtv, driving both a basic vga monitor
and my HD tv (a+v) via hdmi, although at present DLNA moving-picture
quality is still rather better.
But I don't appear to have access to my old MB audio hardware, and
neither vlc nor smplayer have yet played with audio. I've found a
'PulseAudio/Examples' page
https://wiki.archlinux.org/index.php/PulseAudio/Examples
which looks as if it might eventually lead to an answer, but any hints
from closer to home would be welcome.
John P
3:30 p.m.
On Fri, 23 Jun 2017 15:46:39 +0100
John Pilkington <J.Pilk(a)tesco.net> wrote:
But I don't appear to have access to my old MB audio hardware,
and
neither vlc nor smplayer have yet played with audio. I've found a
'PulseAudio/Examples' page
https://wiki.archlinux.org/index.php/PulseAudio/Examples
which looks as if it might eventually lead to an answer, but any
hints from closer to home would be welcome.
If your audio hardware previously worked with vlc or mplayer, then it
is still compatible. What has likely happened is that the new video
card has been interpreted as an audio device, and the order of your
audio devices has changed because of device discovery during boot. So
the audio output that used to go to your MB audio hardware is now going
to the audio output on the new video card.
Try aplay -l to see your list of audio hardware. Once you have that,
play a wav to your MB audio by using
aplay -D [name of MB audio device] [wav file name]
If this plays, then it is the ordering of devices that is at fault.
The best way to fix this is to use the pavucontrol application. You
can set the default audio hardware for pulseaudio from there.
There is a way to fix the order in alsa by putting a file
in /etc/modprobe.d, but it is too complicated to explain in a post. If
you search online, you should find references to it. Setting pulse to
use a device will work just as well.
5:17 p.m.
On 23/06/17 16:30, stan wrote:
On Fri, 23 Jun 2017 15:46:39 +0100
John Pilkington <J.Pilk(a)tesco.net> wrote:
> But I don't appear to have access to my old MB audio hardware, and
> neither vlc nor smplayer have yet played with audio. I've found a
> 'PulseAudio/Examples' page
>
> https://wiki.archlinux.org/index.php/PulseAudio/Examples
>
> which looks as if it might eventually lead to an answer, but any
> hints from closer to home would be welcome.
If your audio hardware previously worked with vlc or mplayer, then it
is still compatible. What has likely happened is that the new video
card has been interpreted as an audio device, and the order of your
audio devices has changed because of device discovery during boot. So
the audio output that used to go to your MB audio hardware is now going
to the audio output on the new video card.
Try aplay -l to see your list of audio hardware. Once you have that,
play a wav to your MB audio by using
aplay -D [name of MB audio device] [wav file name]
If this plays, then it is the ordering of devices that is at fault.
The best way to fix this is to use the pavucontrol application. You
can set the default audio hardware for pulseaudio from there.
There is a way to fix the order in alsa by putting a file
in /etc/modprobe.d, but it is too complicated to explain in a post. If
you search online, you should find references to it. Setting pulse to
use a device will work just as well.
Thanks for the reply. I had tried both aplay -l and aplay -L, and saw
only nVidia devices.
aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
Here's something else, hot off the screen :
dmesg | grep -i hda
[ 20.912368] snd_hda_intel 0000:01:00.1: Disabling MSI
[ 20.912376] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio
client
[ 21.501482] input: HDA NVidia HDMI/DP,pcm=3 as
/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card0/input5
[ 21.501539] input: HDA NVidia HDMI/DP,pcm=7 as
/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card0/input6
[ 146.001011] snd_hda_codec_hdmi hdaudioC0D0: HDMI: invalid ELD data
byte 12
?
5:50 p.m.
On Fri, 23 Jun 2017 18:17:36 +0100
John Pilkington <J.Pilk(a)tesco.net> wrote:
Thanks for the reply. I had tried both aplay -l and aplay -L, and
saw only nVidia devices.
aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
Here's something else, hot off the screen :
dmesg | grep -i hda
[ 20.912368] snd_hda_intel 0000:01:00.1: Disabling MSI
[ 20.912376] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo
audio client
[ 21.501482] input: HDA NVidia HDMI/DP,pcm=3 as
/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card0/input5
[ 21.501539] input: HDA NVidia HDMI/DP,pcm=7 as
/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card0/input6
[ 146.001011] snd_hda_codec_hdmi hdaudioC0D0: HDMI: invalid ELD data
byte 12
?
alsa is only aware of the sound devices on the video card.
If alsa doesn't see a device, it won't work in pulse (or anywhere).
Alsa is the underlying access to the hardware.
So, is there any way that you have it turned off in the BIOS?
Is there a blacklist for the device in /etc/modprobe.d?
Do an lsmod and an lspci, and check if the sound device on the
motherboard is mentioned there.
Run journalctl -r or journalctl -b, and do a search on snd_ ( /snd_) to
see if there was an error loading the driver for the motherboard sound
device.
Could you have caused an issue when you installed the new video card?
Bent something, loosened something, etc.
8:28 p.m.
On 23/06/17 18:50, stan wrote:
On Fri, 23 Jun 2017 18:17:36 +0100
John Pilkington <J.Pilk(a)tesco.net> wrote:
> Thanks for the reply. I had tried both aplay -l and aplay -L, and
> saw only nVidia devices.
>
> aplay -l
> **** List of PLAYBACK Hardware Devices ****
> card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
> card 0: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
>
> Here's something else, hot off the screen :
>
> dmesg | grep -i hda
> [ 20.912368] snd_hda_intel 0000:01:00.1: Disabling MSI
> [ 20.912376] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo
> audio client
> [ 21.501482] input: HDA NVidia HDMI/DP,pcm=3 as
> /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card0/input5
> [ 21.501539] input: HDA NVidia HDMI/DP,pcm=7 as
> /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card0/input6
> [ 146.001011] snd_hda_codec_hdmi hdaudioC0D0: HDMI: invalid ELD data
> byte 12
>
> ?
alsa is only aware of the sound devices on the video card.
If alsa doesn't see a device, it won't work in pulse (or anywhere).
Alsa is the underlying access to the hardware.
So, is there any way that you have it turned off in the BIOS?
Is there a blacklist for the device in /etc/modprobe.d?
No.
Do an lsmod and an lspci, and check if the sound device on the
motherboard is mentioned there.
Not seen in lspci. A similar box has
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio
Controller (rev 02)
Run journalctl -r or journalctl -b, and do a search on snd_ ( /snd_) to
see if there was an error loading the driver for the motherboard sound
device.
Could you have caused an issue when you installed the new video card?
Bent something, loosened something, etc.
Access was difficult and the board
wasn't properly seated the first time
I powered up. Maybe.
Mythtv frontend setup sees ALSA:hdmi:CARD=NVidia,DEV=1, connected to the
tv, and it works. HDA NVidia, HDMI 1. Supports up to 2.0 (LPCM)
It also finds ALSA:hdmi:CARD=NVidia,DEV=0, with no connection detected;
and some Pulse options.
Possible loss of the non-hdmi options is inconvenient, but it seems
strange that vlc and smplayer don't work via hdmi when myth does. I'll
hunt for more settings.
8:56 p.m.
On Fri, 23 Jun 2017 21:28:05 +0100
John Pilkington <J.Pilk(a)tesco.net> wrote:
Access was difficult and the board wasn't properly seated the
first
time I powered up. Maybe.
How about ESD? Is static electricity a problem where you did the work?
Mythtv frontend setup sees ALSA:hdmi:CARD=NVidia,DEV=1, connected to
the tv, and it works. HDA NVidia, HDMI 1. Supports up to 2.0 (LPCM)
It also finds ALSA:hdmi:CARD=NVidia,DEV=0, with no connection
detected; and some Pulse options.
Possible loss of the non-hdmi options is inconvenient, but it seems
strange that vlc and smplayer don't work via hdmi when myth does.
I'll hunt for more settings.
Are you trying to play them through the hdmi connection. I vaguely
recall something about hdmi, that it is not a general audio output
device, but specific to audio to the hdmi channel.
If worst comes to worst, there are cheap USB audio devices available on
ebay. I bought one for about a dollar US, and the audio quality is
fine. It's limited, though, with only line in and line out stereo.
Or maybe you have an old audio card laying around.
3:13 p.m.
GeForce GL 710 (GK208) and nvidia 375.66, Fedora 25 x86_64
Fortunately, it appears that the onboard audio was disabled in the BIOS.
I didn't knowingly make any changes there during the videocard
replacement. Now, in mythtv, I can select from vga or hdmi display,
with audio through either set of speakers. vlc starts with audio
visualisation active but the audio device selector works. SMplayer
shows a shorter list that doesn't include the active hdmi audio
subdevice. I'm not yet confident in predicting where all the active
windows will appear :-)
John P
7:46 p.m.
On Sun, 25 Jun 2017 16:13:16 +0100
John Pilkington <J.Pilk(a)tesco.net> wrote:
GeForce GL 710 (GK208) and nvidia 375.66, Fedora 25 x86_64
Fortunately, it appears that the onboard audio was disabled in the
BIOS. I didn't knowingly make any changes there during the videocard
replacement. Now, in mythtv, I can select from vga or hdmi display,
with audio through either set of speakers. vlc starts with audio
visualisation active but the audio device selector works. SMplayer
shows a shorter list that doesn't include the active hdmi audio
subdevice. I'm not yet confident in predicting where all the active
windows will appear :-)
Maybe battery power was disrupted to the BIOS, and it reverted to
defaults? Anyway, good you got it sorted.
2163
days inactive
2252
days old
rpmfusion-users@lists.rpmfusion.org
11 comments
2 participants
participants (2)
-
John Pilkington -
stan