Some time in recent weeks vlc stopped working for me, i.e. it will no longer play .avi, .mp4 or .mkv files but just lists a continuous stream of errors to the console (see below). I'm currently on: $ rpm -qa vlc\* vlc-extras-3.0.0-25.20180109git0c462fc.fc27.x86_64 vlc-core-3.0.0-25.20180109git0c462fc.fc27.x86_64

but I'm pretty sure the problem started before the recent release of VLC 3. This is a typical slice of output: $ vlc foo.avi VLC media player 3.0.0-rc6 Vetinari (revision 3.0.0-rc5-7-g0c462fc53e) [0000559d9bd7d410] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [0000559d9be4a960] [cli] lua interface: Listening on host "*console". VLC media player 3.0.0-rc6 Vetinari Command Line Interface initialized. Type `help' for help. > [0000559d9be30ae0] main audio output error: too low audio sample frequency (0) [00007eff94c1d0d0] main decoder error: failed to create audio output [0000559d9be30ae0] main audio output error: Can't convert non linear input [00007effb80012e0] main audio filter error: cannot add user audio filter "scaletempo" (skipped) [0000559d9be30ae0] main audio output error: Can't convert non linear input [0000559d9be30ae0] main audio output error: cannot setup filtering pipeline [00007eff94c1d0d0] main decoder error: failed to create audio output [00007eff84001e30] main video output error: video output creation failed [00007eff94c07150] main decoder error: failed to create video output ... and so ad infinitum.

Essentially the same thing happens with every video file I try, even though the same files *do* play correctly with the default KDE and Gnome video tools. It's possible that some codec is missing, but the errors don't seem to point to that. In any case these are the ones I have: $ rpm -qa gstreamer\* gstreamer-plugins-base-0.10.36-18.fc27.x86_64 gstreamermm-1.4.3-1.fc25.x86_64 gstreamer-0.10.36-18.fc27.x86_64 gstreamer1-vaapi-1.12.4-1.fc27.x86_64 gstreamer1-plugins-bad-1.12.4-2.fc27.x86_64 gstreamer1-1.12.4-1.fc27.i686 gstreamer1-plugins-base-1.12.4-1.fc27.x86_64 gstreamer1-plugins-good-1.12.4-1.fc27.x86_64 gstreamer1-libav-1.12.4-1.fc27.x86_64 gstreamer1-plugins-base-1.12.4-1.fc27.i686 gstreamer-plugins-bad-nonfree-0.10.23-5.fc27.x86_64 gstreamer1-plugins-ugly-1.12.4-1.fc27.x86_64 gstreamer-tools-0.10.36-18.fc27.x86_64 gstreamer1-1.12.4-1.fc27.x86_64 I'd be interested to hear opinions on what's going on. VLC used to work perfectly for me, certainly on F26 and (I believe) on F27 though I can't swear to it. Turning SElinux off makes no difference.

On Tue, 2018-02-13 at 08:10 +0800, Ed Greshko wrote: > On 02/13/18 07:58, Patrick O'Callaghan wrote: >> Some time in recent weeks vlc stopped working for me, i.e. it will no >> longer play .avi, .mp4 or .mkv files but just lists a continuous stream >> of errors to the console (see below). I'm currently on: >> >> $ rpm -qa vlc\* >> vlc-extras-3.0.0-25.20180109git0c462fc.fc27.x86_64 >> vlc-core-3.0.0-25.20180109git0c462fc.fc27.x86_64 > I have > > vlc-core-3.0.0-0.48.git20180109.rc5.fc27.x86_64 > vlc-3.0.0-0.48.git20180109.rc5.fc27.x86_64 > > Both from rpmfusion. No problems to play any video... Interesting. My rpms are from fedora-multimedia, and I note that the names are slightly different (vlc-core and vlc-extras rather than vlc and vlc-core). Since I have RPMfusion (free and nonfree) enabled I'm guessing this is correct, as there doesn't seem to be a way to force dnf to use the RPMfusion one (other than disabling the official repos of course).

Aside from that, if I run vlc with no arguments, it does start and I can then view a video. So it looks like there's a change of behaviour compared to the previous version where I could simply type 'vlc movie' and it would run. If that's intentional, then it's a feature and not a bug, but the error message(s) leave a *lot* to be desired. Maybe time for a BZ report.

Den 2018-02-13 kl. 13:14, skrev Ed Greshko: > On 02/13/18 19:31, Patrick O'Callaghan wrote: 3.0.0-rc5-0-gf53236af09) > > Oh, you mention "fedora-multimedia". Is that an actual fedora sponsored repo or a > 3rd party repo like rpmfusion? I ask since I've not heard of that one. > It is netativo17 repo found on https://negativo17.org/

On 02/13/18 20:51, Patrick O'Callaghan wrote: > Sorry for the confusion. The repo name misled me into thinking it was > an official Fedora one. Understandable.  IMO, they should be discouraged from using the "fedora" name for that very reason.

On 02/13/2018 12:44 PM, Stephen Morris wrote: > Hi Ed, just my 2 cents worth, I have the same setup as Patrick, and > like Patrick I use the negativo17 repositories for Nvidia (I found > rpmfusion to be not reliable enough with their binary files for > nvidia), but I'm also using their repositories for Handbrake and > Steam. I didn't have any issues with the repository name of > Fedora-Multimedia, to me it was obvious what it was. Negativo17 > supports multiple distributions and to me it makes perfect sense to > name the repositories for the distribution they are for, the only > source of potential confusion could be where he uses the same > repository name for different versions of the same distribution. Two comments.  First, I've never used negativo17, but I've never heard anything bad about it.  Second, my understanding is that you can either use it or rpmfusion but not both, to prevent conflicts.  I've always used rpmfusion, which is why I've never tried negativo17.

On 02/14/18 05:23, Stephen Morris wrote: > I use Negativo17 because in the past I have found that rpmfusion were very tardy > with their Nvidia binary files in keeping pace with kernel version changes. I have > all the negativo17 repositories enabled and all the rpmfusion repositories enabled, > so far without any apparent conflicts, which may just be luck on my part. You know, if you use akmod-nvidia from rpmfusion you don't have to worry about a binary being available in the repo as the binary will be built locally on your own system when a new kernel is installed.

Simple, easy.  No muss, no fuss. _______________________________________________ users mailing list -- users(a)lists.fedoraproject.org To unsubscribe send an email to users-leave(a)lists.fedoraproject.org

On 02/15/18 04:24, Kevin Cummings wrote: > On 02/13/18 16:59, Ed Greshko wrote: >> On 02/14/18 05:23, Stephen Morris wrote: >>> I use Negativo17 because in the past I have found that rpmfusion were very tardy >>> with their Nvidia binary files in keeping pace with kernel version changes. I have >>> all the negativo17 repositories enabled and all the rpmfusion repositories enabled, >>> so far without any apparent conflicts, which may just be luck on my part. >> >> You know, if you use akmod-nvidia from rpmfusion you don't have to worry about a >> binary being available in the repo as the binary will be built locally on your own >> system when a new kernel is installed. > Right up until a kernel interface changes and you have to wait for a new > nvidia driver to use the new kernel.... > Been using rpmfusion for many years now.

That has *never* happened to me.

So, if you're talking about a rare occurrence to say why you shouldn't use "something" then one best stop using Fedora, Ubuntu, Suse, any flavor of Linux, all brands of mobile phones, etc.  They all have had hiccups causing minor inconvenience to a segment of their users.

_______________________________________________ users mailing list -- users(a)lists.fedoraproject.org To unsubscribe send an email to users-leave(a)lists.fedoraproject.org

> Sorry for the confusion. The repo name misled me into thinking it > was an official Fedora one.

Understandable. IMO, they should be discouraged from using the "fedora" name for that very reason.

On 02/15/18 10:06, Tim wrote: > On 02/13/18 20:51, Patrick O'Callaghan wrote: > > > Sorry for the confusion. The repo name misled me into thinking it > > > was an official Fedora one. > > Ed Greshko: > > Understandable. IMO, they should be discouraged from using the > > "fedora" name for that very reason. > > I have mixed feelings about that. I see the confusion it causes, but > when dealing with other repos, you want to be able to see that you've > got the right one. > > If /other/ repo sites named their "for Fedora" repos actually including > the words "for-fedora," it would alleviate both issues. > IMO, I feel the problem with using the Fedora name in a repo or site makes people think it is formally affiliated with and endorsed by The Fedora Project. Companies such as Disney, Apple, Samsung, and others go to great lengths to protect their brand. Why should Fedora be any different?

On 15/2/18 8:59 pm, Patrick O'Callaghan wrote: > On Thu, 2018-02-15 at 10:21 +0800, Ed Greshko wrote: > > On 02/15/18 10:06, Tim wrote: > > > On 02/13/18 20:51, Patrick O'Callaghan wrote: > > > > > Sorry for the confusion. The repo name misled me into thinking it > > > > > was an official Fedora one. > > > > > > Ed Greshko: > > > > Understandable. IMO, they should be discouraged from using the > > > > "fedora" name for that very reason. > > > > > > I have mixed feelings about that. I see the confusion it causes, but > > > when dealing with other repos, you want to be able to see that you've > > > got the right one. > > > > > > If /other/ repo sites named their "for Fedora" repos actually including > > > the words "for-fedora," it would alleviate both issues. > > > > > > > IMO, I feel the problem with using the Fedora name in a repo or site makes people > > think it is formally affiliated with and endorsed by The Fedora Project. Companies > > such as Disney, Apple, Samsung, and others go to great lengths to protect their > > brand. Why should Fedora be any different? > > I agree. I understand why the package is labelled 'fedora' since it's > meant for Fedora (and not, say Suse) but I feel it should be qualified > by the repo identifier, e.g. negativo17-fedora. I'm using the negativo17-fedora.repo that contains definitions for all the negativo17 repositories for fedora. As this is a text file, one could edit the file and change the repository names to use Patrick's suggestion if desired.

On Tue, 2018-02-13 at 13:36 +0100, Jon Ingason wrote: > Den 2018-02-13 kl. 13:14, skrev Ed Greshko: >> On 02/13/18 19:31, Patrick O'Callaghan wrote: > 3.0.0-rc5-0-gf53236af09) >> Oh, you mention "fedora-multimedia". Is that an actual fedora sponsored repo or a >> 3rd party repo like rpmfusion? I ask since I've not heard of that one. >> > It is netativo17 repo found on https://negativo17.org/ Aha! That must be it. I'd forgotten I had that repo installed (I needed it for NVidia drivers). I've uninstalled that vlc, disabled Negativo17 and reinstalled vlc from RPMfusion. It's working now.

On Wed, 2018-02-14 at 08:08 +1100, Stephen Morris wrote: > So from my perspective the vlc package you had problems with works fine > on my system. > > The packages I have installed are: > > > bash-4.4$ rpm -qa vlc* > vlc-core-3.0.0-25.20180109git0c462fc.fc27.x86_64 > vlc-3.0.0-25.20180109git0c462fc.fc27.x86_64 When using Negativo17 I never had a package called vlc, just vlc-core and vlc-extras. The /usr/bin/vlc binary came from vlc-core. On switching to RPMfusion I now have a package called vlc. So I wonder if your installation is in fact from Negativo17.

On 02/14/2018 01:43 PM, Stephen Morris wrote: > On 14/2/18 10:05 am, Patrick O'Callaghan wrote: >> On Wed, 2018-02-14 at 08:08 +1100, Stephen Morris wrote: >>> So from my perspective the vlc package you had problems with works fine >>> on my system. >>> >>> The packages I have installed are: >>> >>> >>> bash-4.4$ rpm -qa vlc* >>> vlc-core-3.0.0-25.20180109git0c462fc.fc27.x86_64 >>> vlc-3.0.0-25.20180109git0c462fc.fc27.x86_64 >> When using Negativo17 I never had a package called vlc, just vlc-core >> and vlc-extras. The /usr/bin/vlc binary came from vlc-core. On >> switching to RPMfusion I now have a package called vlc. So I wonder if >> your installation is in fact from Negativo17. > I am definitely using the negativo17 packages. As a test I uninstalled > the vlc and vlc-core packages via yumex, and issued the vlc command in a > shell which told me it couldn't be found. I then went back into Yumex > and did a search for vlc, in the list of packages returned it said that > the vlc, vlc-core and vlc-extras package were from fedora-multimedia > which is negativo17, it did not provide me with any reference to vlc in > rpmfusion. I then installed vlc, vlc-core and vlc-extras (I didn't have > this one previously), ran vlc from the shell, and it work as I > documented previously. I have also checked on the negativo17 physical > repository and negativo17 does actually provide packages vlc, vlc-core > and vlc-extras. Looking at the file list from vlc and vlc-core, the vlc > package may not need to be installed. The vcl package provides files in > /usr/bin of qvlc and svlc, where the vlc-core package provides files in > /usr/bin of cvlc, nvlc, rvlc, vlc and vlc-wrapper. I haven't yet tried > the vlc functionality after uninstalling all 3 packages and just > installing vlc-core and vlc-extras. > > I've also checked the physical rpmfusion repository and their free > repository also has packages vlc, vlc-core and vlc-extras, but they are > named differently to the negativo17 ones so there is no confusion as to > which is which. What I don't know yet is why a vlc search in Yumex > doesn't show me the rpmfusion ones? I don't use yumex, but dnfdragora displays them--provided the rpmfusion-free and rpmfusion-free-update repos are enabled. > Particularly given that dnf info vlc > tells me the installed vlc package is from fedora-multimedia and there > is a vlc package available from rpmfusion-free-updates and there is a > source package available from fedora-multimedia-source, which is what > dnf told before I did the uninstall and re-install. My packages (as of this morning, using rpmfusion-*): [root@golem4 ~]# dnf list vlc* Last metadata expiration check: 0:19:21 ago on Thu 15 Feb 2018 11:22:18 AM PST. Installed Packages vlc.x86_64 3.0.0-1.fc27 @rpmfusion-free-updates vlc-core.x86_64 3.0.0-1.fc27 @rpmfusion-free-updates vlc-extras.x86_64 3.0.0-1.fc27 @rpmfusion-free-updates Available Packages vlc.i686 3.0.0-1.fc27 rpmfusion-free-updates vlc-core.i686 3.0.0-1.fc27 rpmfusion-free-updates vlc-devel.i686 3.0.0-1.fc27 rpmfusion-free-updates vlc-devel.x86_64 3.0.0-1.fc27 rpmfusion-free-updates

On 02/15/2018 01:43 PM, Stephen Morris wrote: > On 16/2/18 6:52 am, Rick Stevens wrote: >> On 02/14/2018 01:43 PM, Stephen Morris wrote: >>> On 14/2/18 10:05 am, Patrick O'Callaghan wrote: >>>> On Wed, 2018-02-14 at 08:08 +1100, Stephen Morris wrote: >>>>> So from my perspective the vlc package you had problems with works >>>>> fine >>>>> on my system. >>>>> >>>>> The packages I have installed are: >>>>> >>>>> >>>>> bash-4.4$ rpm -qa vlc* >>>>> vlc-core-3.0.0-25.20180109git0c462fc.fc27.x86_64 >>>>> vlc-3.0.0-25.20180109git0c462fc.fc27.x86_64 >>>> When using Negativo17 I never had a package called vlc, just vlc-core >>>> and vlc-extras. The /usr/bin/vlc binary came from vlc-core. On >>>> switching to RPMfusion I now have a package called vlc. So I wonder if >>>> your installation is in fact from Negativo17. >>> I am definitely using the negativo17 packages. As a test I uninstalled >>> the vlc and vlc-core packages via yumex, and issued the vlc command in a >>> shell which told me it couldn't be found. I then went back into Yumex >>> and did a search for vlc, in the list of packages returned it said that >>> the vlc, vlc-core and vlc-extras package were from fedora-multimedia >>> which is negativo17, it did not provide me with any reference to vlc in >>> rpmfusion. I then installed vlc, vlc-core and vlc-extras (I didn't have >>> this one previously), ran vlc from the shell, and it work as I >>> documented previously. I have also checked on the negativo17 physical >>> repository and negativo17 does actually provide packages vlc, vlc-core >>> and vlc-extras. Looking at the file list from vlc and vlc-core, the vlc >>> package may not need to be installed. The vcl package provides files in >>> /usr/bin of qvlc and svlc, where the vlc-core package provides files in >>> /usr/bin of cvlc, nvlc, rvlc, vlc and vlc-wrapper. I haven't yet tried >>> the vlc functionality after uninstalling all 3 packages and just >>> installing vlc-core and vlc-extras. >>> >>> I've also checked the physical rpmfusion repository and their free >>> repository also has packages vlc, vlc-core and vlc-extras, but they are >>> named differently to the negativo17 ones so there is no confusion as to >>> which is which. What I don't know yet is why a vlc search in Yumex >>> doesn't show me the rpmfusion ones? >> I don't use yumex, but dnfdragora displays them--provided the >> rpmfusion-free and rpmfusion-free-update repos are enabled. >>>                                      Particularly given that dnf info >>> vlc >>> tells me the installed vlc package is from fedora-multimedia and there >>> is a vlc package available from rpmfusion-free-updates and there is a >>> source package available from fedora-multimedia-source, which is what >>> dnf told before I did the uninstall and re-install. >> My packages (as of this morning, using rpmfusion-*): >> >> [root@golem4 ~]# dnf list vlc* >> Last metadata expiration check: 0:19:21 ago on Thu 15 Feb 2018 11:22:18 >> AM PST. >> Installed Packages >> vlc.x86_64                           3.0.0-1.fc27 >> @rpmfusion-free-updates >> vlc-core.x86_64                      3.0.0-1.fc27 >> @rpmfusion-free-updates >> vlc-extras.x86_64                    3.0.0-1.fc27 >> @rpmfusion-free-updates >> Available Packages >> vlc.i686                             3.0.0-1.fc27 >> rpmfusion-free-updates >> vlc-core.i686                        3.0.0-1.fc27 >> rpmfusion-free-updates >> vlc-devel.i686                       3.0.0-1.fc27 >> rpmfusion-free-updates >> vlc-devel.x86_64                     3.0.0-1.fc27 >> rpmfusion-free-updates > Mine is as follows: > > dnf list vlc* > Failed to synchronize cache for repo 'fedora-games', disabling. > Last metadata expiration check: 4 days, 21:34:58 ago on Sun 11 Feb 2018 > 10:48:39 AEDT. > Installed Packages > vlc.x86_64 1:3.0.0-25.20180109git0c462fc.fc27 @fedora-multimedia > vlc-core.x86_64 1:3.0.0-25.20180109git0c462fc.fc27 @fedora-multimedia > vlc-extras.x86_64 1:3.0.0-25.20180109git0c462fc.fc27 @System > Available Packages > vlc.i686 3.0.0-0.48.git20180109.rc5.fc27 rpmfusion-free-updates > vlc.src 1:3.0.0-25.20180109git0c462fc.fc27 fedora-multimedia-source > vlc-core.i686 3.0.0-0.48.git20180109.rc5.fc27 rpmfusion-free-updates > vlc-debugsource.x86_64 1:3.0.0-25.20180109git0c462fc.fc27 fedora-multimedia > vlc-devel.i686 1:3.0.0-25.20180109git0c462fc.fc27 fedora-multimedia > vlc-devel.x86_64 1:3.0.0-25.20180109git0c462fc.fc27 fedora-multimedia > vlc-plugin-jack.x86_64 1:3.0.0-25.20180109git0c462fc.fc27 fedora-multimedia > > > This output surprises me. The rpmfusion repositories are enabled, but > Yumex does not show the rpmfusion vlc versions as being installed even > after using it to uninstall the fedora-multimedia versions. Huh? According to the above, you have the fedora-multimedia versions installed, not the rpmfusion-free versions (although it's saying that vlc-extras was installed from a local RPM file (the "@System" repo). > If I issue > command vlc in a shell it runs the fedora-multimedia application. If I > use Yumex to uninstall vlc and vlc-core, then issue the command vlc in a > shell, it tells me the command doesn't exist. If I then use Yumex to > install the fedora-multimedia versions again, I can run the command from > the shell again. My bad, I've just looked at the output again and > realized it's not telling me that vlc.i686 is installed, it's just > telling me its available. I don't understand why the output is saying > vlc-extras was @system installed when all 3 of those vlc packages were > installed at the same time via Yumex. Are you certain of that? I mean, it could be you installed vlc-extras from a local RPM, then attempting to reinstall it via yumex may result in a "already installed" error and the locally-installed version would continue to be shown. Either remove and reinstall all three via yumex or dnf or expect this sort of thing.

Again, not using yumex, I can't speak to its behaviour. Is it possible that yumex is actually using packagekit backends as apper does? If so, perhaps packagekit has some cruft left over that's masking things. dnf is seeing the packages from rpmfusion-free as available. If yumex doesn't, then something's wrong with yumex's configs/database/whatever. I'd suggest you go with dnf and dnfdragora (if you need a GUI). I use dnf directly from the command line 99% of the time. I think of dnf and its kin as the "official" Fedora package management systems and stay away from apper, packagekit and yum/yumex/whatever--at least for what I stick my fingers on. If they use stuff beyond rpm behind the scenes, I don't know about it.